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

Donald Stufft donald at stufft.io
Mon Sep 14 22:36:16 CEST 2015

On September 14, 2015 at 3:27:22 PM, Paul Moore (p.f.moore at gmail.com) wrote:
> On 14 September 2015 at 17:00, Cory Benfield wrote:
> > 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.
> OK. In *my* experience, systems with appallingly bad security
> practices run for many years with no sign of an exploit. The
> vulnerabilities described in this thread pale into insignificance
> compared to many I have seen. 

What does "no sign of an exploit" mean? Does it mean that if there was an
exploit that the attackers didn't put metaphorical giant signs up to say that
"Zero Cool" was here? Or is there an active security team running IDS software
to ensure that there wasn't a breach?

I ask because in my experience, "no sign of an exploit" is often synonymous
with "we've never really looked to see if we were exploited, but we haven't
noticed anything". This is a dangerous way to look at it, because a lot of
exploitation is being done by organized crime where they don't want you to
notice that you were exploited because they want to make you part of a botnet
or to silently steal data or whatever you have. For these, if they get detected
that is a bad thing because they lose that node in their botnet (or whatever).

It's a very rare exploit that gets publically exposed like the Ashley Madison
hacks, they are jsut the ones that get the most attention because they are
bombastic and public.

> On the other hand, I regularly see
> systems not being upgraded because the cost of confirming that there
> are no regressions (much less the cost of making fixes for deliberate
> incompatibilities) is deemed too high.


However, I think these systems largely don't upgrade *at all* and are still on
whatever version of $LANG they originally wrote the software for. These systems
tend to be so regression adverse that they don't even risk bug fixes because
that might cause a regression. For these people, it doesn't really matter what
we do because they aren't going to upgrade anyways, and they keep Red Hat in
business by paying them for Python 2.4 until the heat death of the universe.

I think the more likely case for concern is people who do upgrade and are
willing to tolerate some regression in order to stay somewhat current. These
people will push back against *massive* breakage (as seen with the Python 3.x
migration taking forever) but are often perfectly fine dealing with small
breakages. As someone who does write software that supports a lot of versions
(currently, 6-7 versions of CPython alone is my standard depending if you
count pre-releases or not) having to tweak import statements doesn't even
really register in my "give a damn" meter, nor did it for the folks I know who
are in similar situations (though this is admittingly a biased and small

> I'm not trying to justify those things, nor am I trying to say that my
> experience is in any way "worth more" than yours. These aren't all
> Python systems. But the culture where such things occur is real, and I
> have no reason to believe that I'm the only person in this position.
> (But as it's in-house closed-source, it's essentially impossible to
> get any good view of how common it is).

I think maybe a problem here is a difference in how we look at the data. It
seems that you might focus on the probability of you personally (or the things
you work on) getting attacked and thus benefiting from these changes, whereas
I, and I suspect the others like me, think about the probability of *anyone*
being attacked.

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

More information about the Python-ideas mailing list