On 09.06.2016 10:16, STINNER Victor wrote:
> 
> 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?

It's mainly to get people stop thinking that we can fix os.urandom()
in a way so that it works the same across platforms and to
draw some attention to the main proposal in #27279 :-)

I don't feel strong about the deprecation.

> 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.

This would be done in the two new functions, in Python and
based on whatever is available on the platform. See #27279.

Application writers should not have to worry about the
different mechanisms used on the different platforms.

> 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.

Exactly.

> 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).

It is a corner case, but one we'll see hit us more often going
forward, since booting up VMs/containers no longer is a rather
rare incident. It's being used as part of the architecture of
system nowadays.

> 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.

Right. The topic has too many aspects to really address in a bug
tracker ticket. It's better to start writing these things down
in a PEP. I'm using #27279 as scratch pad for this.

> But please give me some time to investigate the different technical solutions before trying to take a decision.

Sure, Python 3.6 is still in the making...

> Right now, I'm investigating the options to keep the Python startup "secure" in the "urandom not initialized" case and keep os.urandom() "blocking".

The Python startup definitely has to be fixed, regardless of what
we do with os.urandom(). This means: getting hash randomization
and the random module initialized without blocking even when
the entropy pool is not yet initialized.

I guess the easiest way to solve this for the random module
is by making the initialization lazy (as was proposed on the
resp. ticket).