[Python-ideas] Python's Source of Randomness and the random.py module Redux

Donald Stufft donald at stufft.io
Mon Sep 14 17:17:34 CEST 2015

On September 14, 2015 at 11:01:36 AM, Paul Moore (p.f.moore at gmail.com) wrote:
> On 14 September 2015 at 14:29, Cory Benfield wrote:
> > Is your argument that there are lots of ways to get security wrong,
> > and for that reason we shouldn't try to fix any of them?
> This debate seems to repeatedly degenerate into this type of accusation.
> Why is backward compatibility not being taken into account here? To be
> clear, the proposed change *breaks backward compatibility* and while
> that's allowed in 3.6, just because it is allowed, doesn't mean we
> have free rein to break compatibility - any change needs a good
> justification. The arguments presented here are valid up to a point,
> but every time anyone tries to suggest a weak area in the argument,
> the "we should fix security issues" trump card gets pulled out.

How has it not been taken into account? The current proposal (best summed up
by Nick in the other thread) will not break compatability for anyone except
those calling the functions that are specifically about setting a seed or
getting/setting the current state. In looking around I don't see a lot of
people using those particular functions so most people likely won't notice the
change at all, and for those who there is a very trivial change they can make
to their code to cope with the change.

> For example, as this is a compatibility break, it'll only be allowed
> into 3.6+ (I've not seen anyone suggest that this is sufficiently
> serious to warrant breaking compatibility on older versions). Almost
> all of those SO questions, and google hits, are probably going to be
> referenced by people who are using 2.7, or maybe some version of 3.x
> earlier than 3.6 (at what stage do we allow for the possibility of 3.x
> users who are *not* on the latest release?) So is a solution which
> won't impact most of the people making the mistake, worth it?
> I fully expect the response to this to be "just because it'll take
> time, doesn't mean we should do nothing". Or "even if it just fixes it
> for one or two people, it's still worth it". But *that's* the argument
> I don't find compelling - not that a fix won't help some situations,
> but that because it's security, (a) all the usual trade-off
> calculations are irrelevant, and (b) other proposed solutions (such as
> education, adding specialised modules like a "shared secret" library,
> etc) are off the table.

We can't go back in time and fix those versions that is true. However, one of
the biggest groups of people who are most likely to be helped by this change is
new and inexperienced developers who don't fully grasp the security sensitive
nature of whatever they are doing with random. That group of people are also
more likely to be using Python 3.x than experienced programmers.

> Honestly, this type of debate doesn't do the security community much
> good - there's too little willingness to compromise, and as a result
> the more neutral participants (which, frankly, is pretty much anyone
> who doesn't have a security agenda to promote) end up pushed into a
> "reject everything" stance simply as a reaction to the black and white
> argument style.

If I/we were not willing to compromise, I'd be pushing for it to use
SystemRandom everywhere because that removes all of the possibly problematic
parts of using using a user-space CSPRNG like is being proposed. However, I/we
are willing to compromise by sacrificing possible security in order to not
regress things where we can, in particular a user-space CSPRNG is being
proposed over SystemRandom because it will provide you with random numbers
almost as fast as MT will.

However, when proposing this possible compromise, we are met with people
refusing to meet us in the middle. There are some folks who are trying to
propose other middle grounds, and there will undoubtably be some discussion
around which ones are the best. We've gone from suggesting to replacing the
default random with SystemRandom (a lot slower than MT) to removing the default
altogether, to deprecating the default and replacing it with a fast user-space

However, folks who don't want to see it change at all have thus far been
unwilling to compromise at all. I'm confused how you're saying that the
security minded folks have been unwilling to compromise when we've done that
repeatidly in this thread, whereas the backwards compat minded folks have
consistently said "No, it would break compatability" or "We don't need to
change" or "They are probably insecure anyways". Can you explain what
compromise you're willing to accept here? If it doesn't involve breaking at
least a little compatability then it's not a compromise it's you demanding that
your opinion is the correct one (which isn't wrong, we're also asserting that
our opinion is the correct one, we've just been willing to move the goal posts
to try and limit the damage while still getting most of the benefit).

Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

More information about the Python-ideas mailing list