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

[Michał Górny]

On Fri, 2021-08-13 at 12:50 -0400, Aaron Bauman wrote:
> On Thu, Aug 12, 2021 at 01:17:32PM -0700, Matt Turner wrote:
> > On Thu, Aug 12, 2021 at 5:53 AM Michał Górny <mgorny@g.o> wrote:
> > >
>
> <snip>
>
> > 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.
> >
>
> Yes, please. Thank you for bringing this up. This has been a hotly
> debated item in the past with former security leads dictating that
> "clean up" is not relevant to the security process, but it remained
> codified in documentation that it needs to occur.
>
> It is indeed important, as leaving vulnerable versions is the tree is not
> good for anyone and impacts many other areas (e.g. promoting tree
> cleanliness).
>
> Further, as mgorny mentioned in a follow-up email to this, we need to
> understand what is a "security supported" architecture. This has also
> been an issue in the past with council intervention needed to declare
> dropping specific arches to exp profiles and allowing security to drop
> support and subsequently move bugs forward.
>
> And to continue on my soap box, we have a small blurb on the security
> page [1] which states what architectures are considered security supported.
> This is less than ideal. We also generally state that stable arches are
> supported and must be dealt with during the vulnerability process.
>
> So, all in all, it is highly conflated IMHO and is *not* ideal for
> anyone to have to determine that a particular arch is stable but not
> security supported.
>
> As such, I advocate for any stable arch to be security supported by
> default. If the arch lags or is dropped then it goes to unstable
> (process TBD).
>

Yes, this sounds like a good idea.  We should avoid having multiple
classifications for architectures.  If something's good enough to be
stable, it should be security supported.  If it's not, then it shouldn't
be stable.

In the end, I guess the primary problem is manpower.  Given that secbugs
are normally given priority, I don't really see a case for an arch that
would be not good enough to be security supported but at the same time
good enough to cope with the wider range of bugs.

-- 
Best regards,
Michał Górny