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 lemburg
Date 2016-06-09.07:54:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465458864.98.0.412270875525.issue27279@psf.upfronthosting.co.za>
In-reply-to
Content
I propose to deprecate os.urandom() altogether due to all the
issues we've discussed on all those recent tickets, see e.g. 
#26839, #27250, #25420.

Unlike what we've told people for many years, it's clear that in the
age of VMs/containers getting booted/started every few seconds, it's
not longer the generic correct answer to people asking for random
data, since it doesn't make a difference between crypto random and 
pseudo random data.

By far most use cases only need pseudo random data and only very
few applications require crypto random data.

Instead, let's define something everybody can start to use correctly
and get sane behavior on most if not all platforms. As Larry
suggested in #27266, getrandom() is a good starting point for this,
since it's adoption is spreading fast and it provides the necessary
features we need for the two new APIs.

I propose these new APIs:

 * random.cryptorandom() for getting OS crypto random data

 * random.pseudorandom() for getting OS pseudo random data

Crypto applications will then clearly know that random.cryptorandom()
is the right choice for them and everyone else can use 
random.pseudorandom().

random.cryptorandom() will guarantee that the returned data
is safe for crypto applications on all platforms, blocking or
raising an exception if necessary to make sure only safe
data is returned. The API should get a parameter to determine
whether to raise or block.

random.pseudorandom() will guarantee to not block and always
return random data that can be used as seeds for simulations, 
games, tests, monte carlo, etc.

The APIs should use the getrandom() C API, where available,
with appropriate default settings, i.e. blocking or raising
for random.cryptorandom() and non-blocking, non-raising for
random.pseudorandom().

The existing os.urandom() would then be deprecated to guide
new developments to the these new APIs, getting rid of the
ambiguities and problems this interface has on several platforms
(see all the other tickets and https://en.wikipedia.org/wiki//dev/random
for details).
History
Date User Action Args
2016-06-09 07:54:25lemburgsetrecipients: + lemburg
2016-06-09 07:54:24lemburgsetmessageid: <1465458864.98.0.412270875525.issue27279@psf.upfronthosting.co.za>
2016-06-09 07:54:24lemburglinkissue27279 messages
2016-06-09 07:54:24lemburgcreate