Can we stop the discussion please? I have picked a winner. The loser may not like it, but the discussion is OVER.
On Sun, Aug 7, 2016 at 9:33 AM, Donald Stufft <don...@stufft.io> wrote: > >> 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 > > > -- --Guido van Rossum (python.org/~guido) _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
