[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Security support for go in buster (Was: Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)



On Sun, Jul 01, 2018 at 08:54:00AM +0000, Niels Thykier wrote:
> Moritz Mühlenhoff:
> > Niels Thykier wrote:
> >> If the issues and concerns from you or your team are not up to date,
> >> then please follow up to this email (keeping debian-release@l.d.o and
> >> debian-ports@l.d.o in CC to ensure both parties are notified).
> > 
> > Two issues that we discussed at the recent Security Team sprint wrt
> > problems affecting buster:
> > 
> > [...]
> > 
> > (2) Not an architectual issue, but a cross-arch problem: Buster is
> > reaching a critical mass of applications written in Go and our tooling
> > for security updates is absolutely not in a position to deal with it's
> > approach to link everything statically:
> > 
> > dak on ftpmaster and security-master don't share tarballs, IOW the
> > first time an application is updated in foo-security it's needs an
> > upload including the orig tarball. That's somewhat manageable for
> > standard security updates, but if we'd need to recompile all reverse
> > deps with individual source uploads (which would be dozens to hundreds
> > of packages if it's e.g. in Golang itself), it ends up being total
> > madness.
> > 
> > To be able to support Go-based applications in buster-security we
> > need tooling which
> > - detects which packages need a rebuild if a given Go package has been
> >   fixed.
> > - handles the actual rebuilds and sharing tarballs between security-master
> >   and ftp-master is an automated manner
> > 
> > Cheers,
> >         Moritz
> > 
> 
> Hi Moritz,
> 
> Thanks for highlighting this issue.
> 
> Do you have any idea on whether anyone is working on this tooling at the
> moment (e.g. the tarball sharing between security- and ftp-master)?

I'm not aware of anyone.

> What do you envision as the contingency plan if the tooling is not in
> place for buster?

The canonical solution for unsupportable packages is usually to exclude
them from a stable release, but I really hope we can fix this on a tooling
level.

Cheers,
        Moritz


Reply to: