Stable kernel 2.6.25.11

I hate to see angry messages on LWN.net (although I have to admit that, even while angry, the
current posters are making more useful points than I see on most other web fora).

I like the note at the top of the LWN.net comment editor page: "Please try to be polite,
respectful, and informative".

Let me point out that this isn't so much an issue of Good vs. Evil as much as a question of
different people having different needs.  The Linux kernel does a fine job of evolving
quickly, supporting lots of hardware, improving the common cases of performance issues, and so
forth.  There are plenty of people whose security needs can be aptly summed up as "Whatever my
distribution and the Linux core team think is best is probably good enough.".  Those people
have no need for more specific information about vulnerabilities, and would not be able to use
that information if they had it.  Perhaps they are using Linux exclusively on non-networked,
single-user jobs, for example.

It's not that those people *ought* to value specific security vulnerability disclosures more
than they do -- it's just that they personally have no need of such disclosures.

On the other hand there are people who do need more specific information.  They may be
responsible for networked, multi-user Linux installations with great value at stake, for
example.  They may need, and know how to use, vulnerability disclosures in precise detail as
to the window of vulnerability and how to fix or workaround each issue.  As far as I currently
understand it, those people are not being served.

Now again, this isn't a matter of Good vs. Evil.  Linus, and GregKH, and the rest of the Linux
folks have no moral obligation to provide what those folks need.  If Linus and company care to
start providing it, that would be fine.  If not, then perhaps someone else (such as PaXTeam
and his partners) would provide that information about Linux, or perhaps those users would be
better off if they switched from Linux to Solaris or OpenBSD or something.

But again, for the third time, those users switching from Linux to Solaris or OpenBSD or
something would not be an Evil.  The world would not become a worse place.  Indeed, if the
maintainers of those other operating systems were better prepared to provide the kind of
service that those users need, then the world would be a better place.

For what it is worth I have worked in computer security for a long time, and for years I
tended to assume that my peers who insisted on running only OpenBSD or FreeBSD and refused to
rely on Linux for security were just being show-offs.  Nowadays I'm beginning to think that
they had justification for their choice.

Regards,

Zooko

P.S.  Just to make sure everyone got the point, if it is true, as I just alleged, that many
open-source-loving computer security professionals refuse to trust Linux's security, then this
is not Evil.  It's no big deal.  They get along fine in their jobs and you get along fine in
yours, so when replying to this note, please try to be polite, respectful, and informative.

[lame sarcastic stuff]

> There are reasons certain fixes get included in the -stable tree.  They
> are aware of these reasons, and the only thing preventing them from
> informing others of these reasons is their own will to do so.  We're
> asking them to simply be honest about what was fixed.  When they know
> it's a possibly exploitable overflow, they should just say so.  Now,
> should all these vendors profiting off Linux and its appearance of
> security (which given Linus' recent statements, I think the public
> should be strongly reconsidering) actually maybe form a group of actual
> security professionals to handle this kind of stuff, instead of
> continuing to say "hey don't be so harsh, we're just really awful at
> this sort of thing...but Linux is still enterprise-grade!"?

Here is an exercise.

Get 2.6.25 => 2.6.26 changelogs and patches.

Write down bugs (just bugs) which make sense to apply to 2.6.25.
To apply in logical sense, not in patch(1) sense.

Scratch those which are already in -stable.

Now extract those which are security-relevant.

Do the same for, say, OpenBSD 4.2 => 4.3.

Do the same for Windows (OK, this is a joke).

Enlightment will come pretty quickly.

> Just as an obvious example to show how incredibly stupid your
> explanation of "logical implications", the fact that the PaX team has
> been pointing out suspicious and exploitable vulnerabilities in each of
> the past half-dozen -stable releases

> hasn't seemed to impact the speed
> of kernel development one iota, let alone "devastate" it.  As evidenced
> by several comments on this posting already, people appreciate having
> this information available.

This is something I can't personally understand.

Do those people need word "security" or "buffer overflow" in changelog and
announcement to start kernel upgrade machinery? Given how many commits
don't even reach -stable for PaX guy to whine, they live in some rosy universe.

Not even mentioning occasional incomplete and flatly wrong information
in CVE database.

> I think that view will become even more
> common once people read what Linus is saying (that he doesn't think
> people should be informed of security issues and that the vendors, the
> only people doing such informing, are doing a "crappy" job of it and
> only disclosing a small percentage of vulnerabilities) and realize what
> Linux kernel security in particular is passing for these days.

grsecurity will save us, no worries about that.

Nice snark. Still, it was unnecessary: oddly, I do know what text editors 
are.

However, the fact remains that editing the patch commit logs isn't done 
unless necessary, and the stable tree maintainers don't think that 
researching possible security implications, getting CVE info and so on is 
a good use of their time. In the absence of their doing this, the only way 
to enforce 'CVE info on everything' as you seem to want is the 
development-speed-devastating scheme I outlined two messages up. Of 
*course* this crazy scheme hasn't been adopted or even proposed, but that 
is the only way to do what you suggest as long as the stable team's job 
remains cherry-picking and applying patches that others write, rather than 
actually modifying the commit logs, and the stable team have said that 
this is what they consider their purpose to be.