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

[Florian Weimer]

Hi,

we need to discuss how we can support applications written in Go for
stretch.

The most radical approach would be not to ship any Go applications in
stretch, only the basic Go language implementations.  This is probably
not desirable.

So we need something to deal with the static linking issue.

The current state seems to be that -dev packages do not contain object
code.  This means that they can be built in any admissible order (as
determined by their (versioned) build dependencies), without altering
the end result, which simplifies matters somewhat (but see below).

One approach would be to ship applications as source code only (just
like libraries), and compile them locally upon installation.  This is
what Emacs and Common Lisp implementations already do.  With the
growth of Go compilation and link times, this seems less and less
attractive, though.

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.

But this requires that the source package version changes as a result
of the rebuild.  I'm not sure if this is what happens.  Ideally, we
want to do this with binNMUs, not sourceful uploads.  We may also need
some build ordering optimization to avoid redundant rebuilds.  This
means that the fact that the -dev packages contain no object files is
of little practical consequence: The optimization would have to order
the builds in the same way as if they did contain object code.  But
maybe the optimization is not needed.

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.

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.

Comments?

Florian