On 9 June 2016 at 12:39, Donald Stufft <don...@stufft.io> wrote: > >> On Jun 9, 2016, at 12:30 PM, Steven D'Aprano <st...@pearwood.info> wrote: >> >>> >>> os.urandom >>> ---------- >> [...] >>> With that in mind, I think that we should, to the best of our ability given >>> the >>> platform we're on, ensure that os.urandom does not return bytes that the OS >>> does not think is cryptographically secure. >> >> Just to be clear, you're talking about having it block rather than raise >> an exception, right? >> >> If so, that makes sense to me. That's already the behaviour on all major >> platforms except Linux, so you're just bringing Linux into line with the >> others. Those who want the non-blocking behaviour on Linux can just read >> from /dev/urandom. > > > There are three options for what do with os.urandom by default: > > * Allow it to silently return data that may or may not be cryptographically > secure based on what the state of the urandom pool initialization looks like. > * Raise an exception if we determine that the pool isn’t initialized enough > to get secure random from it. > * Block until the pool is initialized. > > Historically Python has done the first option on Linux (but not on other OSs) > because that was simply the only interface that Linux offered at all. In > 3.5.0 Victor changed the way os.urandom worked in a way that made it use the > third option (he wasn’t attempting to change the security properties, just > avoid using an FD, but it improved the security properties as well). > > My opinion is that blocking is slightly better than raising an exception > because it matches what other OSs do, but that both blocking and raising an > exception is better than silently giving data that may or may not be > cryptographically secure.
I think an exception is much easier for a user to deal with from a practical point of view. Trying to work out why a process has hung is obviously possible, but not necessarily easy. Having a process crash due to an exception is very easy to diagnose by comparison. Cheers, Ben _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
