Re: [8lgm]-Advisory-14.UNIX.SCO-prwarn.12-Nov-1994 (fwd)

[jmb () kryten Atinc COM (Jonathan M. Bresler)]

        gene,  i have a lot of respect for you and what you have done 
(are sitll doing) for the user community.  but i dont agree with 
everything that you have said here.

On Mon, 28 Nov 1994, Gene Spafford wrote:
> >     this is an excellent argument for using one of the free unix 
> > systems.  the support team response time is much better.  if you have the 
> > knowlege and ability, you can fix it yourself.  
>
>
> Those "if" qualifications are quite a bit bigger than you may realize.
> I regularly give tutorials to the people who run major computer
> centers and they are now switching over to Unix.  They don't know C,
> don't know Unix, and are responsible for getting the plant moved over
> to Unix.  They aren't allowed to use freeware or shareware (insurance
> and legal staff won't allow it) even if they knew how, which they
> don't.  They often aren't on the net and don't plan to get Usenet
> groups even if they do connect, so they have no contact with "support
> team[s]" for free unix.

        a corporation should hire or train people to do this work.  if 
they wont or cant, then that is their decision and they may have to live 
with it.  maybe not, they might not get found out and if they connect to 
the net thru a strong firewall, they are better off than many.  but its 
the corporation's responsibilty to protect its assets as it sees fit.
they could also contract with cygnus or the like for support.

        with the advent of betsi, free software from respectable 
organizations like fsf is better than hardware from some (intel?).   i 
can understand intel's plight; but commercial == better is very often 
untrue.  how much better off would we be if hardware companies would 
donate their os budgets to fsf?  then we would have a free, well 
supported unix that runs on most major platforms.  this would have the 
additional benefit of providing us with a standard unix which all 
software vendors can write to.  larry wall's configure code shows how bad 
the situation is.

> Then there are others, like myself, who are using hardware that is not
> adequately supported by any free versions of Unix.  Or (again like
> me), my software is supported by a paid staff and not by myself.  They
> are using a commercial offering because it is consistent across about
> 10 different machine architectures in the department.

        more reasons for hardware vendors to fund fsf.

> Actually, it is possible to get source to commercial versions of Unix,
> if you think it is worth the expense.  Therefore, the argument doesn't
> apply solely to "free" versions of Unix.  Large corporations with a
> concern for security do pay for source licenses for precisely this
> reason.

        if they are buying a source license, i hope they are buying the 
expertise to read, and use the code.

>           (Rhetorical question: I wonder how much of the "full
> disclosure" pressure is from people using "free" versions of Unix who
> hear about a bug and demand the details to know if it applies to their
> systems?  They're getting what they [didn't] pay for, but are
> agitating for more information at the potential expense of endangering
> other users.)

        FreeBSD is all 4.4BSD with parts from 386bsd, netbsd and linux.  
(yes, fragmentation of effort is a problem.  another reason for funding 
fsf)

> If we are concerned about improving the state of computer security for
> *everyone*, we need to give careful thought to the needs and abilities
> of the entire use community -- not just the ones who are comfortable
> with kernel hacking, free software, and the Internet.
>
> On the other hand, if all we are concerned about is our own personal
> security picture, then having sources is the way to go, assuming we
> have time and talent to pursue them.  (But note how many people have
> tried to program around the race condition in /bin/mail and gotten it
> wrong -- including the pros inside Sun, and many people on this list
> who had access to source code.)

        that's another reason we need the best individuals working on 
this.  i am not saying that i can get it right (everytime) but rather 
that small groups of experienced people given the data can.  these people 
should be funded to do so.  as independents, the vendor's reputation is 
not at stake, neither is his development budget.

> I'm not trying to dispute your statement -- merely pointing out that
> most people don't understand all the complexities of the situation
> behind issues of disclosure and patches.  Or, they don't care, because
> they only are concerned with getting fixes for themselves.
>
> I'm also not trying to reopen the debate about full vs. partial vs. no
> disclosure.  I'd like to see some hard evidence for things, though,
> and *not* debate.  Even my experience has been anecdotal (but I
> believe that it is more representative of the true user community than
> these lists are).  Statements to the effect that "policy X produces
> patches faster than policy Y" should be backed up by testable data.
> Otherwise, they fall in the category of faith healing, diet aids, and
> sightings of Elvis -- the observer may believe it is true, but there
> is no controlled way to demonstrate it to skeptical observers in a
> general setting.

        i am not arguing for full disclosure and do not want to reopen an
endless mailfest.  i am saying that the present situation is seriously
flawed and needs to be corrected.  how?  that's beyond me.  i am doing a
little here to wean managment away from the the concept that only money
gets good software (vendors compilers are gcc bootstrap code?) by running 
projects on FreeBSD hardware.  the 486dx-66, FreeBSD 1.1.5.1 runs fft's 
faster than our sparcserver 10/670MP, even with the MP unloaded. <cheap 
shot,  the MP runs twice the number of processes faster, but the same 
process slower>  

        fwtk, logdaemon, skey, tripwire, cops are all other examples. 
FreeBSD bugs are found and squashed before sun can even acknowledge a bug 
exists.  what can i say about hardware vendor's software?  great binders?
fills my bookshelf nicely? 

        i wish i had good evidence, even any evidence, one way or the
other.  all i have are observations of various corporations, trying, not
trying, suceeding, failing.  i think we could reasonable expect better
performance from individuals that are dedicated to this work rather than
hardware corporations that include an os with their box

> Cheers,
> --spaf
> in his professor mode :-)

        good mode.  learned a lot from people in that mode.

Jonathan M. Bresler  jmb () kryten atinc com    | Analysis & Technology, Inc.  
                                                | 2341 Jeff Davis Hwy
play go.                                        | Arlington, VA 22202
ride bike. hack FreeBSD.--ah the good life      | 703-418-2800 x346