On 08/08/2017 02:52 PM, Ken D'Ambrosio wrote: > On 2017-08-08 14:43, Bill Freeman wrote: >> I don't know, but getrandom() may well be using /dev/urandom (or a >> related facility). And that, in turn, might be waiting to "collect >> sufficient entropy". So some network traffic, keystrokes, whatever, >> need to happen between boot time and the first random emission, or >> that first "random" number becomes predictable. Since random numbers >> are often used cryptographically, predictability is a bad thing. > > True, but there's debate about just *how* predictable, etc. Not a > subject for this particular thread, but I'd be perfectly happy with udev > almost-as-random. > >> As to why ruby is designed to require a random number before being >> asked to do something dependent on such a random number is a question >> for the ruby developers. > > Email already sent. :-) > >> Re-linking /dev/urandom will probably break lots of things. Maybe run >> your script in a chroot jail that has a different /dev/urandom could >> work. > > Alas, no -- I'm doing various admin chores, and a chroot won't be > helpful. > >> Is your script too complex to rewrite in bash? Not a general >> solution, but as a workaround it has its appeal. > > *sigh* This is probably where I'm gonna wind up (or Perl, or Python). > Except I've now written a good handful of scripts that people are > waiting on, and it's gonna cause me physical pain to have to re-do them > at this point. > > C'est la vie. I guess that's the way the Ruby crumbles...
Instead of rewriting the whole thing, why not just seed the RNG manually? Slightly relevant-looking discussion BTW: https://bugs.ruby-lang.org/issues/9569#note-56 ... mainly in that it points to the updated random(4) Linux man page, which says: The /dev/random interface is considered a legacy interface, and /dev/urandom is preferred and sufficient in all use cases, with the exception of applications which require randomness during early boot time; for these applications, getrandom(2) must be used instead, because it will block until the entropy pool is initialized. So, there you go. "until the entropy pool is initialized" is apparently about 3 minutes in your case ;) You should be able to explicitly seed Ruby's internal RNG, or explicitly seed the system RNG by writing bytes into /dev/random or /dev/urandom. If you want `instant good entropy' at boot, you can even store some random data into a file at shutdown and then seed from that file at boot (be sure to invalidate that cache before seeding from it though, to ensure that you don't use the same seed twice!). IIRC there are some preexisting packages for this, and some distributions even do it by default. If you write a systemd service, it looks like you can depend on systemd-random-seed.service. -- Connect with me on the GNU social network: <https://status.hackerposse.com/rozzin> Not on the network? Ask me for an invitation to the nhcrossing.com social hub! _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/