[Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

[Barry Warsaw]

On Jun 16, 2016, at 06:04 AM, Donald Stufft wrote:

>Regardless of what we document it as, people are going to use os.urandom for
>cryptographic purposes because for everyone who doesn’t keep up on exactly
>what modules are being added to Python who has any idea about cryptography at
>all is going to look for a Python interface to urandom. That doesn’t even
>begin to touch the thousands upon thousands of uses that already exist in the
>wild that are assuming that os.urandom will always give them cryptographic
>random, who now *need* to write this as:

[...]

>Frankly, I think it’s a disservice to Python developers to leave in this
>footgun.

This really gets to the core of our responsibility to our users.  Let's start
by acknowledging that good-willed people can have different opinions on this,
and that we all want to do what's best for our users, although we may have
different definitions of "what's best".

Since this topic comes up over and over again, it's worth exploring in more
detail.  Here's my take on it in this context.

We have a responsibility to provide stable, well-documented, obvious APIs to
our users to provide functionality that is useful and appropriate to the best
of our abilities.

We have a responsibility to provide secure implementations of that
functionality wherever possible.

It's in the conflict between these two responsibilities that these heated
discussions and differences of opinions come up.  This conflict is exposed in
the os.urandom() debate because the first responsibility informs us that
backward compatibility is more important to maintain because it provides
stability and predictability.  The second responsibility urges us to favor
retrofitting increased security into APIs that for practicality purposes are
being used counter to our original intent.

It's not that you think backward compatibility is unimportant, or that I think
improving security has no value.  In the messy mudpit of the middle, we can't
seem to have both, as much as I'd argue that providing new, better APIs can
give us edible cake.

Coming down on either side has its consequences, both known and unintended,
and I think in these cases consensus can't be reached.  It's for these reasons
that we have RMs and BDFLs to break the tie.  We must lay out our arguments
and trust our Larrys, Neds, and Guidos to make the right --or at least *a*--
decision on a case-by-case basis, and if not agree then accept.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160616/6d6f8a95/attachment.sig>