On Wednesday 12:30 PM 8/20/2008, Jeff Rogers wrote:
I can very easily come up with a scenario that breaks your patched fastpath just as easily as the original, to which you can rightly say, "but why would you do it that way?". And you would be right.

Do it, then. This is the simplest example I've given that exhibits this bug:

    eval exec /some/external/program --output-file $tempfile
    ns_returnfile 200 text/plain $tempfile
    ns_unlink $tempfile

This is ALL that's required. No external meddling, no munging of file modification times, nothing else. Three lines of Tcl code. By all means, show me an example that defeats this patch that's anywhere near as simple as that.

And far, far more to the point: that's as NATURAL as that. I'd assert that that example code is perfectly intuitive--and right up to the point where I pointed out this bug in the first place, it would have been accepted without remark on this mailing list. *Now*, of course, serving anything but 5-year old files with ns_returnfile is proof that one should give up computers for a living, and not recognizing the holy contract we enter into with AOLserver when we invoke ns_returnfile that our files must continue to exist for at least one more second is a valid reason to contemplate suicide to end our worthless existence.

Look: we discovered a serious bug in AOLserver's fastpath caching mechanism that can cause both data corruption and information leakage. I've explained that bug carefully, in the face of confusion, obfuscation, and a continual stream of utterly unnecessary abuse. I've offered a tested patch that provides a minimal, correct-by-inspection, user-transparent, massive improvement over the current behavior, despite my near certainty (based on previous experience) that it'd just lead to another round of carping, finger-pointing, and refusal to accept that there's even a problem here in the first place. I've explained why the patch makes sense (and in fact addresses exactly the limitation that should have been considered when the fastpath caching mechanism was initially designed). I've responded to all serious concerns, respectfully and without returning any of the bile that's been sent my way.

For anyone who's serious about securing your installation, you have the patch now, and I'd strongly suggest that you apply it to your AOLserver sources. I'll still respond to serious concerns that don't just rehash the same excuses, but otherwise I'm done.

- John

AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to