> Willy, please do read the previous discussion before commenting.
I did, and I do not agree with what was said, it is exagerated.
> problem isn't that people are unable to determine whether a given bug
> has a security impact or not. that is a separate issue and is not the
> point raised now. the problem we exposed is that of covering up security
> impact information when it *is* already known to the kernel developers.
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. I don't share his opinion here, but that's
personal taste, and after all, it's *his* project.
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. OK Linus tends to go to extremes (and believe me, it's
hard for -stable and I to follow those bugs). But I don't think there are
many more people oversimplifying the commits in such circumstances.
Both -stable and I keep the original message when backporting, and look
for any existing CVE information then add it. I have already missed CVE
numbers before committing. It happens.
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.
What we agree about is not to divulgate information when joining the list.
That's the minimalist requirement you can expect from members who you will
send sensitive information. There are times you would like to shake a bit
the tree to get something to speed up, and you cannot. Those moments are
a bit frustrating, but you agreed about the initial rules. But I have
never seen anything there such as "hey shhht! don't tell anybody, let's
fix it silently". It's more like "pfff!! needs to be root anyway, not
> you're privy to that information yourself and in silent agreement with
> that policy, don't pretend you don't know (care to explain to the rest
> of the world that itanium hardware bug still unfixed after 2 years?).
As ruled above, I cannot explain this. However, I can paraphrase what
Brad already reported there : http://lwn.net/Articles/285928/
Basically, the fix was deemed wrong and needed some rework. Then no
time to work on it. I recently asked for news about the situation,
because I don't like a fix to remain pending, and response was
that the fix was wrong and not sufficient anyway because of the
reasons Brad already explained. If a fix cannot be developped,
game over! And please don't ask someone to publicly forward the
patch, it will only harm in helping exploitation without bringing
any value towards a possible fix.
Hint: I found the wrong fix is already present in at least one publically
downloadable distro kernel update.
> and where's the problem? you simply include the relevant info in the
> commit and let the users decide which ones they're interested in.
Believe it or not, it is already the hardest part of my work, determining
the relevant information. It is no different than any bug tracking for any
software, people ask for tests, some seem valid and point to one direction,
some seem invalid, some tracks are finally proven wrong. It's very hard to
build a relevant commit message. Sometimes when I read Linus' commits, I
think "oh he's abusing..." but when I try to do the work myself, I
sometimes wonder why I take 30 minutes to try to collect relevant
information to build a useful commit message when it could simply be
> current problem is that by omitting or obfuscating any such info makes
> it *impossible* to quickly select the interesting commits. you're not
> improving linux security by making it hard for users to make decisions.
I know that, believe me! And this is not limited to security impacts. I
regularly read random 2.6 commits to find if there are fixes relevant to
2.4 or stable. Sometimes I don't know. Sometimes I think I should merge
them, then someone explains me that I'm wrong because the bug cannot be
triggered in my situation.
And please, do not say "obfuscate" when speaking about commit logs,
it's more like "summarize", even if extreme summarization may lead to
> > Overall, I think the security issues are correctly taken by the middle
> > chain (2.4 and 2.6-stable),
> once again, to stress the point: no, they are *not* correctly handled.
> ask Chris Wright about
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.
> it doesn't get 'lost', it gets intentionally omitted. and it's not
> sometimes but pretty much every time now. case in point,
> knowing Ilja's past work, i can't imagine he didn't report this as a bug
> with security impact (not that it's hard to figure out even if he didn't)
> yet there's no mention of it in the commit, not to mention a backport to
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.
Don't get me wrong, I'm all about transparency, and we're not good enough
at this IMHO. But it is not *that* bad.
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. Or maybe you spend whole days at
this, in which case all users would benefit from your findings. Why don't
you post on LKML, to -stable or even on security lists links to the patches
you consider suspicious security-wise ? 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
For instance, people are slowly getting used to CC stable when releasing
a fix for an annoying bug. It still takes a lot of efforts to get those
bugs automatically submitted, but after about 2 years, people start to
educate themselves. If you regularly prove them wrong when they claim
that a bug has no security impact, they will more often ask for a second
opinion, or try to a bit more descriptive in their commits.
But you cannot expect too much from the people who already do this on their
minuscule spare time, really.