[pkg-golang-devel] [pkg-go] Security support for packages written in Go

[Paul R. Tagliamonte]

Storing the closure in built-using sounds like the correct solution to me.

   Paul
On Apr 5, 2016 5:47 PM, "Florian Weimer" <fw at deneb.enyo.de> wrote:

> * Martín Ferrari:
>
> >> The alternative is to rebuild reverse dependencies as needed.  I can
> >> see two challenges with that.  Right now, the Built-Using field only
> >> records the source versions of the *direct* dependencies (based on the
> >> dh_golang manual page and a few examples I looked at).  If a critical
> >> update happens farther down the dependency chain, a tool based on
> >> Built-Using will not mark the top-level package as a rebuild
> >> candidate.  When performing the rebuild, it is possible to compensate
> >> for that by rebuilding everything that has an outdated Go source
> >> package in its Build-Using field, iteratively, until we reach a
> >> fixpoint.  But this does not currently work because the -dev packages
> >> do not contain Built-Using information.
> >
> > Actually, I had not noticed this before. I have been including the
> > built-using field in control files, assuming it will end in the binary
> > package too. Maybe we can try to fix this?
> >
> > Alternatively, the built-using field could include the closure of all
> > transitive dependencies, although that might explode in size...
> >
> > In any case, we need to take into account that a security fix in a
> > library usually will not require security uploads to intermediate
> > dependencies.
>
> We currently need these intermediate dependencies to discover all the
> affected applications.  So perhaps dh_golang needs to construct the
> transitive closure, instead of listing just immediate build
> dependencies.  If we don't want to put this information into the
> Packages file, maybe we can keep it in the separate debuginfo
> packages.
>
> >> It does not seem possible to determine rebuild candidates based on
> >> Built-Using alone, building the transitive closure after the fact.  It
> >> may have changed between the original application build and subsequent
> >> library builds.
> >
> > What if we build the transitive closure and discarded any arch:all
> > binaries from the rebuild?
>
> Anything is possible with dak support.  But it's better not to count
> on it and rebuild only what we actually need to ship.
>
> >> Unrelated to all that, we cannot currently perform binNMUs in the
> >> security archive because it does not contain a completely copy of the
> >> main archive.  I'm not sure if there are good approaches to deal with
> >> this yet.
> >
> > So this would be an argument for keeping the status quo and just
> > rebuilding applications manually with a sourceful upload?
>
> Then we absolutely have to minimize what we rebuild.
>
> Keeping the status quo is barely acceptable for this aspect, but there
> is no status quo to keep for the discovery of packages which need
> rebuilding.  We just don't have that capability right now.
>
> _______________________________________________
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-golang-devel/attachments/20160405/163a21c5/attachment.html>