This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Summarize issues related to urandom, getrandom etc in secrets documentation
Type: enhancement Stage: resolved
Components: Documentation Versions: Python 3.6
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: steven.daprano Nosy List: dstufft, georg.brandl, larry, ncoghlan, ned.deily, steven.daprano, vstinner
Priority: normal Keywords:

Created on 2016-06-11 10:30 by steven.daprano, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (5)
msg268206 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2016-06-11 10:30
Write some documentation for the ``secrets`` module summarizing the issues relating to /dev/[u]random, getrandom, etc. There's a lot of confusion about these issues, and the web contains a lot of misinformation, so being able to point to the secrets docs for a summary will be useful for further discussions, and to help programmers pick the right solution.

I know the Python docs cannot be the definitive source of information about OS features, but they can provide enough of a summary to allow users to make informed decisions.
msg268208 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-06-11 10:45
Thx Steven.

tl;dr The OS' / Kernel's CSPRNG is safe-to-use as long as one uses the correct API: getrandom(flags=0) on Linux, getentropy() on BSD, CryptGenRandom() on Windows.

Myths about Linux's urandom: http://www.2uo.de/myths-about-urandom/

Example why user-space CSPRNG are bad: https://gist.github.com/tiran/a9ba8c51cc7d1b75d3bc1d3f24411b4c
msg268240 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2016-06-11 18:18
As with #27292, I'm going to nosy Georg Brandl about this so he can guide us in how to approach it.  My hunch is, it'd be best if we avoided specifics, and talked instead in generalities.

Perhaps all that's really necessary is to consistently assure the user that the secrets module represents best practices in Python, now and in the future.
msg268241 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2016-06-11 18:19
Oops, sorry, forgot to actually nosy Georg.  D'oh!
msg274713 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2016-09-07 02:37
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.

Accordingly, marking this as out of date - with os.urandom() and the secrets module both implicitly doing the right thing, the vagaries of operating system cryptographic RNG access can be left as obscure arcana of interest only to language runtime developers, rather than regular Python users :)
History
Date User Action Args
2022-04-11 14:58:32adminsetgithub: 71480
2016-09-07 02:37:36ncoghlansetstatus: open -> closed

type: enhancement

nosy: + ncoghlan
messages: + msg274713
resolution: out of date
stage: needs patch -> resolved
2016-06-12 11:34:06christian.heimessetnosy: - christian.heimes
2016-06-11 18:19:02larrysetnosy: + georg.brandl
messages: + msg268241
2016-06-11 18:18:02larrysetmessages: + msg268240
2016-06-11 10:45:33christian.heimessetmessages: + msg268208
2016-06-11 10:30:58steven.dapranocreate