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

Donald Stufft donald at stufft.io
Thu Jun 9 08:59:57 EDT 2016

> On Jun 9, 2016, at 8:53 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> Excerpts from R. David Murray's message of 2016-06-09 08:41:01 -0400:
>> On Thu, 09 Jun 2016 13:12:22 +0100, Cory Benfield <cory at lukasa.co.uk> wrote:
>>> The Linux kernel can���t change this stuff easily because they mustn���t
>>> break userspace. Python *is* userspace, we can do what we like, and we
>> I don't have specific input on the rest of this discussion, but I disagree
>> strongly with this statement.  The environment in which python programs
>> run, ie: the python runtime and standard library, are *our* "userspace",
>> and the same constraints apply to our making changes there as apply
>> to the linux kernel and its userspace...even though we knowingly break
>> those constraints from time to time[*].
>> --David
>> [*] Which I think the twisted folks at least would argue we shouldn't
>> be doing :)
> I agree with David. We shouldn't break existing behavior in a way
> that might lead to someone else's software being unusable.
> Adding a new API that does block allows anyone to call that when
> they want guaranteed random values, and the decision about whether
> to block or not can be placed in the application developer's hands.

I think this is a terrible compromise. The new API is going to be exactly the
same as the old API in 99.9999% of cases and it's fighting against the entire
software ecosystem's suggestion of what to use ("use urandom" is basically a
meme at this point). This is like saying that we can't switch to verifying
HTTPS by default because a one in a million connection might have different
behavior instead of being silently insecure.

Donald Stufft

More information about the Python-Dev mailing list