News for hackers. Stuff that matters.
Re:Ruby Bug: SecureRandom should try /dev/urandom first by tptacek on Wednesday May 04, 2016 @11:27AM (#11629013)
The proposed change --- unify urandom/random and permanently lose blocking behavior --- can't possibly break userland. There is no way to write a program that depends on /dev/random blocking, because it does so at random.
Re:Ruby Bug: SecureRandom should try /dev/urandom first by JoachimSchipper on Wednesday May 04, 2016 @01:56PM (#11630224)
I've seen you post that a few times, so two minor nitpicks.

In the mental model in which the /dev/random manpage lives, it makes (some) sense to read /dev/random until you get a short read, then make a userland pool from all the data you've read, "to get as much entropy as possible". That reasoning doesn't actually make sense, of course, but I would be surprised if nobody thought that such a construction would be a good idea.

Separately, there's quite a lot of code - and I've written some - that reads a byte from /dev/random at daemon start, specifically to block until the system has built up enough entropy. FreeBSD blocks reads, even from /dev/urandom, until the [EDIT: estimate of how much entropy has ever gone into the pool] gets high enough, which makes some sense; but there needs to be some way to block-until-random.

Re:Ruby Bug: SecureRandom should try /dev/urandom first by tptacek on Wednesday May 04, 2016 @01:59PM (#11630257)
FreeBSD blocks until the generator is seeded. I think Linux urandom should do the same thing. But once it's seeded, there is no reason for the generator ever to block again.
Re:Ruby Bug: SecureRandom should try /dev/urandom first by JoachimSchipper on Wednesday May 04, 2016 @02:51PM (#11630693)
Yes, that's what I meant. Edited for clarity, thanks!
Re:Ruby Bug: SecureRandom should try /dev/urandom first by mioelnir on Wednesday May 04, 2016 @03:16PM (#11630912)
On 11.x random routinely unblocks before the userland is even started, so from an application standpoint random really never blocks.