Am Thu, Jan 12, 2023 at 09:17:18PM +0100 schrieb Paul Gevers:
> On 12-01-2023 16:50, Shengjing Zhu wrote:
> > > But this bug report triggered me: did the golang security situation
> > > already improved during this release cycle. I may be misremembering, but
> > > I recall the problems on the security archive side haven't been fixed,
> > > have they?
> >
> > For some reference, I did several security updates for golang-1.15 for
> > bullseye, but we didn't rebuild other packages. These security updates
> > are not urgent enough anyway.
> > And others also update some Go packages for bullseye. In general, we
> > just do the usual update for stable release.
> >
> > As for the security archive, IIRC, for bullseye, the security team did
> > need to ask ftp-master to copy some individual packages manually. I'm
> > not sure how it is going now. But given the low update frequency I
> > overseved for bullseye, probably that works.
>
> Do you agree with this view for bookworm? I know you want the situation
> improved, but as far as I am aware nobody (from either side) has been
> pushing this forward so it feels a bit late to make this blocking.
I agree with what Shengjing wrote.
The situation around Go isn't great, but it's pretty much identical to
what we had in past releases, so no specific concerns there. Let's simply
carry over the existing entry from the release notes.
The biggest blocker to fixing this on the toolchain level (like e.g. a
script which programatically detects dependencies in need of rebuilds
and issues binNMUs) is still the split ftp.d.o/security.d.o, which
prevents binNMUs and causes a lot of churn with Built-Using whenever
a Go-based program is updated.
One possible solution discussed was to import all of each stable distro
into security.debian.org, but that disk space demand would mean to
move security-master to baremetal (it's currently a Ganeti VM). I don't
think there has ever been a solution/outcome so far TTBOMK.
Cheers,
Moritz
