Gentoo Archives: gentoo-dev

From: Jaco Kroon <jaco@××××××.za>
To: gentoo-dev@l.g.o, "Michał Górny" <mgorny@g.o>
Subject: Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list
Date: Thu, 21 Oct 2021 08:37:55
Message-Id: 4ca146b0-6419-0a36-7cb2-abc6d5b7d50a@uls.co.za
In Reply to: [gentoo-dev] [RFC] Removing separate "security supported" arch list by "Michał Górny"
1 Hi Michał,
2
3 I do agree with the gist of what you're saying, and in absence of a
4 better solution I'm in support.
5
6 I also make a disclaimer:  I only use amd64 so none of this really
7 affects me, so at the end of the day - I don't really care.
8
9 We have tinderboxes already running that does all kinds of testing for
10 amd64 and specifically, both musl and glibc as far as I'm aware.  This
11 could be trivially extended to x86 by way of chroot I believe.
12
13 Given emulators I believe it's also possible to extend this to other
14 arches at somewhat crazy CPU overhead costs, and I'm not convinced of
15 the reliability of these emulators vs real hardware but for the purposes
16 of this discussion it may be a moot point (if it works on the emulator
17 it's more likely to work on real hardware than the other way around).
18
19 Given the work on nattka, is it possible that nattka could be extended,
20 in collaboration with he tinder hosts to submit a specific package for
21 compile testing?  Specifically for security (and possibly stablereq)
22 bugs I'm thinking have the tinderboxes do the compile tests, as
23 requested by nattka, and then once amd64 and possibly x86 has confirmed,
24 give the security team the option to force stable on the other arches?
25
26 This may seem to be more controversial than dropping stable for those
27 arches, however, consider that ~arch just gets marked anyway, so
28 frankly, we're no worse off than with dropping stable for these arches. 
29 The point of controversy is that we're taking out a testing point for
30 packages, and by implication, control as well as responsibility away
31 from the arch teams.
32
33 I'm also wondering about the overall stabilisation process.  To be
34 frank:  A LOT of work is being handed over to the arch teams.  I'm not
35 against this, but could we possibly come up with a better way? 
36 Specifically, if anyone can request a stable request for an arch, and
37 the package maintainer can OK that within certain rules and constraints
38 (system enforced, with arch teams allowed to violate that, so if a
39 package manager can motivate why then arch can overrule).  So in essence:
40
41 1.  Anyone can request stable for an arch on a package.
42 2.  Package maintainer does first ACK (or automatic after a time delay
43 and additional parties has requested?)
44 3.  Tinderbox for compile tests (At least -* and * on the package
45 itself, ideally with "-* single" as well, and any other USE flags as
46 required by single ... this will burn a lot of CPU, which is arguably
47 better than developer time).
48 4.  If there are tests, run these too, and if they all pass, proceed to
49 stable.
50 5.  If there are not tests ... ?
51
52 Anyway, just some thoughts, hoping to spark some ideas.  At the end of
53 the day I agree with Michał (as I read his message) - differentiation
54 between stable supported and security supported doesn't make sense.
55
56 Kind Regards,
57 Jaco
58
59 On 2021/10/21 10:05, Michał Górny wrote:
60
61 > Hello,
62 >
63 > Splitting from the discussion in [1] (moving more arhitectures to
64 > ~arch), I'd like to propose that we remove the "security supported"
65 > architecture list from [2] and instead level security support with
66 > the general architecture support in Gentoo, e.g. by having all
67 > architectures with stable profiles be "security supported".
68 >
69 > Rationale:
70 >
71 > 1. The architecture list seems to date way back and doesn't seem to have
72 > been maintained properly. According to CVS history, the last time a new
73 > architecture was marked "supported" was in 2005; since then,
74 > architectures were only removed. After the migration to new website,
75 > the points of contact for architectures aren't even listed anymore.
76 > The presence of 'ppc' on the list is doubtful at best. At the same
77 > time, 'arm64' is not supported.
78 >
79 > 2. Keeping a separate list can cause confusion, if not make users of
80 > architectures such as arm64 feel belittled. I don't really see why
81 > the Security team should be overriding the overall Gentoo architecture
82 > support status.
83 >
84 > 3. Per the policy, Security team "will not wait for a stable fix on
85 > these arches before issuing the GLSA and closing the bug". The former
86 > I don't have a problem with but how could you close the bug before
87 > cleaning up old versions, and how would you clean up the old versions
88 > when the new ones aren't stable yet everywhere?
89 >
90 > 4. In the end, Security team isn't really respecting this policy.
91 > In the end, this leads to absurdities like GLSA being released before
92 > a package is stable on amd64, and confusing the users [4].
93 >
94 > While I agree we could probably establish some criteria when GLSAs
95 > should be released, the current policy is incorrect and obsolete. In my
96 > opinion removing the list is the first step towards cleaning stuff up.
97 >
98 >
99 > [1] https://archives.gentoo.org/gentoo-dev/message/fd18905401a1aec78aa6af7238f5ca1c
100 > [2] https://www.gentoo.org/support/security/vulnerability-treatment-policy.html
101 > [3] https://gitweb.gentoo.org/archive/proj/gentoo.git/log/xml/htdocs/proj/en/security/index.xml
102 > [4] https://bugs.gentoo.org/789240#c2
103 >