Re: [gentoo-security] Gentoo security policy

[Koon]

Kurt Lieber wrote:
> We need folks to monitor bugzilla for security-related postings and then
> push valid postings through the GLSA process.

OK, so the process (and groups in charge) is :

- Vulnerability is found, posted on specific software announce lists 
and/or general purpose security-lists)
- User A that reads these groups posts a bugzilla entry
- Developer/User B submits corrective ebuild on bugzilla
- Developer C tests/inserts ebuild in official ~tree(s)
- Developer D pushes ebuild in official stable tree(s)
- SecurityGuy E writes a GLSA
- SecurityChief F approves GLSA for posting

Where is the shortage in manpower ? From what you say I deduce you need 
more of the "E" type, but are we sure there is not too much delay in the 
"B" "C" or "D" steps ? Should the "E" guy have authority to motivate the 
"C" and "D" guys ?

I think I can help in the A and E steps, in software I follow for my own 
servers for example.

> Kernel GLSAs are difficult because we can't release the GLSA until all our
> kernels have been patched.

That's because you want the GLSA to address the whole problems and not 
only parts of it. In the case of the latest kernel flaw, everyone had to 
wait 2 weeks for a GLSA while the corrected vanilla kernels were out the 
same day as vulnerability disclosure and most other corrected kernels 
were out two days after.

Maybe we should consider releasing multiple GLSAs for the same problem. 
In the case of the latest kernel flaw, a GLSA describing a fix (using 
vanilla kernels) and a workaround (apply the following patch to your 
current kernel) could have been out very fast, and a second more 
comprehensive GLSA treating all other sources could have wait. This way 
everyone would have known of the problem, known how to avoid it, and 
known that a second GLSA would be issued on the subject for final 
resolution.

- Koon

--
gentoo-security@g.o mailing list