[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

Guido van Rossum guido at python.org
Sat Jun 11 13:39:11 EDT 2016

Is the feature detection desire about being able to write code that runs on
older Python versions or for platforms that just don't have getrandom()?

My assumption was that nobody would actually use these flags except the
secrets module and people writing code that generates long-lived secrets --
and the latter category should be checking platform and versions anyway
since they need the whole stack to be secure (if I understand Ted Ts'o's
email right).

My assumption is also that the flags should be hints (perhaps only relevant
on Linux) -- platforms that can't perform the action desired (because their
system's API doesn't support it) would just do their default action,
assuming the system API does the best it can.

I think the problem with making os.urandom() go back to always reading
/dev/urandom is that we've come to rely on it on all platforms, so we've
passed that station.

On Sat, Jun 11, 2016 at 10:15 AM, Donald Stufft <donald at stufft.io> wrote:

> On Jun 11, 2016, at 11:34 AM, Guido van Rossum <guido at python.org> wrote:
> In terms of API design, I'd prefer a flag to os.urandom() indicating a
> preference for
> - blocking
> - raising an exception
> - weaker random bits
> If os.urandom can’t block on Linux, then I feel like it’d be saner to add
> os.getrandom(). I feel like these flags are going to confuse people,
> particularly when you take into account that all 3 of them are only going
> to really matter on Linux (and particularly on newer Linux) and for things
> like “blocking” it’s going to get confused with the blocking that
> /dev/random does on Linux.
> Right now there are two ways to access the system CSPRNG on *nix, there is
> /dev/urandom pretty much always, and then there is getrandom() (or
> arc4random, etc, depending on the specific OS you’re on).
> Perhaps the right answer is to go back to making os.urandom always
> open(“/dev/urandom”).read() instead of trying to save a FD by using
> getrandom() and just add os.getrandom() which will interface with
> getrandom()/arc4random()/etc and always in blocking mode. Why always in
> blocking mode? Because it’s the only way to get consistent behavior across
> different platforms, all non Linux OSs either block or they otherwise
> ensure that it is initialized prior to it even being possible to access the
> Using this, code can be smarter about what to do in edge cases than we can
> reasonably be in os.urandom, for example see
> https://bpaste.net/show/41d89e520913.
> The reasons I think this is preferable to adding parameters to os.urandom
> are:
> * If we add parameters to os.urandom, you can’t feature detect their
> existence easily, you have to use version checks.
> * With flags, unless we add even more flags we can’t dictate what should
> happen if we’re on a system where the person’s desired preference can’t be
> satisfied. We either have to just silently do something that may be wrong,
> or add more flags. By adding two functions people can pick which of the
> following they want with some programming (see example):
>     * Just try to get the strongest random, but fall back to maybe not
> random if it’s early enough in boot process.
>     * Fail on old Linux rather than possibly get insecure random.
>     * Actually write cross platform code to prevent blocking (since only
> Linux allows you to not block)
>         * Fail hard rather than block if we can’t get secure random bytes
> without blocking.
>         * Soft fail and get “probably good enough” random from os.urandom
> on Linux.
>         * Hard fail on non Linux if we would block since there’s no
> non-blocking and “probably good enough” interface.
>         * Soft fail and get “probably good enough” random from os.urandom
> on Linux, and use time/pid/memory offsets on non Linux.
>     * Just use the best source of random available to use on the system,
> and block rather than fail.
> I don’t see any way to get the same wide set of options by just adding
> flags to os.urandom unless we add flags that work for every possible
> combination of what people may or may not want to.
>> Donald Stufft

--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160611/03beaf8d/attachment.html>

More information about the Python-Dev mailing list