Didn't see this arrive on the list. Sending again. -- Thayne Harbaugh Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
On 15 Jan 2001 00:15:46 +0100, Niels Möller wrote: > Thayne Harbaugh <[EMAIL PROTECTED]> writes: > > > More specificly, I notice that lshd exits with the following error: > > Thanks for the bug reports. I'll look into it in the week. Thanks. I'm more than happy to help out as well. > > > I'm also wondering what's up with unix_random.c. Why is there so much > > effort exerted trying to stumble through vmstat, ps, netstat and the > > like > > on machines that have a good /dev/random? Will there be a compile > > time option for using /dev/random instead of the current functionality? > > Some reasons for not making the new code optional are > > 1. It doesn't hurt to use more input for the generator. > > 2. If the code is used everywhere, it is more likely that bugs are > noticed and fixed. > > 3. It's not entirely trivial to figure out if a /dev/urandom that > happens to exist in the file system really is good. In particular > not for the configure script. Minor note: At least on Linux, /dev/urandom and /dev/random are different. /dev/urandom just uses a simple random number generator. /dev/random uses disk, network, terminal and other events to generate cryptographicly secure random numbers. > > If you really need a compile time option, I could add one. What should > it be called? What really bugs me is seeing all the failures of vmstat and netstat printed to the screen when an illegal option is tried. It seems that all the blind try/fail of executing vmstat, ps, netstat could be skipped if /dev/random (or whatever is appropriate for the OS) was just used. This looks ugly and is scarey if one doesn't understand why it's unsuccessfly: unix_random.c: Started background poll. pid = 23719. unix_random.c: background_poll: /usr/bin/vmstat exited unsuccessfully. unix_random.c: background_poll: /usr/bin/vmstat exited unsuccessfully. unix_random.c: background_poll: /usr/bin/vmstat exited unsuccessfully. unix_random.c: background_poll: /usr/bin/vmstat exited unsuccessfully. unix_random.c: background_poll: /bin/netstat exited unsuccessfully. If there was a "--with-devrandom" configure option (or something similar) then you could substitue a possibly buggy unix_random.c with something from the OS that has been tested even more than lsh (yes, the obvious tradeoff - lsh:unix_random.c gets tested less). If you are really paranoid than the lsh client/server could print a statement on startup that it is using /dev/random. There might even be a message refering one to a man page or info page describing /dev/random vs. unix_random.c and the tradeoffs and what to be aware of. That way the local user could investigate things, understand them, and make an informed choice about the true randomness of the generator. > /Niels PS. One other bug that has been around for quite some time. The lsh.info page doesn't have an entry so that install-info can make a directory entry. I don't have a huge background with generating info files. If you want, however, I'm more than happy to come up with what needs to be done to fix the problem. -- Thayne Harbaugh Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
