79 lines
11 KiB
Markdown
79 lines
11 KiB
Markdown
---
|
|
title: "Debian Packaging, Versioning, and Security"
|
|
description: "How the Stable Distribution does Security"
|
|
date: 2025-09-19
|
|
tags:
|
|
- Debian
|
|
- Development
|
|
---
|
|
|
|
## I ❤️ Debian
|
|
|
|
I've been using Debian, or a Debian-derived distribution, for my entire Linux journey, starting with Ubuntu 7.10 way back in 2007. I graduated to using Debian proper in 2014 or so, and also spent almost 12 years administering Debian server systems on a daily basis. I love Debian.
|
|
|
|
But one of the oldest and most depended-on distributions is often one of the most misunderstood. Everyone who's spent time in Linux communities has heard the old adage: "Debian is great, if you want to use 3-year-old software". And indeed, this aspect of Debian Stable is both a blessing, a curse, and a source of near constant misunderstandings by those not familiar with it.
|
|
|
|
In this post I hope to give a quick breakdown of how Packaging, Versioning, and Security work in Debian, what some of the benefits and downsides of it are, and why some of us actually _like_ that "3-year-old software" system.
|
|
|
|
## Understanding the Debian Project
|
|
|
|
Debian is unlike most of the other big, old distributions, and even many of its derivatives. It started in 1993, and continues to this day, releasing a new stable version roughly every 2 years; as of late 2025 they are on version 13, codenamed "Trixie".
|
|
|
|
Debian is a volunteer based project. While people are certainly paid to work on Debian, they are not paid _by_ Debian itself. Indeed Debian itself is run as what is called a "do-ocracy", or "rule by those who do the work". People contribute to Debian in the form of (Binary) Packages, which are the fundamental unit of the distribution.
|
|
|
|
Packages are what make up a Debian system; everything is inside a package, from the kernel, to the desktop environment, to any random package you install with `apt`. In fact, Debian is notable as one of the first distributions to be distributed in the form of binary (pre-compiled) packages; in 1993 most Linux systems had to be compiled yourself from source code, piece by piece. Debian changed the game by providing pre-compiled packages to users, making installing and updating very quick (with a sufficiently fast Internet connection, of course), making Linux far more accessible to people without a lot of time on their hands.
|
|
|
|
Debian as an organization structure consists primarily of Package Maintainers, who are known as Debian Developers. A Package Maintaner is someone who, as the name suggests, maintains or or more packages. There are of course teams and groupings within this, but the idea that "Debian Developers are Package Maintainers, and Package Maintainers create Binary Packages out of upstream software" is the basic unit. From there all the collective Debian Developers elect the project leader, and generally steer the distribution through that "do-ocracy" concept.
|
|
|
|
## Understandng Package Maintenance
|
|
|
|
To be a package maintainer is not an easy task. Let's use the example of Alice, who maintains Foo. Alice doesn't necessarily _write_ Foo, but she must be somewhat knowledgeable about how Foo works, how to build it from source, and generally keep up with the ongoing development of Foo as time goes on.
|
|
|
|
To get stated, Alice found Foo and decided to package it. She took the Foo source code and, though some fiddling, got it to compile into a Debian package. In the modern era, [this is actually fairly simple to do](/posts/debian-packaging-101), because most of the tooling and boilerplate has been well established; in the early days, it was much harder. She then submitted the package to Debian, where it was approved by other Debian Developers and became a part of the distribution, with Alice as the maintainer.
|
|
|
|
As time goes on and Foo releases new versions, it is Alices "responsibility" to keep up-to-date with those new versions, and keep the Debian package up-to-date. Now, "responsibility" is in quotes because ultimately she is a volunteer; she may be paid by someone (an employer, a community, etc.) to maintain Foo, but from the Debian side there is no obligation. And packages go unmaintained all the time; usually, they end up removed from the next stable version of Debian, especially if there are glaring issues. But as long as a package has a maintainer keeping it up-to-date, it has a future.
|
|
|
|
## Understanding Stability
|
|
|
|
One core concept of Debian is the idea of "stable releases". Stability in Debian does **not**, necessarily, mean "does not crash" as is common parlance among computer users. Instead, "stable" means "does not change over time".
|
|
|
|
In a Stable release of Debian, package versions are fixed. When a Stable Debian release is being finalized, all packages become "frozen" at a given version. Barring any last-minute show-stopping bugs, this is the version that will be available in that Debian Stable release for its entire lifetime. As an example, when Debian 13 was frozen, Alice's Foo was at version 1.3.1. So in Debian 13, Foo will _always_ be at version 1.3.1.
|
|
|
|
This is where that oft-repeated mantra "Debian has 3-year-old software" comes from, because fundamentally it's true. 3 years down the road, Foo might be on version 4.9.1; but Debian 13 will still have Foo 1.3.1 as its version, and that will never change.
|
|
|
|
So, why? Why would you want this? Well, that depends on your usecase. Speaking purely for myself, I value the stability of Debian Stable for 3 reasons:
|
|
|
|
1. It's one less thing to think about. I do not need to keep up-to-date on all the happenings of the 1000+ software packages I have installed, figuring out what's new and changed in each one every time I update my system. I know I'm on Foo 1.3.1 and that's that, and I like that.
|
|
|
|
2. It keeps consistency over time. Let's say Foo 2.0 introduces a new feature and deprecates an old feature; then Foo 3.0 removes that old feature. What if I depend on that feature for a workflow? The stability means that I only have to care about changes like this once: when _I_ decide to upgrade my system to the next Debian version. Until that time, the features I have are the features I have, warts and all. (Aside: there are ways around this, and there are packages so large and complex that this standard is broken, like Web Browsers; but for 99% of software this holds true).
|
|
|
|
3. It provides reliability (classic "stability"). It allows you to develop workarounds for known defects, bugs, or shortcomings, and those can remain in place for as long as you need. Especially for servers, this can be very important, since managing fleets of systems increases the cognitive complexity and burden of managing them exponentially without such stability. It also helps reduce things like training burden (learn once, keep that knowledge for years) for tools and systems, as you know that the version you have in a given Debian release won't suddenly change.
|
|
|
|
There are of course plenty of other reasons to want this, from sheer laziness, to massive corporate review bureaucracies; but the end result is the same: Debian Stable is a distribution you can trust day-in, day-out, to remain exactly the way you have it, for as long as you need.
|
|
|
|
## Understanding Security & Backports
|
|
|
|
Now that we have described the fundamentals, we can now talk about Security.
|
|
|
|
During my 10+ years administering Debian systems, one of the most common questions I got from clients, and especially their IT/Security teams, was "why are you running such an old version of X". To many, the idea that `New Software == Secure Software` and `Old Software == Insecure Software` is ingrained, because very few other operating systems - and especially non-Linux operating systems - offer the system for security management that Debian does.
|
|
|
|
Let's turn back to Alice and Foo 1.3.1. Let's say Foo 2.0.0 is out, and then someone reports a CVE for a major security bug. The Foo developers then release Foo 2.0.1 with a patch that fixes this bug. In most operating systems, the only thing you can now do to get this security fix is to upgrade to 2.0.1, with all the other changes that come with it. But Debian does things differently.
|
|
|
|
First, there is the Security team; this is a subset of Debian Developers who's job is to keep watch for CVEs like this, triage them, and report them to Package Maintainers. Debian is so large that it even has its own bug ID system, the DSA (Debian Security Advisory) system, for internal tracking. When a security bug is found, it is triaged, and Alice will be notified; presumably she also knows about it from her following the development of Foo, but the process exists to ensure that this is documented publicly.
|
|
|
|
Next, the job falls to Alice to complete 3 steps:
|
|
|
|
1. Determine how the bug was fixed in 2.0.1.
|
|
2. Isolate the _smallest possible_ patch set that fixes the bug, ideally without making any functional changes (feature-stable).
|
|
3. Apply that patch set to version 1.3.1 so that the bug is fixed _in that version specifically_ ("backport" the fix).
|
|
|
|
Depending on the software and the bug, this can be a trivial task, or it can be a very hard task; sometimes, the full fix can't be backported, and smaller workaround patches are needed to get a functional fix out, even if it's not complete; and sometimes, a fix isn't even possible (these are very very rare, and I'm honestly not even sure what happens then). Sometimes the upstream package makes it very easy to isolate patchsets, and sometimes they make it (often unintentionally) hard. But this is the life of a Debian Developer: keeping the software working.
|
|
|
|
So for the Foo CVE, Alice is able to isolate the patchset, and successfully apply it to 1.3.1. Now, she releases Foo version `1.3.1-1`. The small suffix of `-1` signals that this is a newer revision, but not a newer _version_, of the package, and it is released by the Security team along with a DSA advisory. The next time a Foo user does `apt update`, they'll see the new version of Foo ready to be installed, which will have both the security fix, while still remaining fundamentally version 1.3.1.
|
|
|
|
This idea of a feature-identical but security-patched package version can sometimes be confusing to folks not used to it, but it is the very basis of how Debian Stable keeps its users secure. And it's also why one cannot rely just on version number strings when determining how secuure or "insecure" a Debian system is. It allows us the best of both worlds in most cases: stable package versions with stable feature-sets, but security fixes for the bad bugs that can ruin systems (or livelihoods). It's a system that's worked for over 30 years now, and will hopefully continue to work for 30 more.
|
|
|
|
## The Best of Both Worlds (Part 2)
|
|
|
|
I hope this quick dive into the organization of Debian and how Security fixes are handled was interesting and informative. Happy Debian-ing!
|