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

[Florian Weimer]

* 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.