Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list
On Thu, Oct 21, 2021 at 10:05:20AM +0200, Michał Górny wrote: > Hello, > > Splitting from the discussion in [1] (moving more arhitectures to > ~arch), I'd like to propose that we remove the "security supported" > architecture list from [2] and instead level security support with > the general architecture support in Gentoo, e.g. by having all > architectures with stable profiles be "security supported". This will better align the written policy with what actually happens in reality, so I'm all for it! Thanks for bringing this up. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list
> On 21 Oct 2021, at 18:04, Aaron Bauman wrote: > > On Thu, Oct 21, 2021 at 10:05:20AM +0200, Micha=C5=82 G=C3=B3rny wrote: >> Hello, >> =20 >> Splitting from the discussion in [1] (moving more arhitectures to >> ~arch), I'd like to propose that we remove the "security supported" >> architecture list from [2] and instead level security support with >> the general architecture support in Gentoo, e.g. by having all >> architectures with stable profiles be "security supported". >> > > I fully support this approach and have long advocated for it. > > Overall, all stables arches should be security supported and if > they begin lagging behind they should be dropped to unstable. > > I am sure there are some nuances, but this is a great start. > > Let's do it! +1 for reasons you said + in the original proposal. We don't currently adhere to the stated policy verbatim anyway and I don't think it adds anything right now. best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list
> On 23 Oct 2021, at 14:40, Sam James wrote: > > > >> On 23 Oct 2021, at 02:55, Thomas Deutschmann wrote: >> >> On 2021-10-21 17:16, Mike Gilbert wrote: >>> On Thu, Oct 21, 2021 at 4:05 AM Michał Górny wrote: 4. In the end, Security team isn't really respecting this policy. In the end, this leads to absurdities like GLSA being released before a package is stable on amd64, and confusing the users [4]. >>> This is certainly an absurd mistake, but I think it is unrelated to >>> the topic of your message. It looks like Whissi jumped the gun on >>> releasing a GLSA, which could happen regardless of the policy. Am I >>> missing some context? >> >> Yeah, #4 is bullshit. >> > Well, it's not bullshit per se, it's just not consistent with the policy. We > should > update the policy to reflect real life. > > What I'd probably like us to do is have at least amd64 stable before > publishing in future (and if there's a reason amd64 can't be, we probably > can't/shouldn't stable on other arches anyway). ... additionally, even if we're not going to update the policy page (I don't see why we shouldn't), what exactly does this leave "security supported" meaning...? mgorny pointed this out already but there's no real point to having the designation: it makes no difference wrt cleanups and also no real difference to when we publish GLSAs either. > [...] > best, > sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list
> On 23 Oct 2021, at 02:55, Thomas Deutschmann wrote: > > On 2021-10-21 17:16, Mike Gilbert wrote: >> On Thu, Oct 21, 2021 at 4:05 AM Michał Górny wrote: >>> 4. In the end, Security team isn't really respecting this policy. >>> In the end, this leads to absurdities like GLSA being released before >>> a package is stable on amd64, and confusing the users [4]. >> This is certainly an absurd mistake, but I think it is unrelated to >> the topic of your message. It looks like Whissi jumped the gun on >> releasing a GLSA, which could happen regardless of the policy. Am I >> missing some context? > > Yeah, #4 is bullshit. > Well, it's not bullshit per se, it's just not consistent with the policy. We should update the policy to reflect real life. What I'd probably like us to do is have at least amd64 stable before publishing in future (and if there's a reason amd64 can't be, we probably can't/shouldn't stable on other arches anyway). > The security team was never happy with the situation to hold back GLSAs until > last architecture was marked stable. > > Saying that we are not respecting our own own policy is absurd. The team > discussed this in 2018 and we agreed that it is fine to already publish a > GLSA in case a GLSA is ready and when at least one major architecture (amd64 > or x86 at that time) was marked stable. That exception doesn't require a > formal policy update. > I don't get why this means we shouldn't just update the page..? > We even wanted to go one step further and release GLSA when no fixed version > is available at all to inform users and give them a chance to take actions on > their own (to be able to take actions on your own, i.e. you first need to be > aware of a problem). However, this would be too complicated and would > frustrate many users. Aye, although this would involve different instructions. > > The lived practice with releasing GLSA already when just one major > architecture has set stable keyword (and in most cases we covered amd64 and > x86 at release time) received good feedback and is accepted by users and > didn't cause any problems (can't remember that we ever got GLSA feedback for > other architectures than amd64 or x86). > best, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list
On 2021-10-21 17:16, Mike Gilbert wrote: On Thu, Oct 21, 2021 at 4:05 AM Michał Górny wrote: 4. In the end, Security team isn't really respecting this policy. In the end, this leads to absurdities like GLSA being released before a package is stable on amd64, and confusing the users [4]. This is certainly an absurd mistake, but I think it is unrelated to the topic of your message. It looks like Whissi jumped the gun on releasing a GLSA, which could happen regardless of the policy. Am I missing some context? Yeah, #4 is bullshit. The security team was never happy with the situation to hold back GLSAs until last architecture was marked stable. Saying that we are not respecting our own own policy is absurd. The team discussed this in 2018 and we agreed that it is fine to already publish a GLSA in case a GLSA is ready and when at least one major architecture (amd64 or x86 at that time) was marked stable. That exception doesn't require a formal policy update. We even wanted to go one step further and release GLSA when no fixed version is available at all to inform users and give them a chance to take actions on their own (to be able to take actions on your own, i.e. you first need to be aware of a problem). However, this would be too complicated and would frustrate many users. The lived practice with releasing GLSA already when just one major architecture has set stable keyword (and in most cases we covered amd64 and x86 at release time) received good feedback and is accepted by users and didn't cause any problems (can't remember that we ever got GLSA feedback for other architectures than amd64 or x86). -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list
On Thu, Oct 21, 2021 at 10:05:20AM +0200, Micha=C5=82 G=C3=B3rny wrote: > Hello, >=20 > Splitting from the discussion in [1] (moving more arhitectures to > ~arch), I'd like to propose that we remove the "security supported" > architecture list from [2] and instead level security support with > the general architecture support in Gentoo, e.g. by having all > architectures with stable profiles be "security supported". > I fully support this approach and have long advocated for it. Overall, all stables arches should be security supported and if they begin lagging behind they should be dropped to unstable. I am sure there are some nuances, but this is a great start. Let's do it! -Aaron
Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list
On Thu, Oct 21, 2021 at 4:05 AM Michał Górny wrote: > 4. In the end, Security team isn't really respecting this policy. > In the end, this leads to absurdities like GLSA being released before > a package is stable on amd64, and confusing the users [4]. This is certainly an absurd mistake, but I think it is unrelated to the topic of your message. It looks like Whissi jumped the gun on releasing a GLSA, which could happen regardless of the policy. Am I missing some context?
Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list
Hi Michał, I do agree with the gist of what you're saying, and in absence of a better solution I'm in support. I also make a disclaimer: I only use amd64 so none of this really affects me, so at the end of the day - I don't really care. We have tinderboxes already running that does all kinds of testing for amd64 and specifically, both musl and glibc as far as I'm aware. This could be trivially extended to x86 by way of chroot I believe. Given emulators I believe it's also possible to extend this to other arches at somewhat crazy CPU overhead costs, and I'm not convinced of the reliability of these emulators vs real hardware but for the purposes of this discussion it may be a moot point (if it works on the emulator it's more likely to work on real hardware than the other way around). Given the work on nattka, is it possible that nattka could be extended, in collaboration with he tinder hosts to submit a specific package for compile testing? Specifically for security (and possibly stablereq) bugs I'm thinking have the tinderboxes do the compile tests, as requested by nattka, and then once amd64 and possibly x86 has confirmed, give the security team the option to force stable on the other arches? This may seem to be more controversial than dropping stable for those arches, however, consider that ~arch just gets marked anyway, so frankly, we're no worse off than with dropping stable for these arches. The point of controversy is that we're taking out a testing point for packages, and by implication, control as well as responsibility away from the arch teams. I'm also wondering about the overall stabilisation process. To be frank: A LOT of work is being handed over to the arch teams. I'm not against this, but could we possibly come up with a better way? Specifically, if anyone can request a stable request for an arch, and the package maintainer can OK that within certain rules and constraints (system enforced, with arch teams allowed to violate that, so if a package manager can motivate why then arch can overrule). So in essence: 1. Anyone can request stable for an arch on a package. 2. Package maintainer does first ACK (or automatic after a time delay and additional parties has requested?) 3. Tinderbox for compile tests (At least -* and * on the package itself, ideally with "-* single" as well, and any other USE flags as required by single ... this will burn a lot of CPU, which is arguably better than developer time). 4. If there are tests, run these too, and if they all pass, proceed to stable. 5. If there are not tests ... ? Anyway, just some thoughts, hoping to spark some ideas. At the end of the day I agree with Michał (as I read his message) - differentiation between stable supported and security supported doesn't make sense. Kind Regards, Jaco On 2021/10/21 10:05, Michał Górny wrote: > Hello, > > Splitting from the discussion in [1] (moving more arhitectures to > ~arch), I'd like to propose that we remove the "security supported" > architecture list from [2] and instead level security support with > the general architecture support in Gentoo, e.g. by having all > architectures with stable profiles be "security supported". > > Rationale: > > 1. The architecture list seems to date way back and doesn't seem to have > been maintained properly. According to CVS history, the last time a new > architecture was marked "supported" was in 2005; since then, > architectures were only removed. After the migration to new website, > the points of contact for architectures aren't even listed anymore. > The presence of 'ppc' on the list is doubtful at best. At the same > time, 'arm64' is not supported. > > 2. Keeping a separate list can cause confusion, if not make users of > architectures such as arm64 feel belittled. I don't really see why > the Security team should be overriding the overall Gentoo architecture > support status. > > 3. Per the policy, Security team "will not wait for a stable fix on > these arches before issuing the GLSA and closing the bug". The former > I don't have a problem with but how could you close the bug before > cleaning up old versions, and how would you clean up the old versions > when the new ones aren't stable yet everywhere? > > 4. In the end, Security team isn't really respecting this policy. > In the end, this leads to absurdities like GLSA being released before > a package is stable on amd64, and confusing the users [4]. > > While I agree we could probably establish some criteria when GLSAs > should be released, the current policy is incorrect and obsolete. In my > opinion removing the list is the first step towards cleaning stuff up. > > > [1] > https://archives.gentoo.org/gentoo-dev/message/fd18905401a1aec78aa6af7238f5ca1c > [2] > https://www.gentoo.org/support/security/vulnerability-treatment-policy.html > [3] > https://gitweb.gentoo.org/archive/proj/gentoo.git/log/xml/htdocs/proj/en/security/index.xml > [4] https://bugs.gentoo.org/789240#c2 >
