Subject: Re: FreSSH
To: Nathan J. Williams <nathanw@wasabisystems.com>
From: Peter Seebach <seebs@plethora.net>
List: current-users
Date: 03/08/2002 00:53:22
In message <mtu8z938svv.fsf@kinki-sharyo.mit.edu>, "Nathan J. Williams" writes:
>seebs@plethora.net (Peter Seebach) writes:
>> I don't think I've had a bounds overflow problem in C in ten years. It's
>> just not that hard to avoid, *if* you understand what you're doing.
>1) I don't believe you. You are not infallible.
No, I'm not. However, so far as I can tell, my failures are generally much
cooler than bounds overflows. Bounds overflows are easy; if you allocate
static buffers, you check things.
You're welcome to go through my code and try to find bounds overflows. The
only programs I think are likely to have them are my "userfights" program
and my "grain game" program - both of which are '92 or earlier. :) I'll even
put a $20 bounty on the first bounds overflow in my "maintained" code.
http://www.plethora.net/~seebs/c/pkg-0.8.14.tar.gz
I'll be generous; anything but "grain.c" or "uf.c". If I were you, I'd start
on the dysfunctional minesweeper; I think I crashed it once. If you want a
typical target, look at the string library; it does self-allocating strings,
which do their own bounds checking in a half-dozen different ways.
>2) Even if I did, there are always worse programmers.
True.
>3) This should not be an issue of trust or faith. It should be an
> issue of enforced protection.
While I like the idea of a language trying to guarantee integrity, in the
end, you still need to do your own bounds checking; the alternative is still
always a problem, and you always need to remember that, some day, the compiler
will screw up.
So, this doesn't actually make the code any easier; it just means that you'll
have more core dumps and fewer exploits, in theory. (I don't know what
happens in practice, yet.)
-s