Re: RFC: Starting a stable kernel series off the 2.6 kernel

[Florian Weimer <fw@deneb.enyo.de>]

* Horst von Brand:

>> You mentioned security issues in your initial post.  I think it would
>> help immensely if security bugs would be documented properly (affected
>> versions, configuration requirements, attack range, loss type etc.)
>> when the bug is fixed, by someone who is familiar with the code.
>> (Currently, this information is scraped together mostly by security
>> folks, sometimes after considerable time has passed.)  Having a
>> central repository with this kind of information would enable vendors
>> and not-quite-vendors (people who have their own set of kernels for
>> their machines) to address more vulnerabilties promptly, including
>> less critical ones.
>
> I've fixed bugs which turned out to be security vulnerabilities. And I
> didn't know (or even care much) at the time. Finding out if some random bug
> has security implications, and exactly which ones/how much of a risk they
> pose is normally /much/ harder than to fix the bugs.

I know, it happens all the time: vulnerabilities are fixed because
they are bugs, and not because they are vulnerabilities.  It's
unfortunate if people are unnecessarily exposed to the vulnerability
(because they don't know about it and don't apply the fix as a result),
but it's better than carrying around the bug indefinitely.

But if there's considerable evidence that you might have fixed a
security bug, preserving this information (and other bits that are
immediately obvious to you as a developer, but not necessarily who
reviews the issue) seems worthwhile.  Maybe you don't want to put it
into the public commit message, but forwarding what you have to some
trusted group of volunteers would make sense.  The volunteers would
distill the information, add more data and assign a CVE if necessary,
and declassify the information as soon as the public is ready (in the
form of a short security advisory, like the ones you see for most
applications).

Does this sound too far-fetched?  Why don't you think this would be a
valuable service to all users, vanilla kernels or not?

> And rather pointless, after the fix is in.

It doesn't matter much if the fix is in the kernel.org tree, when I'm
supposed to use vendor kernels. 8-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/