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

[Niels Thykier <niels@thykier.net>]

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

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

Thanks,
~Niels