On Jun 21, 2016, at 04:10 PM, Victor Stinner wrote:
> PEP: xxx
> Title: Make os.urandom() blocking on Linux
> Version: $Revision$
> Last-Modified: $Date$
> Author: Victor Stinner <victor.stin...@gmail.com>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 20-June-2016
> Python-Version: 3.6
[...]
>
>Alternative
>===========
I would like to ask for some changes to this proto-PEP.
At a minimum, I think a proper treatment of the alternative where os.urandom()
remains (on Linux at least) a thin wrapper around /dev/urandom. We would add
os.getrandom() as the low-level interface to the new C lib function, and
expose any higher level functionality in the secrets module if necessary.
Then we would also add a strong admonition to the documentation explaining the
trade-offs between os.urandom() and os.getrandom() and point people to the
latter for strong crypto use cases.
Your proto-PEP uses this as a rationale:
Security experts promotes ``os.urandom()`` to genereate cryptographic
keys, even instead of ``ssl.RAND_bytes()``.
and that's been a commonly cited reason for why strengthening os.urandom() is
preferable to adding a more direct mapping to the underlying function that
provides that strengthened randomness. If if the assertion is true -and
respectfully, it isn't backed up by any actual citations in the proto-PEP- it
doesn't make it right. It's also a bad precedence to follow IMHO. Where do
we draw the line in changing existing APIs to their use or misuse as the case
may be?
We can discuss whether your proposal or my[*] alternative is the right one for
Python to follow, and I may lose that argument, but I think it's only proper
and fair to represent this point of view in this proto-PEP. I do not think a
separate competing PEP is appropriate.
I should also note that my proposed alternative would make the title
incorrect, so I'd like to suggestion something like: "Providing a
cryptographically strong source of random bytes."
Cheers,
-Barry
[*] Although labeling it "my" gives me undo credit for points of view also
held and suggested by others; it's just a handy way of referring to it.
_______________________________________________
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig
