[pkg-go] Go security support in buster

[Michael Stapelberg]

Can you give some pointers as to how one would go about developing a
solution to this?

I.e., can one set up the archive locally, or is there a test instance, or
how would one go about that?

Also, are we looking to develop a separate tool, or a feature integrated
into some existing tool? (dak?)

Have you had a chance to look at the Built-Using query by ansgar which I
referenced upthread? That should reliably figure out the affected packages.

On Wed, Sep 5, 2018 at 10:56 PM, Moritz Muehlenhoff <jmm at inutil.org> wrote:

> On Wed, Sep 05, 2018 at 08:34:10PM +0200, Florian Weimer wrote:
> > * Michael Stapelberg:
> >
> > > I thought haskell was in a similar boat? They have tooling to schedule
> > > binNMUs for affected packages.
> >
> > My understanding is that you can't simply schedule binNMUs on the
> > security archive because the security archive does not have the
> > sources until the first upload of the package.  (But I'm a bit out of
> > touch; this may have changed.)
>
> Indeed. There's two problems we need to solve:
>
> 1. Find a reliable mechanism if/which packages need to be rebuild. I guess
>    typical use cases are
>    * Vulnerability issue in Golang itself
>    * Vulnerability in some golang-foo package which is used in build
> dependencies
>      (and transitive ones). Let's say some crypto libs need to be fixed.
>
> 2. Once we have a list of affected packages needing a rebuild, there's the
>    issue of actually building them. Due to some underlying complexities
> the security
>    archive and the main archive are separate. Ideally that would be
> resolved
>    in general, but I have no idea how hard it is and there's very little
> people
>    involved in dak development. So for all practical purpose this will need
>    a solution kludging around it: If package foo is to be updated
>    in bar-security, the first upload of bar needs to include source (-sa
>    option in dpkg-buildpackage). That's annoying, and still manageable for
>    single packages, but doesn't scale for rebuilding statically linked
> applications.
>    So we need a reliable mechanism which imports the list of affected
> packages
>    derived in 1.) and triggers binNMUs for them along with an automated
> source
>    import to the security archive.
>
> As for Michael's earlier question wrt Haskell, it's true that this also
> affects
> Haskell, but it hasn't been a practical issue (while in buster we'll have
> applications like Prometheus or Docker which will definitely need updates
> across
> the lifetime of buster). Ideally whatever it being done for Go is generic
> enough
> to also cater for Haskell if we ever need it (or for Rust when it becomes
> more
> prevalent).
>
> Cheers,
>         Moritz
>



-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-go-maintainers/attachments/20180905/1fa7e815/attachment-0001.html>