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:
(1) Linux upstream security support for i386 seems at risk at this point.
E.g. KPTI for i386 still isn't merged in Linux master half a year later after
the public Meltdown disclosure in early January (and the development of KPTI
started months before that). Someone at SuSE actually developed patches
as an older SLES release using Linux 3.0 (!) still supports i386, but that
will also EOL at some point and if we don't have the manpower to
develop upstream fixes for future i386-specific flaws.
It's not a strict blocker, but we wanted to raise the discussion whether
it still makes sense to ship 32 bit kernels for buster, which means with
support until ~ 2022.
(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
