> That applies for every OS, if there isn't any maintenance done and bugs
> keep being discovered, it will become insecure.
> Just because in a few years the patch may not be so useful as it is now,
> is no reason to include it.
> Why bother porting to IA64 if we know the architecture will be obsolete in
> 10 years or so?
> It's useful NOW, so let's include it NOW.
It might be useful NOW, but WON'T BE when it is finally deployed.
> > I didn't say it doesn't. Just that I prefer to get a bind that is immune to
> > this kind of attacks than cores all over the place and a bind that doesn't
> > work because it is being probed from all over the planet.
> This kernelpatch will not repair bind.
Exactly. Fixing the buffer overflows does.
> However, it will, when properly configured, give you warnings about
> certain possible security issues in ANY userspace code run.
Like linking with latest glibc's, which complain if you use several unsafe
functions? Like grep(1)ing for said functions? That was what I used when I
checked out dip(8) a long while ago: I just fixed anything that looked
fishy. Turned out that that killed an exploitable buffer overflow, and
probably a few random reasons for SIGSEGVs too. I was _not_ out looking
specifically for holes, mind you. The cost of doing that is _much_ lower
than demanding patched kernels everywhere (the source for the server
software Linux uses does run on a few other systems too, you know), and it
fixes a lot more than just kiddie intrusions. I wouldn't trust any server
software that was not written with at least that much care.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/