Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!ames!think!samsung!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ulysses!smb
From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
Newsgroups: comp.org.usenix
Subject: Re: USENIX Board Studies UUCP
Message-ID: <12401@ulysses.homer.nj.att.com>
Date: 18 Nov 89 22:30:43 GMT
Article-I.D.: ulysses.12401
References: <287@usenix.UUCP> <1624@crdos1.crd.ge.COM> <49017@looking.on.ca>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 20

There have been several attempts to write uucp replacements or
look-alikes over the years.  Many of them fail on the issue of
assurance:  how do we know this will work in the real world?  The
better versions of uucp (HDB, and I think 4.3bsd's) are the product of many
years of learning to deal with improbable or impossible conditions
(to say nothing of the bug fixes they have).  The odds are high
that you'll end up with new bugs, unless someone *very* experienced
and *very* gifted write it.  Even that's no guarantee.  HDB uucp was
supposed to be much more secure than its predecessor.  It was, but
not by much at first -- mostly because it let the shell get too close
to user-supplied data.  But the creation of uusched provided powerful
isolation from ``poison pill'' files that would kill off uucico.
One site might be affected, but communication with others would survive.

A few years ago, I had the opportunity to evaluate a uucp replacement.
It was far cleaner, and inherently far more secure.  I rejected it,
though, for the reasons I cite above:  the programmer was insufficiently
paranoid.  I'd seen too many wedged links caused by ``impossible''
conditions, and this program made no attempt to detect or recover from
such errors.  A pity; it had promise.