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