Date: Thu, 11 Jan 2001 23:11:04 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Warner Losh <imp@harmony.village.org> Cc: Mark Murray <mark@grondar.za>, Jordan Hubbard <jkh@winston.osd.bsdi.com>, Sheldon Hearn <sheldonh@uunet.co.za>, obrien@FreeBSD.org, Doug Barton <dougb@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc crontab rc src/etc/defaults rc.conf src/etc/mtree BSD.root.dist src/libexec Makefile src/libexec/save-entropy Makefile save-entropy.sh Message-ID: <200101120711.f0C7B4Y97991@earth.backplane.com> References: <200101120644.f0C6hvI12630@gratis.grondar.za> <200101120534.f0C5YYH96390@earth.backplane.com> <200101120652.f0C6qls78578@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:In message <200101120644.f0C6hvI12630@gratis.grondar.za> Mark Murray writes:
:: > I would do the following:
:: >
:: > * Use Warner's fix, possibly adding 'dmesg' output in phase-1.
::
:: It make more sense to make the random device nonblocking-at-boot than
:: to do this.
:
:Maybe we could make it non-blocking until the first write to
:/dev/random? This would solve the problems that we're seeing, as well
:as allowing sshd to have enough entropy to get good results.
:
:: > * Change the crontab to something reasonable, like once every
:: > 30 minutes. Every 3 minutes is way too disruptive. Massive
:: > overkill.
::
:: Read the Yarrow paper. Yarrow suggests an entropy dump _every_ reseed.
:: Best let the user/admin tweek it as required. "crontab -e" is your
:: friend.
:
:Agreed. once a second would be too often for flash systems :-).
:
:: Do we really need cryptographic randomness to do a "fsck -y" and
:: "mount -a"? If not, then that is the problem.
:
:I don't think we do, so long as we can get good random numbers. I
:don't think we need them to meet the cryptographcially random.
:
:Warner
I think it's fairly obvious that we don't need cryptographic
randomness for early boot stages. All I'm hearing is paranoia (not
from Warner) and all I'm seeing are massive hacks being committed to
the system for no reason at all. The system daemons that require
cryptographic randomness don't start until much, much later in the
boot sequence, long after the filesystems have been mounted. It makes
no sense to construct massive hacks to make the random number generator
cryptographically secure so early in the boot process. None at all.
It makes even less sense to commit a cron job that runs every
3 *MINUTES*. I don't care how much or how little it does... it makes
NO SENSE. How can anyone believe that that would fly in a release?
It isn't even a good stopgap measure! What about laptops that power
down their hard drives? How do suppose a 3 minute cron job will go
over for those people?
I don't really give a damn what Yarrow needs... if it requires a write
to disk every second or every 3 minutes, we can't use it in a release
and should pull the whole damn thing out.
Now I see two perfectly good solutions here. I don't care which one you
guys use but if something isn't done in reasonably short order I am
going to start calling for the whole thing to be yanked... but the
committer rules. This quest for 'perfect randomness' is creating too
much of a disruption to -current. It is a totally unnecessary disruption
and I am getting seriously sick and tired of seeing it on the lists.
Those of you who are paranoid about security can edit the system defaults
on your own systems. But the system defaults themselves have to be
a whole lot more reasonable then what I've seen being committed to
the tree.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101120711.f0C7B4Y97991>