Messages in this thread | | | Date | Thu, 13 Jan 2005 12:05:16 +0900 (JST) | Subject | Re: thoughts on kernel security issues | From | "David Blomberg" <> |
| |
Linus Torvalds said: > > > On Wed, 12 Jan 2005, Andrew Morton wrote: >> >> That sounds a bit over-the-top to me, sorry. > > Maybe a bit pointed, but the question is: would a user perhaps want to > know about a security fix a month earlier (knowing that bad people might > guess at it too), or want the security fix a month later (knowing that the > bad guys may well have known about the problem all the time _anyway_)? > > Being public is different from being known about. If vendor-sec knows > about it, I don't find it at all unbelievable that some spam-virus writer > might know about it too. > >> All of these are of exactly the same severity as the rlimit bug, >> and nobody cares, nobody is hurt. > > The fact is, 99% of the time, nobody really does care. > >> The fuss over the rlimit problem occurred simply because some external >> organisation chose to make a fuss over it. > > I agree. And if i thad been out in the open all the time, the fuss simply > would not have been there. > > I'm a big believer in _total_ openness. Accept the fact that bugs will > happen. Be open about them, and fix them as soon as possible. None of this > cloak-and-dagger stuff. > > Linus > Devils-advocate: Who is on the vendor-sec list? as I have started devloping a roll your own linux dsitro (as 100s of other have as well) who decides who is "approved" to hear about the fixes beforehand-what makes SuSE, and Red Hat more deserving than Bonzai) User Base? inhouse-developrs?. I agree with Linus-san openness is best all around. the rest is mostly politics.
-- David Blomberg dblomber@davelinux.com AIS, APS, ASE, CCNA, Linux+, LCA, LCP, LPI I, MCP, MCSA, MCSE, RHCE, Server+
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |