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 <mgo...@gentoo.org> 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
signature.asc
Description: PGP signature
