| 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 |
Archives