1 |
On Sat, Aug 27, 2011 at 4:49 AM, Christian Kauhaus <kc@××××××.com> wrote: |
2 |
> So in consequence I would appreciate to have both mechanisms: a timely |
3 |
> up-front notification via GLSAs (probably more brief than the past ones) and |
4 |
> some sort of security masking. |
5 |
|
6 |
The current GLSA mechanism already provides both of these. There are |
7 |
the email notifications, and there is an xml file that provides the |
8 |
masking information (which the glsa-checker tool and some package |
9 |
managers use). |
10 |
|
11 |
From what I've seen (from a distance), the problem seems to be that |
12 |
both of these are created using a software tool which is apparently |
13 |
very cumbersome to use. However, both are just text files. |
14 |
|
15 |
Part of me wonders if a workflow like this would help solve the problem: |
16 |
|
17 |
1. Some contributor posts a GLSA email and xml file to a security |
18 |
bug. This could be anybody. The content would be trimmed down a bit |
19 |
- perhaps just a CVE reference, and then the information on vulnerable |
20 |
and non-vulnerable versions. |
21 |
|
22 |
2. Somebody on staff with commit access to the xml tree and the |
23 |
mailing list would review and send out the advisory, and mark this as |
24 |
done in the bug. |
25 |
|
26 |
I also wonder if there would be in value in sending out the notice |
27 |
after the fixed version is in the tree but before it is stable. Right |
28 |
now advisories wait until the last security-supported arch stabilizes |
29 |
the package. I would think that earlier notice would be useful - even |
30 |
if sysadmins want to wait for a package to become stable they'll know |
31 |
something is coming, and the delay on the major arches tends to be |
32 |
hours to days. Plus, if somebody can't wait they can test/install on |
33 |
their own, and perhaps even post feedback on the bug. |
34 |
|
35 |
Obviously notices would have to wait until after any blackout period ends. |
36 |
|
37 |
Note that I'm basically advocating ditching the tool. A tool is good |
38 |
when it improves productivity. However, right now it appears that the |
39 |
tool is keeping people from contributing who want to contribute. |
40 |
Certainly things couldn't get worse without the tool. If a user just |
41 |
edits an xml template and email template and posts it on the bug, then |
42 |
very little work should be required to review the files before posting |
43 |
them. Contributors wouldn't need any special access either - freeing |
44 |
up devs to provide more of a QA role. |
45 |
|
46 |
Ditching the tool would also simplify fixes to GLSAs. I haven't run |
47 |
it in a while, but took glsa-checker out of my cron ages ago when it |
48 |
would just report packages with vulnerabilities that had none. I did |
49 |
log bugs, but apparently adding one line to the xml files requires as |
50 |
much pain as sending out the original notice. |
51 |
|
52 |
Bottom line, however, is I don't think that we can't consider |
53 |
ourselves as a serious distro if we don't provide timely security |
54 |
advisories. |
55 |
|
56 |
All that said, I would say that from what I've seen in bugzilla, if |
57 |
you're on x86 or amd64 and running an updated stable tree, you |
58 |
shouldn't have longstanding security vulnerabilities. A new security |
59 |
bug pops up almost weekly, and packages are updated fairly quickly on |
60 |
those arches. The problem is just that we never tell anybody that |
61 |
we're doing it. |
62 |
|
63 |
Rich |