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

[Nick Coghlan]

On 15 September 2015 at 08:39, Paul Moore <p.f.moore at gmail.com> wrote:
> * I can't think of a single occasion where we *don't* do X. That may
> well be confirmation bias, but again subjectively, it feels like
> nobody's listening to the objections. I get that the original
> proposals get modified, but if never once has the result been "you're
> right, the cost is too high, we'll not do X" then that puts
> security-related proposals in a pretty unique position.

Most of the time, when the cost of change is clearly too high, we
simply *don't ask*. hmac.compare_digest() is an example of that, where
having a time-constant comparison operation readily available in the
standard library is important from a security perspective, but having
standard equality comparisons be as fast as possible is obviously more
important from a language design perspective.

Historically, it was taken for granted that backwards compatibility
concerns would always take precedence over improving security
defaults, but the never-ending cascade of data breaches involving
personally identifiable information are proving that we, as a
collective industry are *doing something wrong*:
http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/

A lot of the problems we need to address are operational ones as we
upgrade the industry from a "perimiter defence" mindset to a "defence
in depth" mindset, and hence we have things like continuous
integration, continuous deployment, application and service
sandboxing, containerisation, infrastructure-as-code, immutable
infrastructure, etc, etc, etc. That side of things is mostly being
driven by infrastructure software vendors (whether established ones or
startups), where we have the fortunate situation that the security
benefits are tied in together with a range of operational efficiency
and capability benefits [1].

However, there's also increasing recognition that some of the problems
are due to the default behaviours of the programming languages we use
to *create* applications, and in particular the fact that many
security issues involve silent failure modes. Sometimes the right
answer to those is to turn the silent failure into a noisy failure (as
with certificate verification in PEP 476), other times it is about
turning the silent failure into a silent success (as is being proposed
for the random module API), and yet other times it is simply about
lowering the barriers to someone doing the right thing once they're
alerted to the problem (as with the introduction of
hmac.compare_digest() and ssl.create_default_context(), and their
backports to the Python 2.7 series)

At a lower level, languages like Go and Rust are challenging some of
the assumptions in the still dominant C-based memory management model
for systems programming. Rust in particular is interesting in that it
has a much richer compile time enforced concept of memory ownership
than C does, while still aiming to keep the necessary runtime support
very light.

Regards,
Nick.

[1] For folks wanting more background on some of the factors this
shift, I highly recommend Google's "BeyondCorp" research paper:
http://research.google.com/pubs/pub43231.html

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia