1 |
On Fri, Dec 16, 2016 at 9:04 AM, Kristian Fiskerstrand <k_f@g.o> wrote: |
2 |
> On 12/16/2016 02:57 PM, Ciaran McCreesh wrote: |
3 |
>> On Fri, 16 Dec 2016 13:25:14 +0100 |
4 |
>> Thomas Deutschmann <whissi@g.o> wrote: |
5 |
>> |
6 |
>> Perhaps it's time to realise that security bugs aren't that |
7 |
>> interesting, and that random data loss bugs and just plain missing |
8 |
>> features can be far more impactful in practice than some obscure |
9 |
>> security issue. All treating security bugs specially does is play into |
10 |
>> the "look at me, I'm important so you should pay me money or I'll put |
11 |
>> out another press release" drama certain consulting companies have set |
12 |
>> up. Broken code is broken whether or not the bug has been given a cute |
13 |
>> name and logo. |
14 |
>> |
15 |
> |
16 |
> Exactly, a security vulnerability originally being an info leak or a low |
17 |
> probability risk that turns out to a denial of service on a stable |
18 |
> system due to lack of proper stabilization is a good argument for the |
19 |
> way things are today. |
20 |
> |
21 |
|
22 |
We already have different risk tiers for security issues depending on impact: |
23 |
https://www.gentoo.org/support/security/vulnerability-treatment-policy.html |
24 |
|
25 |
That is why I suggested sending out the notice once the fix is |
26 |
available, or at the expiration of the target delay. For a |
27 |
trivial-class issue that would mean that a notice would only be sent |
28 |
out without a fix if it took over 40 days to resolve the problem. |
29 |
|
30 |
GLSAs are also marked with their severity/etc, so admins can use this |
31 |
information to make an informed decision about the risks of deploying |
32 |
an update out of cycle, or waiting for their normal testing cycle. |
33 |
|
34 |
Now, if we don't think that security is that important, then fine, |
35 |
let's at least update the security policy to make it clear to our |
36 |
users that we just treat remote network-only root code execution |
37 |
exploits the same as the latest vlc bump. Then our users will know |
38 |
that they aren't actually protected and will take additional measures |
39 |
if they feel it is necessary. |
40 |
|
41 |
What I don't like is a public security policy that says we do xyz |
42 |
within n days, and in reality we don't really do that and we take a |
43 |
lot longer to do it. That is giving users a false sense of security. |
44 |
|
45 |
Now, I get that upstream doesn't always release information on |
46 |
vulnerabilities, or even know about them. Sure, if you're trying to |
47 |
run the NSA you probably shouldn't solely rely on your distro's |
48 |
security update mechanism. People who REALLY care are going to |
49 |
subscribe to various services/etc to get intel on issues, or even do |
50 |
their own in-house research (if you're a major nation state). |
51 |
|
52 |
However, deploying fixes to known vulnerabilities just seems like a |
53 |
good practice. |
54 |
|
55 |
In any case, fixing the security policy to match reality costs |
56 |
nothing, and actually following it on the major archs shouldn't cost |
57 |
THAT much. |
58 |
|
59 |
-- |
60 |
Rich |