Donald Stufft added the comment: > My personal preference would be for os.urandom(n) to favor non-blocking > operation over cryptographic security, and either add os.random() or add an > optional parameter to os.urandom() to make the opposite trade-off.
Insecure by default is very rarely the right trade off. There are thousands of projects using ``os.urandom()`` already assuming it's going to give them cryptographically strong numbers. If we want a "maybe random" function or option, then it should be the new thing, not the other way around. I have no problem with SipHash using a possibly insecure random so that Python can start up quickly even in the face of an unitialized urandom on Linux. I do have a problem with infecting every single call to os.urandom with that same choice. > The current behavior is that Python *will not start at all* if getrandom() > blocks (because the hash secret initialization fails). It starts jsut fine, it just can possible takes awhile. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26839> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
