Understanding and Dealing With LTS Differences

This page provides brief explanations of some key differences between “regular” security support and LTS, including guidance for dealing with these differences.

Reduced Hardware Architecture Support

Difference

A reduced range of hardware architectures are supported; currently amd64, i386, arm64, armel, and armhf.

Explanation

Certain architectures are considerably less popular than others and the less popular architecures are generally also more difficult to support. There are a variety of reasons for this. Among those reasons are that some architectures have fewer build resources available (all security updates must be built for all supported hardware architectures), and also that when the build resources are available then dealing with architecture-specific bugs and regressions can be a very time-consuming process.

The currently supported list of architectures for LTS covers greater than 99.8% of reported Debian users. The exclusion of hardware architectures which have very low usage rates and which are also more difficult to support allows the Debian LTS Team to much more efficiently apply limited resources.

What to do

The most likely scenario is that you are not at all affected by this particular difference. However, in the unlikely event that you are affected, there are two possible avenues available to you.

If you already have hardware which is not on the supported architecture list, then your only recourse is to upgrade to a newer Debian release.

If you are in the acquisition phase and still able to influence the decision over what hardware to acquire, then choose a hardware architecture that is on the above list.

Publication of Security Announcements

Difference

Announcements concerning security updates are published differently by the Debian LTS Team as compared to the Debian Security Team.

Explanation

There exists a close collaboration between the Debian Security Team and the Debian LTS Team. However, as the Debian LTS Team is a much younger team and because the idea of LTS in Debian was not yet proven when the Debian LTS Team was formed, certain elements of infrastructure were created separately and they continue to remain separate. Among these separate infrastructure elements are the places where security advisories are published. The Debian Security Team publishes a Debian Security Advisory (DSA) for each update which they publish. The announcements for DSAs are sent to the debian-security-announce mailing list and the advisories are also available on the Security Information page. Once the Debian LTS Team assumes responsibility for supporting a particular Debian release, the advisories are designated Debian LTS Advisory (DLA) and published to the debian-lts-announce mailing list. Alternate sources for monitoring DLAs are available on the LTS Security Information page.

What to do

If you are responsible for managing one or more Debian systems beyond 3 years from the initial release date, then you should consider subscribing to the debian-lts-announce mailing list or monitoring one of the alternative feeds available on the LTS Security Information page.

Discontinuation of Support for Backports

Difference

Backports are not supported after 3 years from the initial release date.

Explanation

While stability is a cornerstone of any Debian stable release, there are occasions that demand more recent versions of certain packages. In order to provide a solution between the choices of remaining on a stable release with potentially outdated packages and moving wholesale to the testing or unstable distributions, Debian provides backports. More recent versions of select packages are rebuilt and provided for installation on the current Debian stable release.

Backports are provided by a dedicated team that is separate from both the Debian Security Team and the Debian LTS Team. Their policy is that once one year has passed from the initial release of a Debian stable release, the backports suite for the preceding stable release is closed. Put another way, because Debian releases are roughly 2 years apart, users should not expect support for backports after 3 years from the initial release date of a given Debian stable release.

Given the purpose of backports, to provide an interim solution by making more current versions of select packages from the testing and unstable distributions available on a Debian stable release, it stands to reason that once a stable release is made with those package versions (or newer) that the backports would diminish in utility.

What to do

If your configuration depends on backports, then it is important to understand that any packages installed from the backports repository will not receive security updates from the Debian LTS Team. You are advised to revert to versions of those packages which are included in the security support scope of the Debian LTS Team, or instead to upgrade to a more recent Debian stable release.

Discontinuation of Support for Specific Packages

Difference

Packages which have passed the point of being fully supportable may have their scope of support reduced, they be dropped from support, or they may be updated to entirely new versions.

Explanation

This particular item is not so much a difference as it is a reality which becomes more apparent later in the lifecycle of a given release. Which is to say, these occurrences are more likely in the final 2 years of the life of a Debian release.

In general, as software ages it can become more difficult to support. Debian includes a wide variety of extraordinarily complex packages and our ability to continue supporting these packages often depends on the assistance of upstream developers. This reality is faced by both the Debian Security Team and the Debian LTS Team. For the Debian LTS Team the situation becomes more acute, as older software is often more difficult to support. Upstream developers may have moved on and not have an interest in backporting fixes to older versions of their software. Sometimes, the code has changed so radically that it is not possible to backport a patch to address a given vulnerability because the existing patch is too disruptive to safely backport, necessitating the development of an entirely new mitigation from scratch. This can be an extrememly demanding process from a technical perspective and it may carry substantial risk.

The alternatives in such situtions, whether to try to backport patches with a high probability of regression or to allow packages to remain vulnerable with no official action, are deemed to be harmful to our users.

Instead, in the interest of being good stewards of the trust which our users place in Debian, it may be necessary to reduce the scope of support for a package (such was the case in 2023 with samba, which had its scope of support reduced to exclude Active Directory Domain Controller features from security support), to discontinue security support entirely (such was the case in 2023 with tor), or to ugprade to an entirely new version of a package (as was the case in 2023 with freerdp2).

What to do

Because of the nature of these situations, there is not really any specific action which users can be recommended to take. Rather, users must be aware that such situations may arise from time to time, and they must be watchful for such announcements in order to take appropriate action if they are affected.

No Point Releases or Installer Images

Difference

No further point releases, no new installers, and no new installer image releases after 3 years from the initial release date.

Explanation

Once a Debian stable release is made it comes under the responsibility of the Debian Release Management Team. While the Debian Security Team is responsible for coordinating, preparing, and uploading security updates, the Debian Release Management Team is responsible for periodically making new point releases, which incorporate all security updates which have been made for that release, along with fixes for high severity bugs, and updates for packages which require periodic non-security updates (e.g., timezone data files, antivirus signatures, etc.). Along with the point release, a new version of the Debian installer is released, as is a new set of installation media images. The teams which are responsible for this, the Debian Release Management Team and the Debian Installer Team, are separate from the Debian Security Team and their commitment is to support a Debian stable release for 3 years from the initial release date.

Because the work of both the Debian Release Management Team and the Debian Installer Team requires interacting with complex aspects of the Debian archive infrastructure, and because the complexity of those parts of the infrastructure as well access to them is beyond the scope of what the Debian LTS Team is able to manage, point releases and installer releases are discontinued 3 years following the initial date of a Debian stable release.

Consequently, certain classes of bug fixes which may generally be addressed in a stable point release are not able to be addressed by the Debian LTS Team. In some instances, like timezone data files and antivirus signatures, the Debian LTS Team will upload updated packages and accompany them with a DLA, as if they were a security update.

What to do

From a practical standpoint, this only impacts users if having access to very recent installation media is a particular requirement. If this is not the case for you, then simply performing regular updates of your existing system(s) will ensure that all applicable updates (security and otherwise) will be installed as they are published.