1 |
On 05.12.2018 6:46, Virgil Dupras wrote: |
2 |
> On Tue, 4 Dec 2018 17:05:55 -0500 |
3 |
> Michael Orlitzky <mjo@g.o> wrote: |
4 |
> |
5 |
>> This is technically correct, but: how many users even know what a |
6 |
>> security-supported arch is? I would guess zero, to a decimal point or |
7 |
>> two. Where would I encounter that information in my daily life? |
8 |
>> |
9 |
>> If I pick up any software system that's run by professionals and that |
10 |
>> has a dedicated security team, my out-of-the-box assumption is that |
11 |
>> there aren't any known, glaring, and totally fixable security |
12 |
>> vulnerabilities being quietly handed to me. |
13 |
>> |
14 |
>> Having a stable arch that isn't security-supported is a meta-fail... we |
15 |
>> have a system that fails open by giving people something that looks like |
16 |
>> it should be safe and then (when it bites them) saying "but you didn't |
17 |
>> read the fine print!" It should be the other way around: they should |
18 |
>> have to read the fine print before they can use those arches. |
19 |
>> |
20 |
> I very much agree with this. If we end up deciding on keeping the |
21 |
> "supported arches" system, I would like to propose that we also add a |
22 |
> big red warning, on the download page of unsupported arches, that |
23 |
> states that this can't be considered secure and that links to our |
24 |
> Vulnerability Treatment Policy. |
25 |
> |
26 |
> I don't have arm systems anymore, but for a while I did and at the |
27 |
> time, I wasn't aware at all of this situation. That's not fun and we |
28 |
> probably have many arm users right now who are unknowingly running |
29 |
> insecure systems. |
30 |
> |
31 |
> Regards, |
32 |
> Virgil Dupras |
33 |
|
34 |
|
35 |
The "stable" definition within the security project is ridiculous and |
36 |
has to be clarified. |
37 |
|
38 |
Stable == "once stable arches are stabilised we can send a GLSA". It |
39 |
does not mean |
40 |
|
41 |
that so-called "security unstable" arches do not get stable updates. |