> On Aug 7, 2016, at 12:28 PM, Ethan Furman <et...@stoneleaf.us> wrote: > > At this point we have concrete examples of the harm caused by blocking on > os.urandom -- do we have any actual use-cases where it is hurtful to raise > instead?
The use cases there are basically any time it would have only blocked for say, half a second or so. It’s hard to point out a specific use case because we’ve never had an error raising there, we’ve either just silently given them bad data because /dev/urandom wasn’t initialized or we blocked and they didn’t notice because it only blocked for a short time. I suspect that the “can block for a short time” will be the dominant case, because the system generally gets entropy quite quickly in most scenarios. The only time it can’t really is if Python is the only thing running early enough in the boot process *and* that thing is calling os.urandom. The problem we had that started this thread was SipHash initialization calling a blocking urandom by a script called by systemd prior to the point where systemd would attempt to reseed urandom from previous boots and prior to the point that systemd parallelizes the boot process. Basically any other time the time to block will be relatively short (and in fact, you see daemons like OpenSSH blocking on start up for similar reasons). — Donald Stufft _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
