Stable kernel 2.6.25.7 released

Er, if the holes get exploited, of *course* there's a consequence. And if there's no
possibility that the holes would be exploited, then modifying the commit messages to conceal
the security-related nature of the commits makes no sense.

You're blatantly contradicting yourself now. I've had enough of this thread.

> Well, I know that Linus does not like to give too much information in
> the commits because he believes it will help the bad guys, reason why
> he does not add the methods to reproduce the problems nor the CVE when
> he does the commits himself.

that's obviously utter crap. the bad guys are smarter than him or any kernel contributor.
they'll spot the bugs *before* they do. they'll also spot the bugs in the commits regardless
of what the commit says. does anyone remember the collective bruhaha in the security world
when CVE-2006-2451 became public? IIRC, that was a full year after the original commit and
also a full year after at least two working private exploits for it. on a sidenote, IIRC, that
bug still isn't fixed properly, as soon as a sysadmin enables the suid coredump feature, it's
exploitable again.

but actually i don't care about his opinion. what i do care about is that his published
commitment to full disclosure matches what he actually does and that's where the problem is.
you see, withholding security impact information doesn't full disclosure make. you guys can't
have it both ways because the people relying on you expect you to hold up to that commitment
you made in Documentation/SecurityBugs and if you violate that promise, people will make wrong
decisions and innocent people may suffer as a result. so if you want to stick to withholding
security impact info from commits, say so and the world will adjust. but let me guess, that'd
also be bad PR and you don't like that part.

> You have to keep in mind that most often, a commit is a summary of 10-20
> mail exchanges with reproducers, tests and results. You cannot put all
> that in a commit.

that's a strawman Willy, noone asked for it. what we did ask for was inclusion of known
security impact details. it doesn't overflow anyone's mailbox or git repo if you include a
*single sentence* saying that this is a potentially exploitable buffer overflow or NULL deref
or whatever. people can grep for the keywords and make further judgements based on whatever
extra research they deem necessary (including asking the committer for more details). once
again, this info doesn't help the bad guys because they'll spot this regardless of how obscure
the commit message is.

> What I'm really sicked about is the accusations of "general agreement to
> deliberately hide security informations from commits". That's false IMHO,
> really. And in fact, examples given by Brad were on public lists, so that
> does not make any sense.

when you publicly commit to full disclosure, yet, by your own admission now, you don't
actually practice it, then what do you call that? i call that general (silent or otherwise)
agreement of all participants. after all, participation in handling the kernel security bugs
is voluntary, noone forces you or anyone else to do it against his better judgement. therefore
if you play ball there, you de facto accept the not-exactly-full-disclosure policy (you later
admit that regarding vendor-sec, except everyone knows that vendor-sec does not practice
full-disclosure so people don't build that expectation into their decision making processes).
do you understand the problem better now?

> What we agree about is not to divulgate information when joining the list.

that's not the whole truth. what you also agree to is full disclosure after the embargo. go
read Documentation/SecurityBugs if you don't believe me. do you admit that you don't actually
practice it? if you do, we can take the discussion further and figure out whether you want to
actually update Documentation/SecurityBugs or really adopt full-disclosure. if you don't,
we'll keep on exposing the fallacy because we have no other way to affect you and at the same
time help the world by letting them know that their security risk analysis processes are based
on false promises.

> But I have never seen anything there such as "hey shhht! don't tell
> anybody, let's fix it silently".

i quoted Paul Mackerras a few times now. what do you have to say about that quote? why would
someone practicing full disclosure even *ask* that question and then actually withhold the
more important security impact?

> [stuff about the itanium hw bug]
> If a fix cannot be developped, game over!

not true. did the FDIV or F00F bugs mean game over? i don't think so. last time i checked, the
world hadn't stopped back then. what did happen was a huge PR disaster for Intel (in part
because of the same coverup attempt they're doing again). and history is repeating itself,
except this time you guys are actively party to the coverup. you should all be ashamed and the
conscientous of you should have left the list the moment Intel first had asked you to keep
silent because they didn't feel like fixing the chips. something tells me that there's another
PR disaster in the making.

> Believe it or not, it is already the hardest part of my work, determining
> the relevant information.

this is another strawman Willy, as this should not be your work at all and noone asked for it.
what we do ask for is that if you guys learn about security impact information during the
course of bug examination, then you *do* include those details in the commit. noone is
expecting anyone to spend time on thorough bug impact analysis, most of you are not even
qualified for that, it's really hard and time consuming work (just look at this very thread
and see how i missed stuff ;). but, say, if you see a kernel stack overflow then you say so
and don't try to be creative by calling it 'copying overly long strings' and similar crap. of
course there's always the alternative of publicly admitting that you do not in fact want to
practice full disclosure. it won't look cool in PR events but you can at least sleep with
clear conscience.

> And please, do not say "obfuscate" when speaking about commit logs,
> it's more like "summarize", even if extreme summarization may lead to
> obfuscation.

sorry, but i have no better words when i see something like
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .
do you really call that 'summary'? i hope not.

> Could you elaborate please ? This fix is in Linus tree, and I don't see
> Chris in the sign chain. Did he report it first ? Also, I'm sorry, but
> I fail to see the security implications of this patch, eventhough seeing
> "ptrace_attach" catches my attention.

