[issue27293] Summarize issues related to urandom, getrandom etc in secrets documentation

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. Accordingly, marking this as out of date - with os.urandom() and the secrets module both implicitly doing the right thing,

[issue27293] Summarize issues related to urandom, getrandom etc in secrets documentation

Changes by Christian Heimes : -- nosy: -christian.heimes ___ Python tracker ___ ___

[issue27293] Summarize issues related to urandom, getrandom etc in secrets documentation

Larry Hastings added the comment: Oops, sorry, forgot to actually nosy Georg. D'oh! -- nosy: +georg.brandl ___ Python tracker ___

[issue27293] Summarize issues related to urandom, getrandom etc in secrets documentation

Larry Hastings added the comment: 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

[issue27293] Summarize issues related to urandom, getrandom etc in secrets documentation

Christian Heimes added the comment: 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

[issue27293] Summarize issues related to urandom, getrandom etc in secrets documentation

New submission from Steven D'Aprano: 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