Marc-Andre Lemburg added the comment: On 07.06.2016 15:21, Donald Stufft wrote: > > The patch causes a regression because I'm relying on the 3.5 behavior of > getting secure randomness from ``os.urandom`` via the ``getrandom()`` system > call (behavior that was documented in the Whats New in 3.5). The 3.5 behavior > also makes ``os.urandom`` behave the same on Windows, FreeBSD, OpenBSD, etc, > basically every major OS except for Linux.
The contention is not about using getrandom() to fetch data, but the newly introduced and unwanted blocking nature during system startup. This was not documented anywhere and it's a regression that causes major problems with using Python 3.5 on containers and VMs systems where startup time is of essence. You get the same blocking behavior when importing the random module (see http://bugs.python.org/issue25420), even though it's just seeding the global PRNG. All these instances assume that os.urandom() does *not* block and rightly so, since at the time they were written, os.urandom() was a direct interface to /dev/urandom, which is documented and designed to not block on Linux. > And yes, it's not unusual for "bugs" to not be fixed if there is contention > about whether or not they are bugs at all and if they should be fixed. The > typical resolution path to not change anything unless there's broad > agreement, if that can't happen on bugs.p.o then escalate to python-dev, and > if it can't happen there then escalate to a PEP for a BDFL pronouncement. Sure, we can have the discussion again on python-dev. I just don't understand why you are apparently not willing to even consider compromises. ---------- _______________________________________ 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