On 2016-06-10 05:48, Donald Stufft wrote:
On Jun 9, 2016, at 11:11 PM, Larry Hastings <larry@hastings.org <mailto:larry@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