1 |
On 12/10/2016 02:09 PM, Mart Raudsepp wrote: |
2 |
> Ühel kenal päeval, R, 09.12.2016 kell 21:54, kirjutas Aaron Bauman: |
3 |
>> They must be connected, because we cannot properly clean the tree if |
4 |
>> they are not. Otherwise, we would break the dependency tree. As |
5 |
>> long |
6 |
>> as the packages are marked stable, we can somewhat ensure that users |
7 |
>> will not be exposed to vulnerable code, but not entirely. We cannot |
8 |
>> publish a GLSA if there is no stable upgrade path for the user |
9 |
>> either. |
10 |
>> Why would that be acceptable? Given a "dozen users will know what to |
11 |
>> do," then why build tooling for such a small audience? If they know |
12 |
>> what to do, then we should expect that they will know what to do |
13 |
>> without |
14 |
>> being a stable arch. |
15 |
>> |
16 |
>>> Or as a temporary measure propose the removal of these arches from |
17 |
>> the |
18 |
>>> list of security supported (I don't believe one of them is security |
19 |
>>> supported even now), and move back to security supported once the |
20 |
>>> process is more streamlined from the workflow efforts going into |
21 |
>> there |
22 |
>>> now. |
23 |
>>> |
24 |
>>> |
25 |
>> Aside from the above items, I think this proposal becomes confusing |
26 |
>> for |
27 |
>> the user. My arch is stable... but not security supported? |
28 |
> Yes. See your own documentation at |
29 |
> https://www.gentoo.org/support/security/vulnerability-treatment-policy.html |
30 |
> for a list of security supported architectures and documentation on |
31 |
> stabling of not security supported architectures must not be waited for |
32 |
> a stable fix to proceed. |
33 |
> |
34 |
> |
35 |
> Mart |
36 |
|
37 |
Yes, that is not up to date. In practice, as you can see through our |
38 |
bug reports, we still cover IA64 and arm due to the very reasons I have |
39 |
brought forth. |