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.
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
