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

[Aaron Bauman]

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


[1]: https://www.gentoo.org/support/security/vulnerability-treatment-policy.html

-Aaron