On 11 June 2016 at 22:46, Donald Stufft <donald@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