[issue29790] Optional use of /dev/random on linux

2017-03-11 Thread STINNER Victor
STINNER Victor added the comment: You can already use os.getrandom() if you want /dev/urandom. And as you wrote, it is easy to inherit from SystemRandom if you need something else than bytes. I am strongly opposed to use /dev/random because most users misunderdood RNG znd so will use

[issue29790] Optional use of /dev/random on linux

2017-03-11 Thread Nick Coghlan
Nick Coghlan added the comment: To provide some additional context to that answer: the problem isn't with folks wanting direct access to their hardware entropy devices as such. There are plenty of options for that (such as exposing it as a file descriptor distinct from both /dev/random and

[issue29790] Optional use of /dev/random on linux

2017-03-11 Thread Nick Coghlan
Nick Coghlan added the comment: This RFE is unfortunately based on some incorrect assumptions about the way Linux kernels use CSPRNGs and entropy pools. Using /dev/random isn't magically more secure than /dev/urandom, it just makes your applications less reliable for no good reason. Folks

[issue29790] Optional use of /dev/random on linux

2017-03-10 Thread Ivan Anishchuk
Ivan Anishchuk added the comment: Victor, I suppose you don't happen to have a good entropy source? :) I cannot really stress the word "optional" enough here. And I understand why most user wouldn't want this. That's why I'm proposing to make it optional. As per PEP, "The /dev/random device

[issue29790] Optional use of /dev/random on linux

2017-03-10 Thread STINNER Victor
STINNER Victor added the comment: I'm opposed to use blocking /dev/random instead of /dev/urandom: see PEP 524 for the rationale. -- ___ Python tracker

[issue29790] Optional use of /dev/random on linux

2017-03-10 Thread Steven D'Aprano
Changes by Steven D'Aprano : -- nosy: +haypo, ncoghlan, steven.daprano ___ Python tracker ___

[issue29790] Optional use of /dev/random on linux

2017-03-10 Thread Ivan Anishchuk
New submission from Ivan Anishchuk: Right now secrets module uses SystemRandom which is hardcoded to use os.urandom() which is fine for most users but some have good hardware sources of entropy (or otherwise replenish entropy pool) in which case it would be much better to use getrandom() with