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.
