SECURITY BUG IN INTERACTIVE UNIX SYSV386

[Erik Fortune]

>Anybody who is stuck writing programs in ANY computer language, including
>APL and C today is going to write code that has bugs in it. Period. ENd
>of story. No way around it. Programming is not YET an engineering 
>type of job. Should be. Ain't. Nobody knows how to make it so.

Re-read the original posting.   The poster wasn't complaining that
the bug existed.  He was complaining that ISC refused to acknowledge
and repair the bug once it was pointed out.   Having bugs in your
code is a part of life.  Refusing to fix a most heinous security hole
like this one is not acceptable.

>Heaping shit on the developers is NOT going to help anyone.

Agreed.  However, heaping truckloads of shit on whoever decided 
that this bug wasn't important to fix, *even though* AT&T had sent 
them a fix is a solemn duty.

>Of course, it is highly desirable for the developers of said bug to 
>provide a fix asap. AND to ensure they don't reintroduce it later on,
>and so on. 

Precisely the intent of the person who started this thread.   After
banging his head against interactive support for far longer than he
should have had to considering the severity of the bug, he decided to
try to embarass them into fixing it.   Looks like it's working.

BTW:
   Another poster compared this to Ford buying bad bolts, but the
analogy doesn't quite fit.   Let's restate it this way:
   Ford buys bad bolts from a bolt manufacturer.   The bolt manufacturer
and a customer both discover the bad bolts and try to get Ford to
replace them; Ford refuses, and continues to use the bolts that they
know to be defective.    I think the liability questions are a little
(say, two orders of magnitude) less fuzzy in this case.

-- Erik
   erik at gogoman.sf.ca