Doug Barton said:
>       Since this post actually has some content I'm moving it to
> -current.


> > Our /var isn't persistant accross boots, btw.  It is a mfs file
> > system.  Having a requirement that /var contain persistant data would
> > likely lead to problems.
>       It's precisely for these, and other hairy examples that I haven't
> put the thing in /var yet. Even a diskless workstation can read files from
> a RO root that the host writes out periodically, but there is no guarantee
> that there will be a /var filesystem that we can read from at boot time. I
> actually started to write some code to handle some obvious cases and got a
> major headache just thinking about it.

What is needed is some form of persistant storage to stash the Yarrow
state over a reboot or a crash.

There are a number of people saying "Over my dead body can you put it
${HERE}!!", without coming up with alternatives that are useful. At
BSDCon, the concept of using the first swap partition was discussed,
and I think it is a great idea, but the volunteer has yet to offer
any code.

> > I'm still not sure why we can't do something like:
> >
> >     date > /dev/random
> >     cat /bin/ls > /dev/random
> >     fsck
> >     mount the file systems
> >     read in the entropy file
> >
> > Eg, toss some bone to the random pool.  Sure, it will be highly
> > preditable, but for the mount commands it doesn't matter.  We fix
> > before anything interesting happens.

Just as usable is "echo 'sekrit password' > /dev/random".

Might as well not bother. There is no usable randomness here, so rather
than pretending, it is better to simply admit to ourselves that the
entropy generator is giving crap numbers at this point.

I originally put a block-at-startup in precicesly because of this 
complaint. Remember that on a brand-new system, at first boot, the
sshd is going to use /dev/random to make keys. How insecure do you
want that?

Can we decide this, please - do we want secure startup (which will
take some effort to achieve), or can we say "screw it" and start
insecure like the old system?

I'm happy to accomodate folks, but the constant lack of concensus
combined with extreme positions is wearing a bit thin.

Mark Murray
Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to