[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Paul Moore]

On 11 June 2016 at 22:46, Donald Stufft <donald at stufft.io> wrote:
> I guess one question would be, what does the secrets module do if it’s on a
> Linux that is too old to have getrandom(0), off the top of my head I can
> think of:
>
> * Silently fall back to reading os.urandom and hope that it’s been seeded.
> * Fall back to os.urandom and hope that it’s been seeded and add a
> SecurityWarning or something like it to mention that it’s falling back to
> os.urandom and it may be getting predictable random from /dev/urandom.
> * Hard fail because it can’t guarantee secure cryptographic random.
>
> Of the three, I would probably suggest the second one, it doesn’t let the
> problem happen silently, but it still “works” (where it’s basically just
> hoping it’s being called late enough that /dev/urandom has been seeded), and
> people can convert it to the third case using the warnings module to turn
> the warning into an exception.

I have kept out of this discussion as I don't know enough about
security to comment, but in this instance I think the answer is clear
- there is no requirement for Python to protect the user against
security bugs in the underlying OS (sure, it's nice if it can, but
it's not necessary) so fallng back to os.urandom (with no warning) is
fine. A warning, or even worse a hard fail, that 99.99% of the time
should be ignored (because you're *not* writing a boot script) seems
like a very bad idea.

By all means document "if your OS provides no means of getting
guaranteed secure randon mumbers (e.g., older versions of Linux very
early in the boot sequence) then the secrets module cannot give you
results that are any better than the OS provides". It seems
self-evident to me that this would be the case, but I see no reason to
object if the experts feel it's worth adding.

Paul