The core issue [LWN.net]

The core issue

Posted Jun 17, 2008 11:50 UTC (Tue) by bojan (subscriber, #14302)
In reply to: The core issue by wtarreau
Parent article: Stable kernel 2.6.25.7 released

> If we want to be picky, everything which can permit a non-privileged user to cause a
malfunction resulting in a degradation of performance, integrity, availability,
confidentiality or traceability is a security issue.

Kernel is done for a wide audience and, as you mentioned, different people would like to know
about different types and severity of security problems. So, the best policy is just to
describe them all and let people (including distributors) decide if they want to bump up or
not.

In other words, if things are logged in such a way that even the pickiest of them are OK with
it, then the ones that are less picky will be OK too. Provided the information about the
security impact is known, of course.

(Log in to post comments)

It's done exactly in this way... in a sense

Posted Jun 17, 2008 17:08 UTC (Tue) by khim (subscriber, #9252) [Link]

So, the best policy is just to describe them all and let people (including distributors) decide if they want to bump up or not.

Better for whom exactly? There are exist one potential group which will be VERY negatively affected: top-level kernel developers (and to lesser extent all other kernel developers). For them detailed list of security implications in descriptions is unneeded noise, not something important. They look and review THOUSANDS of such descriptions each and every week so OF COURSE they want to reduce this noise. If issue looks severe enough - they keep it in description.

In other words, if things are logged in such a way that even the pickiest of them are OK with it, then the ones that are less picky will be OK too.

And the pickiest users are of course kernel developers - they want to avoid clutter in various typed of reports and so demand short and concise descriptions. So they remove unimportant (for them) parts. Including detailed descriptions of possible security implications. In all cases except the most severe ones. So in fact they did what you asked them to do - but somehow you are not satisfied.

Now if you think they go overboard in some cases - you can join the system and help to prevent this. If you want totally different style of commit messages (extensive with lots and lots of details) in general - you are free to fork the project and put any kind of descriptions you want.

It's done exactly in this way... in a sense

Posted Jun 17, 2008 21:54 UTC (Tue) by bojan (subscriber, #14302) [Link]

> Better for whom exactly?

For people trying to keep their systems secure?

Security issues are not noise, especially when people producing patches for them are already
aware of their nature.

> So they remove unimportant (for them) parts.

Yeah, that's kinda the problem. Even the most trivial of security issues may be important to
someone. Removing information about it puts users that may be affected at a disadvantage.

> If you want totally different style of commit messages (extensive with lots and lots of
details) in general - you are free to fork the project and put any kind of descriptions you
want.

So, mentioning in the release notes of .7 that some security issues have been addressed, which
would take less than 100 words, requires a kernel fork? I don't understand where all this
hostility is coming from.

If issues are known, release notes should specify that. It's that simple.