1 |
El sáb, 18-01-2014 a las 19:19 +0100, Alex Legler escribió: |
2 |
[...] |
3 |
> So you observed correctly there's still plenty of delays. There are |
4 |
> three parts to an advisory that take time: |
5 |
> - Drafting: Collecting information, linking references, getting package |
6 |
> versions done right (slots are a huge pain still). |
7 |
> |
8 |
> - Reviewing: Our current process asks for two independent positive |
9 |
> reviews from other team members before an advisory can be sent. |
10 |
> |
11 |
> - Sending: The original author gets a .txt to email and have to check in |
12 |
> the .xml to CVS. |
13 |
> |
14 |
> Going through these three steps requires at least three people, and the |
15 |
> (group of) people whose action is required shifts twice. That overall |
16 |
> process is spot #1 we are planning to improve. The current plan contains |
17 |
> requiring only one review and the reviewer sends the advisory directly. |
18 |
> So we go from author -> reviewer 1 -> reviewer 2 -> author to just |
19 |
> author -> reviewer. |
20 |
|
21 |
This looks a nice improvement indeed :) |
22 |
|
23 |
> |
24 |
> Concerning the single steps here are other measures: |
25 |
> - Drafting: Implement a new GLSA format to |
26 |
> * reduce the amount of editorial text written by us |
27 |
> * support slots (makes specifying vulnerable ranges in slotted package |
28 |
> much easier) |
29 |
> * (cleanup old stuff no longer needed) |
30 |
|
31 |
That looks interesting as doing all the draft manually is really a huge |
32 |
work (with leads to not so enhancement). I am unsure how will the |
33 |
cleanup be done, as soon as the portage tree doesn't break (due some |
34 |
other package requiring the old buggy version), why are not all devs |
35 |
allowed to drop (or, at least, hardmask if needed for some base-system |
36 |
package :/) the vulnerable versions? Looks like currently security team |
37 |
waits for maintainers to do that, I try to do it fast but maybe will |
38 |
take much more time in other situations. I think this could be improved |
39 |
if other people like security team members or the last one stabilizing |
40 |
the fixed version could do the cleanup too. |
41 |
|
42 |
Also, currently looks like, when we (maintainers) get asked to bump the |
43 |
package fixing it, we tend to wait for security team members to CC |
44 |
arches, maybe the maintainers could do that directly to gain a bit of |
45 |
time. |
46 |
|
47 |
> |
48 |
> - Reviewing: Reduced editorial text means less to review. |
49 |
> |
50 |
> - Sending: We want to improve our tooling to automatically send |
51 |
> advisories and push them to a git repository. |
52 |
> |
53 |
> The new GLSA format was up for review on -security last week. Next up |
54 |
> will be getting it specified formally, implemented in our tooling, |
55 |
> glsa-check and a new security.g.o frontend. [1] |
56 |
> Then, we can adopt the new workflow. |
57 |
> |
58 |
> > |
59 |
> > Then, instead of blaming on how should I have asked for clarification on |
60 |
> > this (well, looks like the main topic here is that I have asked about |
61 |
> > this in ML instead of the real problem :O), I think you should focus on |
62 |
> > explaining how are you fixing this problem. |
63 |
> |
64 |
> Your original email didn't reflect actual interest in the details. Now |
65 |
> that we've established you do care, I hope my explanations helped you |
66 |
> out there. |
67 |
> |
68 |
|
69 |
They helped for sure :) and I appreciate them, I simply thought nothing |
70 |
was being worked out as I explained in previous mail (I was still saying |
71 |
long delays) |
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 |
> |