Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs

[Michał Górny]

On Thu, 2021-08-12 at 13:17 -0700, Matt Turner wrote:
> On Thu, Aug 12, 2021 at 5:53 AM Michał Górny <mgorny@g.o> wrote:
> >
> > Hello, everyone.
> >
> > TL;DR: I'd like to propose that stabilizations are done via blockers of
> > security bugs instead of security bugs themselves, i.e. as any other
> > stabilizations.
> >
> >
> > Right now we're often performing security-related stabilizations via
> > security bugs. This has a few problems, that are:
> >
> > 1. Stabilization-related activity causes unnecessary mail to the widely
> > subscribed security alias. That is, subscribed people get notified of
> > package list changes, NATTkA results, every arch doing its work.
> > However, in reality the security team only cares about stabilization
> > being started, stalled or finished -- and for that, getting the usual
> > 'dependent bug added/closed' mail should be sufficient.
> >
> > 2. NATTkA has no good way of distinguishing irrelevant security bugs
> > from security bugs where something went wrong (and NATTkA doesn't use
> > persistent state by design). The most important problem is that --
> > unlike regular stablereqs -- security bugs aren't supposed to be closed
> > after stabilization. It can't really distinguish a security bug 'left
> > open' from a security bug with incorrect package list.
> >
> > 3. Proxied maintainers without editbugs can't actually CC arches on
> > security bugs since the bugs are assigned to security@.
> >
> >
> > To resolve these problems going forward and establish consistent
> > behavior in the future, I'd like to propose to disable 'package list'
> > fields on security bugs and instead expect regular stabilization bugs to
> > be used (and made block the security bugs) for stabilizations. While I
> > understand that filing additional bugs might be cumbersome for some
> > people, I don't think it's such a herculean effort to outweigh
> > the problems solved.
> >
> > In the end, consistency is a good thing and we've introduced a dedicated
> > stabilization category to reduce the spread of stabilization bugs all
> > around the place.
>
> I love this.
>
> It sounds (from IRC) like you're on board with the idea of having
> nattka add kw:security to appropriate stabilization bugs.
>
> Could nattka also do something to the security@-assigned but itself to
> indicate that all security-supported architecture have been handled?
> Something like leaving a comment or fiddling with the security
> whiteboard.

Yeah, this shouldn't be a problem.  However, I would prefer if 'security
supported' architectures were defined somewhere reasonably standard,
rather than hardcoded in nattka.

>
> It would be nice to be able to resolve the security@-assigned but
> before non-security-supported architectures are handled.
>
> To do that, I think we'd want to change what's required for the "clean
> up" step. Since today the "clean up" step is dropping the vulnerable
> package versions from the tree, it is dependent on
> non-security-supported architectures completing the stabilization bug.
> I think we'd like to break that dependence.
>
> I suggest that we redefine the "clean up" step to be: drop
> security-supported architectures' keywords from vulnerable versions.
> That would allow the security@-assigned bug to be resolved before
> non-security-supported architectures are finished with stabilization.
>

To be honest, this sounds like doubling the effort for little benefit. 
After all, removing the old version of the package doesn't resolve any
problems on the end user systems -- upgrading does, and upgrading
usually happens entirely independently of whether we've cleaned up or
not.

Maybe it'd easier to release GLSAs before cleanup happens?  We can
always go the dekeywording way if arch teams are actually slacking.

-- 
Best regards,
Michał Górny