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

[Martín Ferrari]

Hi Florian,

On 05/04/16 09:27, Florian Weimer wrote:

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

Thanks for bringing this up for discussion.

Coincidentally, a few days ago we were discussing the implementation of
autopkgtest to deal with issues that stem from static linking too (in
particular, libraries that break builds of reverse dependencies, but are
not discovered in a timely fashion, if ever)

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

Highly not desirable :-)

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

Yes, specially on slow architectures, where just running the tests for
libraries can take many minutes a piece.

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

> 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?

> 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?


As a final note, I would like to point out that maybe not only golang
libraries need to be taken into account. For example, prometheus -as it
is compiled upstream- embeds javascript libraries into the binary. I
have removed that in the Debian package, to have run-time 'linking' of
javascript libraries, but that could be happening in other packages.

-- 
Martín Ferrari (Tincho)