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 GRND_RANDOM flag i.e. to read from /dev/random pool.

Simply subclassing SystemRandom is not enough, the idea is to make it possible for every library and program to use the big entropy pool if it's available. So I'm thinking it would be best to configure it with an environment variable, something like PYTHONTRUERANDOM or PYTHONDEVRANDOM.

Admittedly, only a small subset of users would benefit from this but changes required are also small and I'm willing to do all the work here. Are there any reason this patch won't be accepted? Any preferences regarding variable name?

I'm opposed to use blocking /dev/random instead of /dev/urandom: see PEP
524 for the rationale.

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 should only used for very specific use cases." and that's exactly what I'm proposing, a special option for special use cases. (Speaking of options, it would've been nice to have more of those, I would really like to have an easy way to access an entropy source directly, not through system PRNG, for generating keys and like. But devices and interfaces can be different so it's out of scope for this proposal.)

To be absolutely clear: what I'm proposing is a small improvement for linux users who have a good entropy source (e.g. a hardware TRNG) and specifically opt for this feature setting an environment variable (or by other means). Without affecting anyone else under any circumstances.

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 are free to do that through an extension module if they really wish to do so, but it's not an option we're interested in supporting in the standard library.

This is a good article providing some additional background on that topic: http://www.2uo.de/myths-about-urandom/

There was one genuine problem with /dev/urandom (it could return potentially predictable values if the entropy pool hadn't been adequately seeded), but Victor addressed that in PEP 524 by switching to the blocking variant of the getrandom() syscall (when available) rather than using the file descriptor interface.

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 /dev/urandom), but going through /dev/random (or calling "os.getrandom(n, os.GRND_RANDOM)") isn't one of them.

Instead, /dev/random consumes the same kernel CSPRNG that /dev/urandom does, it just adds an extra check to make it block when the kernel's collected entropy estimate happens to be low.

So this isn't something we want to expose or explain to Python users in general - instead, it's something that only folks doing highly specialised work involving hardware security modules might be interested in, and hence can be safely left to third party tools and frameworks, rather than being something that would ever be shipped by default as part of the reference interpreter and standard library.

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 /dev/random for *bad* reason.

There is no need to extend the stdlib. I suggest yo close this issue as
WONTFIX.