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:49:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <5756DEF2.5040506@egenix.com>
In-reply-to <1465309115.08.0.157352239694.issue26839@psf.upfronthosting.co.za>
Content
On 07.06.2016 16:18, Donald Stufft wrote:
> 
> Donald Stufft added the comment:
> 
>> I just don't understand why you are apparently not willing to even consider compromises.
> 
> I have one thing that I hold immutable here, That os.urandom should use the best interfaces provided by the OS to ensure that it always returns cryptographically random data.
> 
> I don't care if SipHash is allowed to use lesser data.
> I don't care if os.urandom raises an exception or if it blocks if enough entropy isn't available.
> I don't care if people are given an option that will let them maybe get bad data (but will only work on Linux or older *nixes).
> 
> All I care about is that the default behavior of os.urandom gets data that is generated using the best practices for that system, because that's what people have been told to use for years and years.

Fine, but that's just your personal desire.

It's not something that we have documented anywhere - all these
years, we've told people that os.urandom() is an interface to
/dev/urandom and this was now changed in an incompatible way
without giving notice to anyone.

Why not expose os.getrandom() and then have folks that care
about having it block in the case of an uninitialized
entropy buffer use that ?

This gives people a clear choice and doesn't cause people
to have to reconsider using the random module or wait for
Python hash randomization to initialize itself when using
Python during VM/container/system startup.

I don't really appreciate this approach to break Python in
cloud setups just because some entropy pool is not initialized,
which only a tiny fraction of users care about. It doesn't
make Python land a better place.

This is similar to the approach that Python3 should always
determine the I/O encoding from the environment, without providing
sane defaults to even startup the interactive console or run a
pipe. It wasn't helping with the adoption of Python. We've
resolved that by making useful assumptions. We should do
the same here.
History
Date User Action Args
2016-06-07 14:49:28lemburgsetrecipients: + 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:49:28lemburglinkissue26839 messages
2016-06-07 14:49:27lemburgcreate