| 1 |
On Thu, Mar 18, 2004 at 03:28:08PM +0100 or thereabouts, Koon wrote: |
| 2 |
> OK, so the process (and groups in charge) is : |
| 3 |
> |
| 4 |
> - Vulnerability is found, posted on specific software announce lists |
| 5 |
> and/or general purpose security-lists) |
| 6 |
> - User A that reads these groups posts a bugzilla entry |
| 7 |
> - Developer/User B submits corrective ebuild on bugzilla |
| 8 |
> - Developer C tests/inserts ebuild in official ~tree(s) |
| 9 |
> - Developer D pushes ebuild in official stable tree(s) |
| 10 |
> - SecurityGuy E writes a GLSA |
| 11 |
> - SecurityChief F approves GLSA for posting |
| 12 |
> |
| 13 |
> Where is the shortage in manpower ? From what you say I deduce you need |
| 14 |
> more of the "E" type, but are we sure there is not too much delay in the |
| 15 |
> "B" "C" or "D" steps ? Should the "E" guy have authority to motivate the |
| 16 |
> "C" and "D" guys ? |
| 17 |
|
| 18 |
That flow is largely correct, except SecurityGuy E is riding herd on |
| 19 |
Developer B, C and D to get the stuff patched. SecurityGuy E acts as an |
| 20 |
overall coordinator for that particular GLSA. They keep track of all the |
| 21 |
other bits and pieces so they should know at any given time what the status |
| 22 |
of that GLSA is. |
| 23 |
|
| 24 |
> >Kernel GLSAs are difficult because we can't release the GLSA until all our |
| 25 |
> >kernels have been patched. |
| 26 |
> |
| 27 |
> That's because you want the GLSA to address the whole problems and not |
| 28 |
> only parts of it. In the case of the latest kernel flaw, everyone had to |
| 29 |
> wait 2 weeks for a GLSA while the corrected vanilla kernels were out the |
| 30 |
> same day as vulnerability disclosure and most other corrected kernels |
| 31 |
> were out two days after. |
| 32 |
> |
| 33 |
> Maybe we should consider releasing multiple GLSAs for the same problem. |
| 34 |
> In the case of the latest kernel flaw, a GLSA describing a fix (using |
| 35 |
> vanilla kernels) and a workaround (apply the following patch to your |
| 36 |
> current kernel) could have been out very fast, and a second more |
| 37 |
> comprehensive GLSA treating all other sources could have wait. This way |
| 38 |
> everyone would have known of the problem, known how to avoid it, and |
| 39 |
> known that a second GLSA would be issued on the subject for final |
| 40 |
> resolution. |
| 41 |
|
| 42 |
A valid point and something that I forwarded on to the security team. I |
| 43 |
don't like the idea of multiple GLSAs, but I do think we should release |
| 44 |
different revisions of the same GLSA. |
| 45 |
|
| 46 |
--kurt |
Archives