Message 267750 - Python tracker (original) (raw)

On 07.06.2016 22:27, Theodore Tso wrote:

Secondly, when I decided to add this behavior to getrandom(2), it was because people were really worried that people would be using /dev/urandom for security-critical things (e.g., initializing ssh host session keys, when they'd really rather not the NSA have be able to trivally pwn the server) before it had been completely initialized. (And if it is not completely initialized, it would be trivially and embarassingly easy. See https://factorable.net/weakkeys12.extended.pdf for an example of where this was rather disastrous.)

Thanks, Theodore, for this paper reference. It provides convincing arguments that going back to the Python 3.4 behavior is indeed not a good idea - even though I'm still not convinced that the main use case for os.urandom() is cryptography. Most people will simply use it to seed their Mersenne Twisters, like the random module does too.

Now, raising an exception instead of blocking would likely cause even more breakage, so I'm with Colm in keeping Victor's patch and applying the fix to not block in dev_urandom_noraise().

We still need to fix the random module issue, though.

For 3.6, I wish we could have the getrandom() API exposed as os.getrandom(), with all options available to applications. That way, the application can decide what is best for them.