Apologies if my message seemed overly agitated or plaintive.  Wondered just
after sending if if I ought to have left out a couple of the "!"s; they were
engendered more by surprise that things didn't work than annoyance or
aggrivation or an urge to complain emphatically.  I'm personally of the
opinion that the NetBSD developers do a most nifty and timely job indeed.

On a gloomier note:

The recent note on the ftp server on sun-lamp has made me think about the
security of the "official" copy of the NetBSD sources from tampering.  I've
no idea about what if any measures have been taken to ensure this, but it's
worth note that so vast a collection of source code, used by tens or hundreds
of thousands around the world, represents a treasure-trove for malicious
individuals wishing to insert holes simple or complex, trojan horses, and the
like.  Bluntly put, were 50 such holes inserted at various points in the
tree, I doubt they'd all be noticed within several years.

I notice that sun-lamp appears to still be using reuseable passwords.  I also
note that Ethernet sniffing has been reported on Berkeley's campus network
several times in the past few months.  It might make sense to consider using
s/key.  In fact, it would probably make sense to include a s/key aware
/bin/login with the NetBSD distribution, since as s/key doesn't use
encryption it can be freely exported.

I also hope that machines which can be telnetted into bear copies of the
NetBSD source tree which are mounted read-only, or some such?  Of course, I
have no idea what degree of thinking has or hasn't gone on about this -- but:

It's noteable that most OS development work is now done behind firewalls. 
Clearly, the NetBSD core team does not have this option.  However, might it
not be best to keep an official copy of the source on a machine which runs no
net daemons save telnetd, and which has only very few, s/key protected
accounts?  A PITA, but one which probably needs to be suffered through if
crackers aren't to be marauding about through the source code with
boobytraps...

The caveat belongs here once again that I have no idea what measures are or
have been taken to prevent this.  But with the number of
insert-hole-in-source type attacks that seem to be going on (we even noticed
an attempt here at Panix to stuff our dns, presumably to direct ftps to a
false archive site for some reason, a few days ago) the issue must bear some
degree of thought.

Thor

------------------------------------------------------------------------------