SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)

Valdis.Kletnieks at Valdis.Kletnieks at
Fri Mar 24 02:33:48 UTC 2006

On Thu, 23 Mar 2006 19:28:16 CST, Gadi Evron said:
> No offense Valdis, you know I both like you and consider you a friend,
> but if you (sendmail) can't take the heat and/or stand up to the task of
> being International Infrastructure, step down.

Heat we can take.  Whining we can't.

Did you have a *specific* suggestion as to how it could be done better, or
did you just feel the need to flame about how it was handled?

Specific things that you did *not* consider, as far as I can tell:

1) You don't, as far as I know, contribute anything to paying the salaries
of the people actually doing the coding, and who know the way the code works.
This means that a choice has to be made:

a) Handle it in a way that doesn't upset the people paying the bills, even if
the people who aren't paying the bills don't like it.

b) Finding somebody else to pay the bills.

c) Dumping it and finding a project that *does* pay the bills, and fix it
as a hobby rather than a full-time job.

d) Dump it, move on, and let somebody else who doesn't know the code as well
do it, possibly worse.

So Gadi, what do you suggest we do, keeping in mind that the guy who's actually
doing the work needs to pay his rent and buy groceries?

2) You're complaing about the huge size of the patch, *and* the fact it took a
month to get it done.  If you want it faster, you can either have less bugs
fixed, or less testing. Choose one. (Also, 2% code churn between releases is
*nothing*. Take a look at the Linux kernel sometime - it has a *far* higher
churn rate between releases that Linus is trying to keep on a 3-month

Steve Bellovin is right - these asynchronous events are a *pain* to debug,
because the human brain doesn't deal with race conditions very well.  I
mentioned a timer event issue in a previous note - that one took Claus and I a
good *six months* to debug and understand, and resulted in all of 3 or 4 lines
of code.  It was one that was not reproducible on command, only tripped a few
times a month, and by its nature never left any really useful state wreckage
behind.  Trying to attach a debugger or adding debugging instrumentation to the
code would change the timing, and as a result scare the bug back into hiding...

Yes, it could potentially have been 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <>

More information about the NANOG mailing list