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

[Donald Stufft]

> On Jun 16, 2016, at 8:50 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> 
> On 16 June 2016 at 12:34, Donald Stufft <donald at stufft.io> wrote:
>> [1] I don’t think using os.urandom is incorrect to use for security sensitive
>>    applications and I think it’s a losing battle for Python to try and fight
>>    the rest of the world that urandom is not the right answer here.
>> 
>> [2] python-dev tends to favor not breaking “working” code over securing existing
>>    APIs, even if “working” is silently doing the wrong thing in a security
>>    context. This is particularly frustrating when it comes to security because
>>    security is by it’s nature the act of taking code that would otherwise
>>    execute and making it error, ideally only in bad situations, but this
>>    “security’s purpose is to make things break” nature clashes with python-dev’s
>>    default of not breaking “working” code in a way that is personally draining
>>    to me.
> 
> Should I take it from these two statements that you do not believe
> that providing *new* APIs that provide better security compared to a
> backward compatible but flawed existing implementation is a reasonable
> approach? And specifically that you don't agree with the decision to
> provide the new "secrets" module as the recommended interface for
> getting secure random numbers from Python?
> 
> One of the aspects of this debate that I'm unclear about is what role
> the people arguing that os.urandom must change see for the new secrets
> module.
> 
> Paul

I think the new secrets module is great, particularly for functions
other than secrets.token_bytes. If that’s all the secrets module was
then I’d argue it shouldn’t exist because we already have os.urandom.
IOW I think it solves a different problem than os.urandom, if all you
need is cryptographically random bytes, I think that os.urandom is the
most obvious thing that someone will reach for given:

* Pages upon pages of documentation both inside the Python community
  and outside saying “use urandom”.
* The sheer bulk of existing code that is already out there using
  os.urandom for it’s cryptographic properties.

I also think it’s a great module for providing defaults that we can’t
provide in os.urandom, like the number of bytes that are considered
“secure” [1].

What I don’t think is that the secrets module means that all of a sudden
os.urandom is no longer an API that is primarily used in a security
sensitive context [2] and thus we should willfully choose to use a subpar
interface to the same CSPRNG when the OS provides us a better one [3]
because one small edge case *might* break in a loud an obvious way for
the minority of people using this API in a non security sensitive context
while leaving the majority of people using this API possible getting
silently insecure behavior from it.


[1] Of course, what is considered secure is going to be application
    dependent, but secrets can give a pretty good approximation for
    the general case.

[2] This is one of the things that really gets me about this, it’s not
    like folks on my side are saying we need to break the pickle module
    because it’s possible to use it insecurely. That would be silly
    because one of the primary use cases for that module is using it in
    a context that is not security sensitive. However, os.urandom is, to
    the best of my ability to determine and reason, almost always used in 
    a security sensitive context, and thus should make security sensitive
    trade offs in it’s API.

[3] Thus it’s still a small wrapper around OS provided APIs, so we’re not
    asking for os.py to implement some great big functionality, we’re just
    asking for it to provide a thin shim over a better interface to the
    same thing.

—
Donald Stufft