[issue27288] secrets should use getrandom() on Linux

Nick Coghlan added the comment: PEP 524 has been implemented for 3.6b1 in #27776, so os.urandom() itself will now do the right thing for cryptographic use cases on Linux. -- nosy: +ncoghlan resolution: -> out of date status: open -> closed ___

[issue27288] secrets should use getrandom() on Linux

Changes by Donald Stufft : -- nosy: -dstufft ___ Python tracker ___ ___ Python-bugs-list

[issue27288] secrets should use getrandom() on Linux

Ned Deily added the comment: Setting this to "deferred blocker" priority to note that it needs to be resolved prior to feature code cutoff for 3.6.0, which is at 3.6.0b1 currently planned for 2016-09-07. -- priority: release blocker -> deferred blocker

[issue27288] secrets should use getrandom() on Linux

Jelle Zijlstra added the comment: I'm interested in implementing this for 3.6, but I'm not sure exactly what the changes are that were decided upon. Is the following accurate? 1. Nothing changes in os (all the necessary changes were made in 3.5.2 already). 2. On Linux 3.17+ only, we add a new

[issue27288] secrets should use getrandom() on Linux

Brett Cannon added the comment: It should be mentioned that Guido really doesn't like the idea of os.getrandom() as it exposes stuff where we would rather simply tell people to use the secrets module. -- ___ Python tracker

[issue27288] secrets should use getrandom() on Linux

Tim Peters added the comment: I think it's clear Guido would say "#1". The thrust of all his comments to date is that it was a mistake to change the semantics of os.urandom() on Linux (and one other platform? don't really care), and that in 3.6+ only `secrets` should _try_ to supply

[issue27288] secrets should use getrandom() on Linux

Brett Cannon added the comment: Based on the documentation of random.SysRandom I think it comes down to #1. Perhaps the secrets documentation simply shouldn't mention the random module beyond how it's different? Then any use of the random module by the secrets module is an implementation

[issue27288] secrets should use getrandom() on Linux

Changes by Cory Benfield : -- nosy: +Lukasa ___ Python tracker ___ ___ Python-bugs-list

[issue27288] secrets should use getrandom() on Linux

Steven D'Aprano added the comment: I don't want to start another huge thread on python-dev unless really necessary. What should happen to random.SystemRandom? (1) nothing, it stays as it is, and if ``secrets`` needs better, it can subclass it; (2) it changes to use ``os.getrandom``, and then

[issue27288] secrets should use getrandom() on Linux

Changes by Brett Cannon : -- nosy: +steven.daprano ___ Python tracker ___ ___

[issue27288] secrets should use getrandom() on Linux

Tim Peters added the comment: It was a primary purpose of `secrets` to be a place where security best practices could be implemented, and changed over time, with no concern about backward compatibility for people who don't use it. So if `secrets` needs to supply a class with all the methods

[issue27288] secrets should use getrandom() on Linux

Donald Stufft added the comment: As an additional aside, the documentation of secrets references the documentation of random.py for it's secrets.SystemRandom class, however random.py docouments random.SystemRandom as using os.urandom. So the documentation for secrets.SystemRandom should be

[issue27288] secrets should use getrandom() on Linux

New submission from Donald Stufft: In 3.5.0 and 3.5.1 os.urandom will, where available, use the getrandom() to block rather than get insecure random from the urandom pool on Linux. In 3.5.2 this change is reverted so that os.urandom will return possibly predictable random numbers instead of