1 |
On 18.01.2014 18:38, Pacho Ramos wrote: |
2 |
> […] |
3 |
> |
4 |
> Then, how are you finally going to fix this? |
5 |
|
6 |
Thank you for finally showing interest in anything we do. Here is how we |
7 |
are 'finally' going to fix this. |
8 |
|
9 |
> Only for knowing, I still |
10 |
> was seeing some delays and, then, I though situation was not improved. |
11 |
> For example, since this year started, I have only seen 8 GLSAs filled: |
12 |
> http://www.gentoo.org/security/en/glsa/ |
13 |
|
14 |
Er, we're 18 days in… |
15 |
|
16 |
You shouldn't look at this purely by the numbers, you should see that we |
17 |
have now again a steady stream of advisories going not. No gaps like |
18 |
from 2013-01 to 2013-07. That is largely the effort of the |
19 |
recently-joined members. |
20 |
|
21 |
> |
22 |
> Then, I thought something was still wrong as that rate didn't seem |
23 |
> enough to me for handling upcoming security issues and the really old |
24 |
> ones. Also, if you that 8 GLSAs, you will see the only one that has been |
25 |
> done in a fast way is the ntp one, the other 7 took months (or years) to |
26 |
> be handled. |
27 |
|
28 |
So you observed correctly there's still plenty of delays. There are |
29 |
three parts to an advisory that take time: |
30 |
- Drafting: Collecting information, linking references, getting package |
31 |
versions done right (slots are a huge pain still). |
32 |
|
33 |
- Reviewing: Our current process asks for two independent positive |
34 |
reviews from other team members before an advisory can be sent. |
35 |
|
36 |
- Sending: The original author gets a .txt to email and have to check in |
37 |
the .xml to CVS. |
38 |
|
39 |
Going through these three steps requires at least three people, and the |
40 |
(group of) people whose action is required shifts twice. That overall |
41 |
process is spot #1 we are planning to improve. The current plan contains |
42 |
requiring only one review and the reviewer sends the advisory directly. |
43 |
So we go from author -> reviewer 1 -> reviewer 2 -> author to just |
44 |
author -> reviewer. |
45 |
|
46 |
Concerning the single steps here are other measures: |
47 |
- Drafting: Implement a new GLSA format to |
48 |
* reduce the amount of editorial text written by us |
49 |
* support slots (makes specifying vulnerable ranges in slotted package |
50 |
much easier) |
51 |
* (cleanup old stuff no longer needed) |
52 |
|
53 |
- Reviewing: Reduced editorial text means less to review. |
54 |
|
55 |
- Sending: We want to improve our tooling to automatically send |
56 |
advisories and push them to a git repository. |
57 |
|
58 |
The new GLSA format was up for review on -security last week. Next up |
59 |
will be getting it specified formally, implemented in our tooling, |
60 |
glsa-check and a new security.g.o frontend. [1] |
61 |
Then, we can adopt the new workflow. |
62 |
|
63 |
> |
64 |
> Then, instead of blaming on how should I have asked for clarification on |
65 |
> this (well, looks like the main topic here is that I have asked about |
66 |
> this in ML instead of the real problem :O), I think you should focus on |
67 |
> explaining how are you fixing this problem. |
68 |
|
69 |
Your original email didn't reflect actual interest in the details. Now |
70 |
that we've established you do care, I hope my explanations helped you |
71 |
out there. |
72 |
|
73 |
> I have been long time wondering about this because: |
74 |
> 1. I usually get lots of bugs from alias I am a member whose we go fast |
75 |
> bumping, calling for stabilization and dropping vulnerable versions and, |
76 |
> the, the bugs get stalled. |
77 |
> 2. Once of the machines I maintain would benefit from being able to use |
78 |
> glsacheck to only update vulnerable packages as not always have enough |
79 |
> time for updating the full world |
80 |
> |
81 |
> |
82 |
> |
83 |
|
84 |
[1] Lots of code to be written here. .py+.rb, help wanted! |
85 |
|
86 |
-- |
87 |
Alex Legler <a3li@g.o> |
88 |
Gentoo Security/Ruby/Infrastructure |