Hi, regarding "security supported architectures" a few words from security project:
We don't like the differentiation. And in practice, it doesn't even matter nor does it work: In theory, "security supported architectures" would allow us to ignore bugs only affecting specific architectures. But examples are rare. I can only think about a vulnerability affecting just x86 (https://security.gentoo.org/glsa/202003-13) or arm (like some vulnerabilities in Xen hypervisor making use of specific hardware features) in the past 24 months. So this is not really important and in the end we don't really have the man power to differentiate. We just bump because if we would skip a bug fix just because we thought it doesn't affect us, this could have serious impact for no real reason. We also always have to cc all architectures which have stable keywords set on any affected ebuild which should be removed (cleaned up) after security stabilization or maintainers will be unable to do the cleanup. In the past, "security supported architecture" was also used to determine when security team was allowed to publish a GLSA. However, we changed this policy ~3 years ago: Some people don't do regular world upgrades. They only pull updates when they want a newer version or for security reasons via glsa-check tool. Not telling amd64 users that they are using a vulnerable package where we already have a fix for just because slacking architecture like hppa in these days didn't stabilize this package yet was just unacceptable. It wasn't an easy decision even in our small team because some members had the concern that users will get warned about a vulnerability without a solution yet available for their architecture, resulting in bug spam/nagging. However, this never happened and some members even believe that this is also an opportunity: Maybe some users not knowing that their arch team is slacking would step up and join their architecture team and help. For the future some members even want to go one step further and release GLSAs more often and not just for B2 or more severe vulnerabilities. Back to "security supported architectures: tl;dr Security project wants to remove "security supported architectures" for years. Any architecture in Gentoo which is carrying stable keywords must keep up with stabilization or keyword requests. Security stabilization shouldn't be treated special (Because new ebuilds often depend on recent libs. If an arch team would only focus on security bugs, calling for stabilization will become more difficult because we would have to add all the missing deps which are now required but already stable everywhere else and just ignored by this arch until today). If an architecture can no longer keep up with stabilization/keywording demand, the entire architecture must be dropped to ~arch. No exception. Stop pretending that this architecture is in good shape and that those users have the same stable experience like you have on more common architectures. Keep in mind: You would also need to explain a user, "Yeah, you are using something we name 'stable' but it doesn't mean what you are expecting and BTW, while we have said we have fixed vulnerability X in Gentoo you heard about in the media, don't forget to check on your own if this is also true for your architecture because in theory the maintainer could have decided to make use of arch-depending eapply for some reason..." => Keep it simple: Stable should mean the same across all architectures -- Regards, Thomas Deutschmann / Gentoo Security Team fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
signature.asc
Description: OpenPGP digital signature
