Why/how can distro support lifetimes exceed the lifetime of their dependencies (such as Python)?
Motivating example: my Mint 20.3 distribution offers long-term support until April 2025, which matches the "standard support" offered for the upstream Ubuntu (20.04 "Jammy Jellyfish"). However, the system-provided Python version is 3.8, which reaches the end of security support this October, half a year earlier.
Similarly, the next LTS Ubuntu release (and corresponding Mint release) are based on Python 3.10, which will similarly EOL half a year before the end of support for the Linux distros. Both Python and Ubuntu/Mint offer a total of 5 years of support (Ubuntu Pro notwithstanding), and Python now has a 1-year release cadence while Ubuntu and Mint do major-version LTS releases every 2 years - so they are advancing in lock-step.
Should I expect my system Python to be automatically updated (or to be prompted for an update) at some point? Or else, why would the maintainers deliberately offer an additional 6 months of support for an OS that depends on a no-longer-supported version of Python?
More generally, how does it make sense to offer this kind of support schedule, outlasting system components that are no longer maintained by their respective authors?
2 answers
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| Karl Knechtel | (no comment) | Apr 1, 2024 at 05:20 |
When an upstream project stops supporting a version (e.g., Python stops supporting 3.8), the maintainers of the distribution do the job of supporting those components, applying security patches as necessary.
You can expect that their knowledge of the project isn't as comprehensive as that of the programmers of the upstream project. Also, one packager tends to be responsible for hundreds of packages, which is not ideal. As a consequence, the support is often not-so-good, and only security vulnerabilities are fixed, not just every bug. (There are exceptions, and in some cases, the support from your distribution may be better than the original support from the upstream programmers.)
It can make sense because some upstream projects may not support stable branches at all, so from day 0, distributions need to take care of back-porting bug fixes. You could say that a version in those projects is EOL the day after the release.
In some other cases, upstream may support stable branches, but for a time that the distribution considers too short. For example, Debian releases every 2 years, and releases are stable for 2 years, then oldstable and oldoldstable, with a support of almost a decade in total. Most upstreams won't commit to maintaining branches for a decade, so someone from Debian must do the work.
Why do it? Because if you have a system that works, it costs money to update it to use a newer version, and it's also risky. Of course, it's also risky to use an outdated version that might have bugs that were (sometimes accidentally) fixed in newer versions and nobody noticed that the old versions should be patched. And it also costs money to support old versions. But it's a balance where doing it might be worth it.
For a personal use case, since the cost of upgrading the OS in your personal computer is low (and the eventual time cost of an upgrade from oldoldstable to stable could be significant, as too much changed at once), I think it makes more sense to run stable or even unstable OS versions on personal computers. As long as you trust the distributors to not break those versions too often that they're unusable. I've been using Debian unstable for many years and rarely had any problems with it, and only minor ones for a few days.
If you run a company with 1000s of servers that you don't want to break ever, you may consider it good to pay some distribution developers to fix security vulnerabilities in EOL packages that you use, so that you don't need to upgrade those systems' OSes, which could cost a lot more than that.
When PSF says Python 3.8 is not supported, they are simply saying they will no longer bother fixing bugs in or adding stuff to that version. It's not like Python 3.8 will start automatically exploding your computer the moment they drop support. They just don't want you to come complain to them if you do find something in it that doesn't work.
If Mint devs want to release some Mint 20.3 LTS, and they want to put Python 3.8 into that, the users cannot expect to get help from PSF on problems with that Python. PSF will just tell them to upgrade to Python 3.9. Instead, they will have to ask the Mint devs, since they are the ones who support it.
In practice, this is a question that comes down to critical security vulnerabilities that may get discovered in Python 3.8. There might be non-security things, like garden variety usability bugs, but for those your solution would be "deal with it" (or upgrade). It's only really for security issues that "deal with it" is not an option.
If it turns out that Python 3.8 has a critical security hole, I would expect the Mint devs to release an update that fixes it. They could try to write their own patch to Python itself. For example, let's say the last "official" version of 3.8 is Python 3.8.10. Mint devs could try to develop Python 3.8.11mint and release that in the LTS repos. More practical would be to simply bump Python to 3.9 in the repos. Minor versions of Python are intended to be backwards compatible, so nothing that worked in 3.8 should break in 3.9. But if something does break, it would be up to the Mint devs to fix that too (by bumping the version or writing a patch).
However, security is really a problem with servers on the public internet. The moment, say, a security vulnerability becomes known in Python 3.8 then someone could take that vuln and immediately hack a server that is using 3.8 in an applicable way. So keep in mind, for example, if you have a server hosting your personal website using nginx and hand-written HTML, and that server happens to be running Python, that doesn't mean it's vulnerable - vulnerabilities have some specific attack vector that's required to exploit them. If your server doesn't actually have a way for outside visitors to reach Python or run Python code (including running programs that rely on Python under the hood) then it's not actually vulnerable. But in any case, if it is vulnerable then there is a need to urgently fix the vuln with a patch, even if it's running an ancient Python, because it might take too long to upgrade Python. Say you take a day to update Python and then update everything else that depends on the old Python - meanwhile, perhaps hackers read about the vuln and used it to hack your server already.
Mint, however, is mostly a distro for use on Desktops and laptops, not servers. These types of machine are not even on the internet - you cannot connect to them even if you know their IP. Routers are not normally configured to forward inbound connections to their ports, and even if they did, they're not usually running any programs that listen on those ports. So even if there was a vuln on this type of PC, it's extremely unlikely that it would be possible to exploit it. The majority of vulns basically don't apply, because by simply not accepting inbound connections from the internet, these machines are already very tightly secured. I suspect this is why Mint is being a bit vague about such things. Server distros will usually pay a bit more attention to details like this.
0 comment threads
0 comment threads