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

[Michael Hudson-Doyle]

On 12 October 2016 at 10:44, Moritz Mühlenhoff <jmm at inutil.org> wrote:

> On Mon, Jul 11, 2016 at 10:53:57AM +1200, Michael Hudson-Doyle wrote:
> > On 9 July 2016 at 07:21, Moritz Muehlenhoff <jmm at inutil.org> wrote:
> > > Florian Weimer wrote:
> > >> > On Wednesday, 6 July 2016 9:59:32 PM AEST Moritz Mühlenhoff wrote:
> > >> >> What's the current status? Is there technical progress compared to
> what was
> > >> >> discussed in April? The freeze is coming really close and we can't
> support
> > >> >> the status quo for stretch.
> > >> >
> > >> > Perhaps I'm not the best person to speak on the matter as I've never
> > >> > touched any Golang tools except dh-golang. Situation with Golab
> > >> > libraries is not ideal (to say the least) but I understand that
> > >> > Golang is not the only language without concept of dynamic
> > >> > linking. As I recall someone mentioned Haskell as another example.
> > >> >
> > >> > It is my understanding that when vulnerability is fixed in Golang
> > >> > library it should be sufficient to NMU (re-build) all reverse
> > >> > dependencies.
> > >>
> > >> Part of the problem is that we currently lack a decent way to list all
> > >> these reverse dependencies.
> > >
> > > And there's also the much bigger problem that we can't actually rebuild
> > > packages on security.debian.org without a lot of manual work!
> > >
> > > The dak installation for security-master has a _lot_ of tech debt. One
> > > that particularly bites us here is that tarballs between
> security-master
> > > and ftp-master are separate. This e.g. requires that every package that
> > > is new on security-master needs to be build with "-sa" to include
> source
> > > and we can only issue binNMUs for packages which were at least once
> > > upload to jessie-security/stretch-security etc.
> >
> > That does sound unfortunate in the Go context.
> >
> > It is worth bearing in mind though, that you only need to rebuild the
> > binary-containing packages, so if the number of binary-containing
> > packages supported by the security team is tightly constrained, then
> > so is the number of (no-change source, I guess) uploads required to
> > handle any security update (e.g. in Ubuntu 16.04 there are only three
> > packages that contain Go binaries in main).
> >
> > The changes I'm making in Ubuntu to use shared libraries should in the
> > common case (i.e. the fix does not break ABI) make this better, but
> > worst case (where the fix breaks ABI) it will be worse as we might end
> > up having to rebuild the whole rdep tree.
>
> What's the status of that work, will that land in the stretch release?
>

I'm not planning on working on getting it into stretch myself.

Cheers,
mwh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20161012/5036a126/attachment-0001.html>