Ruby Bug: SecureRandom should try /dev/urandom first

Re:Ruby Bug: SecureRandom should try /dev/urandom first by tptacek on Tuesday May 03, 2016 @10:09PM (#11625681)

No, it's not. Don't use haveged. Virtual machines should simply get their initial entropy from the already-seeded urandom pool of their hypervisor host. Processes don't "hang waiting for more entropy"; they hang because /dev/random inexplicably goes on strike. The answer to that problem is "never use /dev/random".

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by matt_wulfeck on Wednesday May 04, 2016 @02:04AM (#11626530)

true but even if we don't want to use /dev/random, there's still software using it all over the place that we don't necessarily want to patch.

I end up installing haveged just because I don't want the system mysteriously locking up because some random daemon wants to create a 4096 bit key on first startup.

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by viraptor on Wednesday May 04, 2016 @02:31AM (#11626608)

Replacing random with urandom for one app is just one LD_PRELOAD away. Similar to https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker... you can replace open("/dev/random") with open("/dev/urandom")

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by throwaway2048 on Wednesday May 04, 2016 @04:12AM (#11626924)

Its much easier and less error prone to just replace the device node.

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by viraptor on Wednesday May 04, 2016 @04:53AM (#11627078)

I'd rather go for a limited scope. But yes, one way or another, you don't have to suffer just because someone hardcoded /dev/random in the app.

[ Parent | on HN ]