On 08/06/2020 08:04, Glyph wrote:
<a bunch of valid stuff>
I'm going to start here by saying: I agree with almost all of what you wrote, but at the end of the day, I don't get to determine our customers' policies. You can try to explain to them why their policies are misguided, but particularly when you're working with a large organisation, change can be very slow. So you end up working around the policy, whether you agree with it or not. In practical terms, that means that for now at least we need to support Python 3.5. As Erik said, we certainly have no right to demand that Twisted continue to support 3.5: indeed, if dropping support will deliver value to the project, then I'd encourage you to go for it; and as you've already said, the whole thing is probably moot anyway given the timescales we're talking about.
I believe in this case its a general desire to keep track of what packages are running and where they've come from. They basically trust that packages from official Debian repositories are probably safe from being tampered with, whereas random tarballs of code from the web are not safe (unless they're signed by someone they trust or whatever).
I think this sounds like a misunderstanding of Debian's vetting process? It's not like there's a ton of additional auditing that goes into packaging something. There's definitely an authentication process for both Twisted and Python, although this attestation could be somewhat stronger and less centralized, PyPI does quite a bit of heavy lifting there.
I think it's less that they think that Debian does extra vetting, and more that, especially if you're managing whole fleets of servers, then if everything runs the same version, it's easier to keep track of what you need to upgrade when there's a "security" bug. And yes, there are plenty of counterarguments to this, but that's the reasoning.
1. Many non-"security" bugs are in fact security bugs that nobody has noticed you can exploit. 2. Many "low-severity" or "un-exploiable" security bugs are in fact exploitable 3. "supported" distros rarely take care to backport many patches for their software, and when they do, they often make undetected errors (like debian's infamous ssh bug) which are analyzed by far fewer security analysts than the upstream source code.
These are probably all true, but taken to their logical extreme, the conclusion seems to be "you should always run the bleeding edge of all software, to make sure you've got all the latest bug fixes". I don't think you're really arguing for that, so the point is: we end up nominating "stable" versions, and trying to make an assessment as to which bugfixes are worth backporting. That latter part is a subjective decision, and the question is who you trust to make it. You may not trust Debian to make that decision on your behalf (with perfectly valid reasons), but plenty of others do.
So I feel like the folks making the decision to stick with these old "supported" distros are only getting half the story - sure, it won't break, but are they /actually/ getting the security fixes that they think they are? Debian's staff are stretched pretty thin as it is.
A counterpoint here is that the Python in oldstable has had several years of bugfixes, and of course it was the primary Debian-supported version of Python for a good couple of years. Again, I know that peoples' assessment of Debian's ability or competence varies, but I don't think it's *unreasonable* to assume that by this point the worst problems with that version of Python have been shaken out (and that if a significant new problem arises, a fix will be made).
In terms of twisted dropping support of 3.5, I guess the question is to what extent do you want applications to be hassle free to deploy on the more "enterprise" style environment?
One other confusion I have about these environments is why they want very-old Python but don't /also/ want very-old Twisted.
Well, again, it comes down to fleet management, and responsibility for "security". From the customer's point of view, they want to provide a python interpreter which runs our application. So the Python interpreter is their responsibility (hence: use Debian oldstable everywhere), whereas the stuff running on it is ours. Plus, since there's only one thing using Twisted in their network, it's inherently easier to maintain a single version. (I also fear that there is a misguided belief that security vulnerabilities are "worse" if they are in the Python interpreter, because that runs native code, whereas Twisted can't possibly do anything that bad because "interpreted language". I mention this only for completeness, and fully realise it's nonsense.)
But supporting old Pythons, old service_identity modules, old OpenSSL's, etc, has been seeming more and more to me like a disservice to the community, because it facilitates the adoption of slow, insecure, dangerous deployment practices so we're not doing anyone any favors.
Whilst I largely agree with the sentiment, I suspect it's a bit idealistic to take this to an extreme.