On Wed, 16 Jul 2008, pageexec@freemail.hu wrote:Actually, we disagree on one fundamental thing. We disagree on that single word: "relevant". I do not think it's helpful _or_ relevant to explicitly point out how to tigger a bug. It's very helpful and relevant when we're trying to chase the bug down, but once it is fixed, it becomes irrelevant. You think that explicitly pointing something out as a security issue is really important, so you think it's always "relevant". And I take mostly the opposite view. I think pointing it out is actually likely to be counter-productive. For example, the way I prefer to work is to have people send me and the kernel list a patch for a fix, and then in the very next email send (in private) an example exploit of the problem to the security mailing list (and that one goes to the private security list just because we don't want all the people at universities rushing in to test it). THAT is how things should work. Should I document the exploit in the commit message? Hell no. It's private for a reason, even if it's real information. It was real information for the developers to explain why a patch is needed, but once explained, it shouldn't be spread around unnecessarily. Linus --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Stephen Rothwell | Re: Announce: Linux-next (Or Andrew's dream :-)) |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 33/37] dccp: Initialisation framework for feature negotiation |
| Christoph Lameter | Network latency regressions from 2.6.22 to 2.6.29 |
