[Twisted-Python] [RFC] Drop support for Python 3.5 sometime after May 2021?

[Richard van der Hoff]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20200608/c5ce45c4/attachment.htm>