Re: Full Disclosure works, here's proof:

[smb () research att com (smb () research att com)]

         > If the reader believes that the holes originally exist as stated and
         > that SCO has made a good faith effort to fix them, it is sensible to
         > install the fixes even if it eventually turns out that a narrower
         > hole remains.  

         What if it turns out that they open an even bigger hole?  Im thinking 
         of binmail.

Yup.  Let me add some quotes from Fred Brooks' classic ``The Mythical Man-
Month''.  (Disclaimer:  I studied software engineering lo these many years
ago from Brooks.  And he's had a far greater effect on my thinking than
anyone else.)

        Betty Campbell, of MIT's Laboratory for Nuclear Science, points
        out an interesting cycle in the life of a particular release of a
        program....  Initially, old bugs found and solved in previous
        releases tend to reappear in a new release.  New functions of the
        new release turn out to have defects.  These things get shaken
        out, and all goes well for several months.  Then the bug rate
        begins to climb again...

        The fundamental problem with program maintenance is that fixing a
        defect has a substantial (20-50 percent) chance of introducing
        another.  So the whole process is two steps forward and one step
        back.

This was published about 20 years ago, btw.

Without expressing any opinion one way or another on full disclosure,
I will point out that it's quite rational to refrain from installing
patches if you don't think you're susceptible to the problem.  You
never know when you'll actually make things worse.

Let me give one relevant case in point.  I was one of the two people
most responsible for the general strategy of the System V pty allocator.
Our goal was to eliminate both the complexity and the security holes
present in the 4.3bsd version, such as the race conditions on setting
the ownership and modes of the slave device.  In my opinion, we succeeded.
But despite all our design efforts, and all our attention to subtle
timing flaws, we've all just heard that there was a bug in one particular
instantiation.  Furthermore, that bug -- though unquestionably involving
incorrect code on all releases -- only showed up as a security problem
when there was an interaction with totally unrelated operating system
design decisions.

Getting code right is hard.  Getting code right in a complex system is
*very* hard.  While one can, I claim, do better for security stuff than
in the general case, I do not think it is humanly possible to build
a large system with no security flaws.  (And yes, I put firewalls in
that category -- which is why good firewalls are as small and simple
as possible.)

Finally, if you don't believe me, go and read (or reread) Mythical
Man-Month.


                --Steve Bellovin