Larry Hastings added the comment: Thank you for summarizing the debate. It made it a lot easier to
> * blocking initialization of the hash secret. This occurs regardless of > script contents; at present Python simply can't be used at all in low-entropy > situations. I feel that this issue is a release blocker. > > Possible resolutions: > * accept possible low-entropy initialization of the hash secret; using the > patches supplied here by myself and Victor. > * add a command-line flag to disable "strong" initialization of the hash > secret (or revive the old -R flag). > * simply require user-space workarounds like setting PYTHONHASHSEED The latter two approaches are unacceptable IMO. They result in a poor user experience. Python should do the "right" thing by default; the "right" thing includes not taking 90 seconds to start up. By process of elimination, this leaves only the first approach as viable. Ergo, let's do that. The hash secret is a 32-bit integer, even on 64-bit builds of Python. It is not and cannot be cryptographically secure. It's frankly ridiculous to fret about "strong" initialization of it at the cost of a 90 second startup time. (For posterity: when people mention "SipHash", they're talking about the hashing algorithm used for str/dict/etc. The seed for SipHash is the "hash secret" we're talking about here.) > * blocking random reads during import hashlib or import random. This is more > complex, as we need to take developer intentions into account. I do *not* > think that these are release blockers as there are reasonably easy > workarounds, however the fact remains that there has been a regression in > Python's behavior on Linux. > > Possible resolutions: > > * accept Victor's existing changeset without my nonblocking_urandom_noraise > patch, which makes _PyOS_URandom nonblocking in all Linux cases. > * resolve as above (both Victor's and my patches), and require that > applications be modified to work correctly > * require modifications to hashlib.py and random.py to use nonblocking > sources and/or raise exceptions accordingly. I don't follow whose patch does what. But here's what I find acceptable, from a high level. * The semantics as presented by the documentation must be preserved. os.urandom() and other operations that declare they're safe for cryptographic use must remain safe for cryptographic use. * "import random" must not block. * "import hashlib" must not block. Is there a patch set that accomplishes that? -- If this means that random.random() may be seeded with poor-quality random bits, so be it. As I think I already stated in this thread: there are many non-cryptographic uses for random.random(). And the documentation for the random module already states that it's not suitable for cryptography. So making it block in order to procure a cryptographically-strong seed is counterproductive. Also, I think the constraint "import hashlib must not block" is a non-issue. I preserved it above just in case I missed something. But Colm was the one who suggested "import hashlib" was blocking, and he quickly said afterwards that he was mistaken. In any case a quick review of the code suggests that hashlib never uses getrandom and thus should not currently block. Unless someone says otherwise, I'll assume hashlib is fine, never blocks on import, and thus requires no modification. ---------- _______________________________________ 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
