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

Michael Hudson-Doyle michael.hudson at canonical.com
Sun Jul 10 22:53:57 UTC 2016


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.

Cheers,
mwh

> And with that setup (and in addition to what Florian mentioned) I see
> no sane way that we can support Go applications in stretch. It's
> already difficult enough to support a distro of the size of Debian with
> volunteers only.

> As Haskell was mentioned; sure it has the same problem. But Go is a totally
> different ballpark: Go aims at system-level services which have a notable
> security surface (think of docker or kubernetes), while I can't remember
> any security vulnerability in an application written in Haskell in the
> archive in the 10+ years I'm in the Security Team.
>
> Cheers,
>         Moritz
>
> _______________________________________________
> 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



More information about the pkg-golang-devel mailing list