This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Colm Buckley, Lukasa, alex, christian.heimes, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-07.14:06:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <5756D4C7.1080600@egenix.com>
In-reply-to <1465305668.29.0.091260234974.issue26839@psf.upfronthosting.co.za>
Content
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.
History
Date User Action Args
2016-06-07 14:06:05lemburgsetrecipients: + lemburg, rhettinger, doko, vstinner, larry, christian.heimes, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, dstufft, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-07 14:06:05lemburglinkissue26839 messages
2016-06-07 14:06:05lemburgcreate