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. -- Marc-Andre Lemburg eGenix.com _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