don't you think there's a reason you fail to see the security impact and that i cited this
particular commit? go ask Chris about the history of it, you'll be surprised. in short, this
*is* a local DoS, the kernel devs were provided proof-of-concept code *yet* Linus deliberately
did not include any of that information. then Chris deliberately omitted it from the -stable
commit as well. wild accusations? or the unbelievable truth? it's yours to find out and you
even know how.

> From what I have seen, this was finally judged as a non-issue since other
> checks are in place, which probably explains why you don't have it in
> stable. It is very often that fixes for supposedly real vulnerabilities
> finally end in mostly code cleanups.

it would have been nice to mention this in the commit as well.

> What amazes me, to be honnest, is the ability you have to spot patches in
> mainline that take a lot of time to other people. I'd love to know how
> you proceed, it would save me a lot of time.

uhm, there's nothing magical in this. i sometimes check the kernel shortlog looking for
potential conflicts with PaX and obviously my eyes catch sometimes other 'interesting' looking
commits which i then go and look at in detail.

> Or maybe you spend whole days at this, in which case all users would
> benefit from your findings.

not at all, as i said somewhere below, i do it on my free time, always have in fact. and these
days, i'm trying to actually spend my time on other things. but as long as i can't give PaX
away to a new crew, i'll have to have a look every now and then.

> Why don't you post on LKML, to -stable or even on security lists links
> to the patches you consider suspicious security-wise ?

what would that change? more flames, more excuses for why it's not a good idea to support the
bad guys, etc. and in the end, as i said above, that's not what i care about but rather the
consistency between the promise made to the public and the actual actions. i can't fix any of
that because it's not of my making.

> Even assuming everyone's honnest in the chain, and the other people
> considered the bug inoffensive when you think the contrary, you could
> educate people about your methods of discovering this.

that's a whole separate issue of figuring out that a bug has a security impact after the
commit. i'm afraid such research requires a full staff, and i'm not in the position to fund
anything like that. heck, i'm happy when i make ends meet here ;).

> 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.

Likewise. Obviously it would be nice if more things that were security holes got so labelled,
but short of educating everyone who commits anything to think in a suitably paranoid manner (a
nice long-term goal but ridiculous in the short term), I can't see any way in which this
problem could be instantly fixed, except if the people who *could* determine that particular
fixes fix security problems were to help with that.

But at least one of them (sorry Brad, mixed you up, it may be that only PaXTeam is alleging
some sort of widespread dishonesty conspiracy theory and you're merely alleging insufficient
paranoia, which I'd agree with) would apparently rather moan than help fix the problem.

What you've just said is that experts who spent their time reverse engineering a binary
firmware failed to find an easily exploitable method, but instead found a method that enabled
them to make money.  That is human nature.  What guarantees do I have that some linux
contributers don't deliberately introduce or obscure exploitable bugs so that they can profit
from them in some way?  The vast majority of other people who understand and find them are
likely to keep them to themselves, or sell them on.

If there is no accountability or transparency in how these serious flaws are dealt with,  no
incentives to disclose or not put them there in the first place, bad things will almost
certainly happen.  It's inevitable.  These corruptions happen in every other field, it's naive
to think they won't happen here.

Everything that is even remotely a "security" threat should be labeled as such.  If this makes
linux look bad when some smart researcher compares all the major OS' security by counting
publicly known flaws, so be it.  That is the incentive to not put them there in the first
place.  Hiding them is, at best, leading to a culture of complacency, and at worst an
indication of malice.

I salute spender and the PaX team for bringing these issues to the fore.  They have made a
considerable impact in the field of security,  when they speak it is worth listening.

it does *not* matter what that 'little time' is. that's because your *whole* argument is based
on a false assumption, namely that it's the kernel devs (or whoever reports a bug to them) who
are the *first* to find a given security bug. it's obvious that there's exactly one such
person in the world who can make that claim, and based on what resources kernel devs spend on
finding security bugs vs. the rest of the world does, it's easy to see that this one lucky guy
isn't one of the kernel devs. it then follows that you can't in general assume that the
security bugs found by kernel devs aren't already being exploited in the wild. it then also
follows that this 'hide the bugs from the bad guys' doesn't actually do that, but it does hide
them from honest but less knowledgable people who nevertheless still need to know about them
to be able to properly assess the risks of a given bug *themselves* (and what the kernel devs
think they can do better themselves - good luck proving that, if anything, they so far proved
the exact opposite).

> (Quibbling over the meanings of words only works if you know what the
> meanings of those words actually *are*.)

hear hear brother! and let me help you out while i'm at it:
http://dictionary.reference.com/search?q=malice . malice requires intent to harm another out
of hostility, or something like that, you're the native speaker, i'm sure you can interpret it
properly. now, the kernel devs did not actually want to do anything like that, they simply
wanted to save face and look better in statistics, or so. that's not malice, only dishonesty
(they did know what they committed to in Documentation/SecurityBugs and did violate that
promise).

> If something is accidental or unintentional it's not dishonest.

strawman warning ;)! the suppression of security info in the commits we pointed out as such
was neither accidental nor unintentional (nor malicious, just dishonest), so i have no idea
what you're talking about.