1 |
On Tue, Dec 04, 2018 at 12:39:07AM +0000, M. J. Everitt wrote: |
2 |
> On 04/12/18 00:16, Aaron Bauman wrote: |
3 |
> >> On 25.11.2018 15:31, Mart Raudsepp wrote: |
4 |
> >>> In two weeks from now, there will be a council meeting again. Now is |
5 |
> >>> the time to raise and prepare agenda items that you want us to discuss |
6 |
> >>> and/or vote upon. |
7 |
> >>> |
8 |
> >>> Please respond to this message on the gentoo-project mailing list with |
9 |
> >>> agenda items. |
10 |
> >>> The final agenda will be sent out on 2018-12-02, so please make sure |
11 |
> >>> you post any agenda items before that, or we may not be able to |
12 |
> >>> accommodate it into the next meeting. |
13 |
> >>> |
14 |
> >>> The meeting itself will happen on 2018-12-09 19:00 UTC [1] in the |
15 |
> >>> #gentoo-council FreeNode IRC channel. |
16 |
> >>> |
17 |
> >>> |
18 |
> >>> 1. https://www.timeanddate.com/worldclock/fixedtime.html?iso=20181209T19 |
19 |
> >>> |
20 |
> >>> |
21 |
> >>> Thanks, |
22 |
> >>> Mart Raudsepp |
23 |
> > I would like to propose, once again, that the council vote on the |
24 |
> > following items: |
25 |
> > |
26 |
> > 1. The council approves all architectures that are maintained as stable |
27 |
> > architectures. |
28 |
> > - e.g. alpha, amd64, arm, arm64, ia64, ppc, ppc64, and x86. |
29 |
> > |
30 |
> > Conversely, the council also may remove/drop such architectures as |
31 |
> > needed (c.f. item 2). |
32 |
> > |
33 |
> > 2. The council approves that all stable architectures are subsequently |
34 |
> > determined to be security supported. Thus, an architecture may not be |
35 |
> > stable and *not* security supported. This disparity has implications in |
36 |
> > processes and timeliness of actions taken to mitigate vulnerabilities |
37 |
> > reported. |
38 |
> > - e.g. amd64 is approved as stable arch and thus is security supported. |
39 |
> > - e.g. arm is dropped as a stable arch thus is no longer security supported. |
40 |
> > |
41 |
> > Overall, both of these items will provide a much clearer understanding |
42 |
> > of how security is able to proceed with mitigating vulnerabilities in |
43 |
> > the tree, how users view and understand what architectures are stable |
44 |
> > and security supported, and allow the security team and maintainers a |
45 |
> > clearer/cleaner process to follow. |
46 |
> > |
47 |
> > Standing by to answer RFI's. |
48 |
> > |
49 |
> > -- |
50 |
> > Cheers, |
51 |
> > Aaron |
52 |
> By all means correct me if I'm wrong, but my understanding was that a |
53 |
> stable *arch* meant that there was a consistent dependency tree, and this |
54 |
> was maintained to ensure there was some integrity to that arch's packages. |
55 |
|
56 |
Correct. Which directly correlates to how the security team and |
57 |
maintainers are able to proceed with security related matters. Very |
58 |
simply put: |
59 |
|
60 |
Vulnerability Identified->Package patched/bumped->Stabilization |
61 |
occurs->Vulnerable package (read... ebuild) is removed->GLSA issued if |
62 |
required->Bug closed. |
63 |
|
64 |
> It had/has nothing to do with security-supported which was another separate |
65 |
> classification entirely. |
66 |
> |
67 |
|
68 |
Correct. Historically, it has been treated separately, but due to the |
69 |
previous statement above it is quite interdependent. |
70 |
|
71 |
> I see merit in simplifying the categorisation of arch package sets, but I'm |
72 |
> not sure this particular change/proposal will serve much of a purpose, |
73 |
> other than further reinforcing that amd64 is the only arch that Gentoo |
74 |
> officially supports; and sets the wheels in motion for eventual bitrot of |
75 |
|
76 |
Our intent is not bitrot of any arch. Many "alt-arches" |
77 |
(uncommon/exotic... pick a description) keep up just fine... if not |
78 |
exceed more common arches. |
79 |
|
80 |
> anything else, streamlining the way for deprecation and treecleaning |
81 |
> anything which is not relevant for amd64 arch. |
82 |
> Please clarify that this is not, and will not be the case with this |
83 |
> policy/proposal. |
84 |
> |
85 |
|
86 |
This is *not* the case and will never be the case for this proposal. I |
87 |
don't believe anyone would vote/recommend such a thing if an arch is |
88 |
capable of being supported. |
89 |
|
90 |
-- |
91 |
Cheers, |
92 |
Aaron |