>> I'm not sure of the merit in this; it's security through (little) obscurity,
>> at best.  Any reasonable cracker knows how to go 'fish'ing ...  8-)
>
> Any qualms about adding that 'unsecure' option to the code, or is NetBSD
> trying to stay as BSD 4.4'ish as possible?

(I certainly hope so.)

> I totally agree about the false security about this.  I mean, you can't
> rlogin as root, but rsh "setenv <host>:0.0; /usr/X11R6/bin/xterm &" works
> just fine.  Unfortunately, that won't work for us in all cases, since we do
> work from vt100 emulation at times.

Done a "rsh otherhost '[t]csh -i'" lately?  If you don't need job control ...

Oh, one other vaguely security-related thingy: I fed some NetBSD-specific
patches to the author of "xlockmore" (xlock-type screen locker; available from
ftp://ftp.X.ORG/contrib/applications/xlockmore-1.14.tar.gz last I checked). 
I'm going to build it tomorrow to make sure he didn't drop any patch-related
bits; in the meantime, if someone in i386-land could give it a whirl and see if
it flies, I'd appreciate it.  (Not that I expect any byte-ordering issues, but
one never knows ... and I'd like to tell him to put "works on NetBSD" in the
README, not "works on NetBSD/SPARC" (-: )

On another note, I mentioned the "artpnew" problem a while back on port-sparc;
I get a bunch of these on my SPARCstation IPC.  I noted that I especially
tended to get them when something did a broadcast; e.g. "rup" (or "rusers") on
a SunOS or Solaris machine.

I didn't look real hard but I'm sure that it's trying to add a new ARP table
entry and something is cocked up.  Just not sure yet.

If it's not fixed in 1.0 (Final Edition) I'll surely look into it at some
point ...

	- Greg