skip to content

On Debian stable, a package's upstream version number stays the same for the entire life of the release, sometimes years after upstream has moved on. Does that mean the package stops receiving fixes, and what are your options when you genuinely need something newer?

level: middleimportance: should knowfreq 55%

answer

  1. old version number is a policy, not neglect
  2. the upstream version never moves mid-release
  3. the patch, not the release, is what ships
  4. look at the revision suffix, not upstream
  5. one package at a time, opted in

basics

~20 s

No. Debian freezes the upstream version deliberately and backports security and critical fixes into it, bumping only the Debian revision. When you truly need newer software, the sanctioned route is the backports suite, opted into one package at a time.

solid answer

~50 s

Freezing the upstream version is the product, not neglect. Debian's security team backports the patch for a vulnerability into the version that shipped with the release and publishes it through the `<codename>-security` suite, bumping only the Debian revision — so a version string like `1.2.3-4+deb12u1` is the same upstream `1.2.3` with a security fix applied. Other important non-security fixes arrive in the periodic point releases. The benefit is that the behaviour of the platform does not change under you mid-release, and an automatic upgrade run cannot hand you a new upstream major version overnight. When you genuinely need newer software, the sanctioned route is `<codename>-backports`: packages rebuilt from testing against stable, opt-in per package via `apt-get install -t`, and carried with weaker support guarantees. The alternatives are vendoring the dependency with your own application, or an upstream-maintained repository — both of which move that package's patching burden onto you.

code

bash · 7 lines
bash
# Enable the backports suite for Debian 12 (bookworm)
echo 'deb http://deb.debian.org/debian bookworm-backports main' \
  | sudo tee /etc/apt/sources.list.d/backports.list
sudo apt-get update

# Nothing comes from backports unless asked for by name
sudo apt-get install -t bookworm-backports linux-image-amd64

go deeper

for a junior

Say clearly that Debian stable keeps the upstream version fixed on purpose and that security fixes are patched into it, so an old-looking version is not the same as an unpatched one.

for a middle

Explain the three channels feeding a stable release — the security suite, the updates suite and point releases — and read a version string like 1.2.3-4+deb12u1 aloud, naming which part moves when a CVE is fixed.

for a senior

Demonstrate that you choose escape hatches deliberately: know that backports are opt-in per package with weaker guarantees, and be able to explain to a compliance team why a version-number-only scanner over-reports on Debian.

for a principal

Own the trade-off as a platform decision — currency versus behavioural stability — and be able to state which packages your organisation has moved off Debian's support surface onto its own, and who patches them when a CVE lands.

## What "frozen version" actually means When a Debian release is published, the upstream version of every package in it is fixed for the life of that release. If the release shipped a web server at upstream 1.22, that release will still be offering upstream 1.22 three years later. This is a deliberate policy decision, and it is the single most misread thing about Debian: candidates read an old version number as evidence that the package is unmaintained. It is the opposite. Freezing versions is what makes stable *stable*: the interfaces, config file formats, defaults and behaviours you validated on day one are the ones you still have on day nine hundred. An automatic upgrade run cannot silently move you to a new upstream major release with different semantics. ## How fixes reach a frozen package Three channels feed a stable release: - **The security suite** — `<codename>-security`, served from Debian's security host. When a CVE affects a package in stable, the security team (usually working with the maintainer and upstream) extracts the fix and applies it as a patch to the frozen upstream source, rather than upgrading to whatever upstream released. The rebuilt package keeps its upstream version and gains a Debian revision suffix. - **The updates suite** — `<codename>-updates`, for changes that are not security fixes but cannot wait for the next point release, such as time-zone data. - **Point releases** — periodic refreshes of the release media (12.1, 12.2, and so on) that roll accumulated fixes into the installer images. A point release is not a new release; it changes no upstream versions beyond what has already been published. ## Reading the version string A Debian version is `upstream-debian_revision`, with security rebuilds adding a further suffix: ``` 1.2.3-4+deb12u1 │ │ │ │ │ └─ security/point-release update for Debian 12 │ └──── Debian packaging revision └────────── upstream version ``` So when a scanner reports "1.2.3 is vulnerable to CVE-XXXX", the honest answer on Debian is often "the upstream version is 1.2.3, and the patch for that CVE is already in `-4+deb12u1`". Version-number-only scanners generate a great deal of false-positive noise on Debian for exactly this reason, and being able to explain that in an interview is worth more than reciting the suite names. ## The consequence you have to plan for The policy has a real cost: if your application needs a runtime or library newer than the one the release froze, stable will not give it to you, and it will not give it to you later either. You have to choose an escape hatch consciously: - **Backports.** `<codename>-backports` holds packages taken from testing and rebuilt against stable. They are opt-in twice over: you add the suite, and even then nothing installs or upgrades from it unless you ask for it by name. Support is weaker than for stable proper — backports get less testing and are not carried by the security team in the same way — so treat each one as a package you have chosen to own. - **Vendor the dependency.** Ship the runtime with your application rather than consuming the distribution's. This is the common answer for language runtimes, and it moves the patching duty to your build pipeline. - **An upstream repository.** Many projects publish their own Debian repository. That gives you current versions and hands you the upstream project's security cadence and packaging quality instead of Debian's. - **Do not mix suites.** Pointing a stable machine at testing or unstable to grab one newer package is the classic self-inflicted outage: dependency resolution pulls in a newer C library and effectively half-upgrades the system into a state nobody supports and no upgrade path repairs. ## The judgment an interviewer is listening for A good answer names the trade being made. Debian stable buys you a platform that does not change underneath you and gets vulnerabilities fixed without behavioural churn; it costs you currency. Backports are the sanctioned, per-package release valve for that cost, and every package you take from backports or an upstream repository is a package you have quietly moved from Debian's support surface onto your own.

  • A compliance scanner flags dozens of "outdated, vulnerable" packages on your Debian servers. How do you respond?
    Check whether the scanner compares upstream version numbers alone. On Debian the fix is backported into the frozen upstream version, so the number stays put while the Debian revision advances. Verify against the security tracker entry for each CVE and the installed revision, then configure the scanner to consume distribution security metadata rather than raw version strings. Do not upgrade packages just to make the report quiet.
  • Why does taking one package from backports carry less risk than pointing the machine at testing?
    A backported package is rebuilt against the stable release's libraries, so it installs without dragging newer core dependencies in. Adding testing to your sources instead lets dependency resolution pull a newer C library and toolchain, half-upgrading the system into a mixed state with no supported upgrade path. Backports also stay opt-in per package, so nothing else on the machine changes.

saying these in an interview costs you the question

  • Assumes an old version number means the package is unpatched
  • Thinks security fixes arrive as upstream version upgrades
  • Adds testing or unstable to a stable machine's sources
  • Believes backports install and upgrade automatically once enabled
  • Treats a point release as a new distribution release

context

resolving links…