[Ksummit-2013-discuss] Topic Proposal: Handling Security Issues in the kernel

[Jiri Kosina]

On Fri, 9 Aug 2013, James Bottomley wrote:

> We seem to have reached the point in kernel development where "security"
> is the magic word to escape from any kind of due process (it is, in
> fact, starting to be used in much the same way the phrase "war on
> terror" is used to abrogate due process usually required by the US
> constitution).  A couple of recent example are:
> 
> http://lists.linuxfoundation.org/pipermail/ksummit-2013-discuss/2013-July/000116.html
> 
> and
> 
> http://marc.info/?l=linux-kernel&m=137549048712303
> 
> In both cases we had commits with cryptic messages, little explanation
> and practically no review all in the name of security.
> 
> Our core processes for accepting code require transparency, review and
> testing.  Secrecy in getting code into the kernel is therefore
> fundamentally breaking this and risking the kinds of problems we see in
> each of the instances.  

Thanks for bringing this up, James, I wouldn't have formulated this 
better.

I guess the counter-argument that will be coming would be that 
distributions are notified in time through the vendor-sec (or however it 
is called these days), but I fail to see why this is always getting 
related just to distros being able to release fixes for CVEs in time.

With my distro hat off, I'd really like all this stuff happen publicly, 
exactly because that is one of the biggest advantages and streghts of the 
linux kernel development model -- being open in order to allow for proper 
review of the code. Hiding facts doesn't bring anything good to the 
overall quality of the kernel code.

Thanks again,

-- 
Jiri Kosina
SUSE Labs