Date: Sun, 25 Jun 2017 15:22:07 +0100
From: Roy Marples <r...@marples.name>
Message-ID: <ee3739d2-462f-2fbb-1515-db4bc24d0...@marples.name>
| Don't count on that happening soon.
| http://austingroupbugs.net/view.php?id=859
That one has been withdrawn, it is going nowhere at all.
The current related issue is
http://austingroupbugs.net/view.php?id=1134
which is being discussed "now" (that is, for the past couple of months
at least) - and like everything security related, seems to be being side
tracked by people who always want something better... but by blocking
any request which improves things, but doesn't achieve perfection, manage
to cause no improvement at all.
I think I have heard it said (somewhere) that the biggest threat to
good security is perfect security.
At least that is what it looks like to me looking in from the outside.
I generally avoid all security/crypto discussions, as I know nothing
worth knowing about the field.
| All modern BSD's have arc4random (and most have arc4random_uniform) -
| some use something more modern like ChaCha, so it's just an interface
| really.
Yes, I see, it just does not seem to meet the requirements (as you
said in your second message.)
| Just like sh, dhcpcd can start very early .... sometimwes before enough
| entropy has been generated just to pull blindly from /dev/urandom
| because it can block - or did in the past; it might be fixed now.
I am not too worried about that - sh will only fetch values from there
if someone is actually referring to $RANDOM, none of the startup scripts
do that, and I can't think of any reason they would - I mean who would
want a system which randomly decided whether to mount the filesystems or
not?
If someone does want random numbers, and is not setting the seed themselves,
then one might assume that they actually want numbers that are reasonably
random, and so should be prepared to wait if required (if that is what
happens.)
kre
