Gentoo Archives: gentoo-dev

From: Alex Legler <a3li@g.o>
To: gentoo-dev@l.g.o
Cc: security@g.o
Subject: Re: [gentoo-dev] Regarding long delays on GLSA generation
Date: Sat, 18 Jan 2014 18:19:27
In Reply to: Re: [gentoo-dev] Regarding long delays on GLSA generation by Pacho Ramos
1 On 18.01.2014 18:38, Pacho Ramos wrote:
2 > […]
3 >
4 > Then, how are you finally going to fix this?
6 Thank you for finally showing interest in anything we do. Here is how we
7 are 'finally' going to fix this.
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 >
14 Er, we're 18 days in…
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.
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.
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).
33 - Reviewing: Our current process asks for two independent positive
34 reviews from other team members before an advisory can be sent.
36 - Sending: The original author gets a .txt to email and have to check in
37 the .xml to CVS.
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.
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)
53 - Reviewing: Reduced editorial text means less to review.
55 - Sending: We want to improve our tooling to automatically send
56 advisories and push them to a git repository.
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.
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.
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.
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 >
84 [1] Lots of code to be written here. .py+.rb, help wanted!
86 --
87 Alex Legler <a3li@g.o>
88 Gentoo Security/Ruby/Infrastructure


Subject Author
Re: [gentoo-dev] Regarding long delays on GLSA generation Pacho Ramos <pacho@g.o>