STINNER Victor added the comment:
Marc-Andre Lemburg:
> I propose to deprecate os.urandom() altogether due to all the issues we've
> discussed on all those recent tickets.
I'm sorry, but I don't understand the purpose of this change. Usually, when we
deprecate something, it is in favor of a new better function. What do you
propose?
I read that you proposed to expose getrandom() as os.getrandom(). It would be
painful to write portable code if each OS provides its own RNG function.
Python has the habit of helping users by providing portables functions. Recent
example: time.monotonic (PEP 418). Somehow related: non inheritable file
descriptors by default (PEP 446) and retry system calls failing with EINTR (PEP
475). These changes aim to simplify the life of Python developers to reduce the
subtle differences between each operating system.
To me, os.urandom() is well defined. The corner case of not initialized urandom
is really a corner case which only occurs in "catastrophic" cases like ("badly
configured") VM or embedded devices without hardware RNG (nor RTC).
When it's hard to write a reliable behaviour on all platforms, the simple
solution was always to document the subtle differences between each platforms.
I started to do with documenting getrandom() and the fallback on /dev/urandom
for Linux:
https://docs.python.org/dev/library/os.html#os.urandom
--
If we cannot agree on a technical solution, a PEP is required.
But please give me some time to investigate the different technical solutions
before trying to take a decision.
Right now, I'm investigating the options to keep the Python startup "secure" in
the "urandom not initialized" case and keep os.urandom() "blocking".
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27266>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
