[Python-ideas] Python's Source of Randomness and the random.py module Redux
ncoghlan at gmail.com
Tue Sep 15 02:36:52 CEST 2015
On 15 September 2015 at 01:01, Paul Moore <p.f.moore at gmail.com> wrote:
> 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".
This may be at the core of the disagreement, as we're not talking "one
or two people", we're talking tens of millions. While wearing my "PSF
Director" hat, I spend a lot of time talking to professional
educators, and recently organised the first "Python in Education"
miniconf at PyCon Australia. If you look at the inroads we're making
across primary, secondary and tertiary education, as well as through
workshops like Software Carpentry and DjangoGirls, a *lot* of people
around the world are going to be introduced to text based programming
over the coming decades by way of Python.
That level of success brings with it a commensurate level of
responsibility: if we're setting those students up for future security
failures, that's *on us* as language designers, not on them for
failing to learn to avoid traps we've accidentally laid for them
(because *we* previously didn't know any better).
Switching back to my "security wonk" hat, the historical approach to
computer security has been "secure settings are opt in, so only
qualified experts should be allowed to write security sensitive
software". What we've learned as an industry (the hard way) is that
this approach *doesn't work*.
The main reason it doesn't work is the one that was part of the
rationale for the HTTPS changes in PEP 476: when security failures are
silent by default, you generally don't find out that you forgot to
flip the "I need this to be secure" switch until *after* the system
you're responsible for has been compromised (with whatever
consequences that may have for your users).
The law of large numbers then tells us that even if (for example) only
1 in 1000 people forget to flip the "be secure" switch when they
needed it (or don't even know that the switch *exists*), it's a
practical certainty that when you have millions of programmers using
your language (and you don't climb to near the top of the IEEE
rankings without that), you're going to be hitting that failure mode
regularly as a collective group.
We have the power to mitigate that harm permanently *just by changing
the default behaviour of the random module*. However, that has a cost:
it causes problems for some current users for the sake of better
serving future users. That's what transition strategy design is about,
and I'll take that up in the other thread.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas