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

[Cory Benfield]

On 14 September 2015 at 16:01, Paul Moore <p.f.moore at gmail.com> wrote:
> 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.

What makes you think that I didn't take it into account? I did: and
then rejected it. On a personal level, I believe that defaulting to
more secure is worth backward compatibility breaks. I believe that a
major reason for the overwhelming prevalence of security
vulnerabilities in modern software is because we are overly attached
to making people's lives *easy* at the expense of making them *safe*.
I believe that software communities in general are too concerned about
keeping the stuff that people used around for far too long, and not
concerned enough about pushing users to make good choice.

The best example of this is OpenSSL. When compiled from source naively
(e.g. ./config && make && make install), OpenSSL includes support for
SSLv3, SSL Compression, and SSLv2, all of which are known-broken
options. To clarify, SSLv2 has been deprecated for security reasons
since 1996, but a version of OpenSSL 1.0.2d you build today will
happily enable *and use* it. Hell, OpenSSL's own build instructions
include this note[0]:

> OpenSSL has been around a long time, and it carries around a lot of
> cruft. For example, from above, SSLv2 is enabled by default. SSLv2 is
> completely broken, and you should disable it during configuration.

Why is it that users who do not read the wiki (most of them) get an
insecure build? Backwards compatibility is why.

This is necessarily a reductio ad absurdum type of argument, because
I'm trying to make a rhetorical point: I believe that sacrificing
security on the altar of backwards compatibility is a bad idea in the
long term, and I want to discourage it as best I can.

I appreciate your desire to maintain backward compatibility, Paul, I
really do. And I think it is probably for the best that people like
you work on projects like CPython, while people like me work outside
the standard library. However, that won't stop me trying to drag the
stdlib towards more secure defaults: it just might make it futile.