[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Christian Heimes]

On 2016-06-10 05:48, Donald Stufft wrote:
> 
>> On Jun 9, 2016, at 11:11 PM, Larry Hastings <larry at hastings.org
>> <mailto:larry at hastings.org>> wrote:
>>
>> I don't understand why so many people seem to think it's okay to break
>> old code in new versions of Python, when Python's history has shown a
>> similarly strong commitment to backwards-compatibility.
> 
> Python *regularly* breaks compatibility in X.Y+1 releases, and does it
> on purpose. An example from Python 3.5 would be PEP 479. I think
> breaking compatibility is a good thing from time to time, as long as
> it’s not done so with wanton disregard and as long as the cost is
> carefully weighed against the benefits.
> 
> One of the more frustrating aspects of trying to discuss security
> sensitive topics on python-dev is a feeling (at least from my end) that
> whenever someone wants to make something more secure [1] folks come in
> and try to anchor the discussion by treating backwards compatibility as
> some sort of sacred duty that can never be broken and the discussion
> ends up feeling (from the security side that I’m typically on) being try
> to justify the idea of ever breaking backwards compatibility, instead of
> weighing the cost/benefit of a particular change. On the flip side, when
> a different kind of change that breaks compatibility , say to make some
> behavior less confusing, gets brought up it feels like the discussion
> instead focuses on whether or not breaking compatibility is worth it in
> that particular instance.
> 
> I’m perfectly happy to accept that Python has decided to make a trade
> off differently than what I would prefer it, but the rhetoric that is
> employed makes trying to improve Python’s security an extremely
> frustrating experience for myself and others [2]. Feeling like you have
> to litigate that it’s *ever* OK to break compatibility before you can
> even get to the point of discussing if it makes sense in any particular
> instance, while watching other kinds proposals not have to do that is a
> pretty disheartening experience.
> 
> 
> [1] Making code more secure pretty much by definition means taking some
> code that previously executed and making it so it no longer executes,
> ideally only in degenerate and dangerous conditions, but in general,
> that’s always the case.
> 
> [2] I don’t want to name names, as they didn’t give me permission to do
> so, but these discussions have caused more than one person who tends to
> fall on the security side of things to consider avoiding contributing to
> Python at all, because of this kind of rhetoric.

Donald,

feel free to name me. I'm mentally exhausted and frustrated by the
discussions over the last days and weeks. As of now I'm considering to
step down from PSRT and take a long break from Python core development.

My frustration is mostly rooted in Dunning-Kruger effects. If you still
think that a CSPRNG can run out of entropy or that it is a good idea to
implement a crypto hash function in pure Python, then please go back to
the children table and let the grown-ups talk. You are still struggling
with basic addition and multiplication, while we discuss Laplace
transformation for linear ODEs and consult experts, who do quantum
fourier transformation to solve a hidden subgroup problem by converting
it from finite Abelian groups to Shor's quantum algorithm [1]. Quoting
Larry: "You must be this tall to ride the security train." </rant>

I'm well aware that I'm not a trained and studied cryptographer. Cory
and Donald repeatedly stated the same. However we are aware of our
shortcomings, know our limits and constantly follow the advice of
trusted experts. At least we combine enough experience to recognize bad
ideas.

Please, please don't add unnecessary noise to security discussions.
os.urandom() is not about the concrete foundation of a bike shed. It's
the f...reaking core catcher [2] of a nuclear power plant. You want to
have a secure core catcher when the nuclear reactor goes BOOOM and
spills hot molten, extremely radioactive Corium.

Christian


[1] Yes, that is a real thing. It will break all current asymmetric
ciphers like RSA and EC.
[2] https://en.wikipedia.org/wiki/Core_catcher