Published on 2022-03-30. Modified on 2023-10-24.
Debian used to be a very famous Linux distribution in the communications industry and I have been running it in production since about 1998 up until the time when the systemd conflict arose. Since then the priorities of the Debian project changed and Debian was no longer what Debian used to be.
Because of the problems with systemd, the Debian community was unfortunately split and a minority of former members and contributors decided to fork Debian into Devuan. Debian was, and still is, a very big project and the founders of Devuan struggled for years because forking Debian was no easy task. Several leading members simply quit Debian without joining Devuan, and many people felt betrayed by how the systemd conflict was handled.
One of the primary reasons to deploy Debian on production servers in the past was because of the way Debian maintained both the kernel, the userland, and third party packages in the stable release. On the project website Debian still "boasts" of the same procedure.
Debian is secure
Debian offers security support for its stable releases. Many other distributions and security researchers rely on Debian's security tracker.Long Term Support
Debian's free of charge Long Term Support (LTS) version extends the lifetime of all Debian stable releases to at least 5 years. Additionally, the commercial Extended LTS initiative supports a limited set of packages for more than 5 years.
On the Debian Security Information it is further stated that:
Debian takes security very seriously. We handle all security problems brought to our attention and ensure that they are corrected within a reasonable time frame.
Many advisories are coordinated with other free software vendors and are published the same day a vulnerability is made public and we also have a Security Audit team that reviews the archive looking for new or unfixed security bugs.
Furthermore, on the Debian Security Audit Project website it is stated that: (The web page for the Debian Security Audit Project has been removed since I wrote this article).
The Debian Security Audit Project is a project which is focused upon auditing Debian packages for security issues.In the short time it has been running it has been responsible for several Debian Security Advisories proving that this auditing process really works to improve Debian security. It is hoped more advisories will result from future work.
By taking a proactive stance in auditing code we can help to ensure that Debian continues its long history of taking security seriously.
The aim of the project is to audit as many of the packages within the Debian stable release as possible for potential flaws. Important packages which are contained in the unstable distribution may also be examined for flaws, decreasing the likelihood of insecure packages entering the stable release in the first place.
This is a very tall order! The amount of packages in Debian stable are more than 100.000 and they contain millions upon millions of lines of code in many different programming languages.
Today Debian is still one of the biggest Linux distributions in the world but the project has been experiencing a sort of decline in the quality of leadership (this began with the problems regarding systemd). The issues that the project has chosen to focus their energies and efforts on has little to do with Debian. As a result there is also a decline in the amount of people willing to participate in the project.
This is made worse by the fact that the current leader (Jonathan Carter) is more worried about how "shiny" Debian is and whether it has a "black lives matter" sticker somewhere on the project website than he is with technical issues and the fact that tons of Debian packages are abandoned and many important packages don't get security updates in a timely manner.
At the virtual DebConf20, Debian project leader Jonathan Carter gave his talk.
"Debian isn't pretty enough, needs better look and feel."
People who think that Debian lacks "the shiny" are not the people Debian should be attracting!
In all my years in IT I have never, NOT ONCE, met anyone who used Debian in production or on their personal machines who where unhappy about the look and feel of Debian! Rather, the opposite!
"Black lives matter" is a political issue that has absolutely nothing to do with Debian. If it does, then what about all the other political issues that are currently rampant in the world?
Debian should continue to do what they used to do best, provide a stable and relative secure Linux distribution and stay out of politics. Debian is a Linux distribution, not a discussion panel for political issues.
You can get the full slides in PDF here: DebConf 20 slides.
During this weekend I have been going through a number of packages and found that the sad state of web browser support within Debian also extends to many other packages.
More than that, and I am sorry, but the Debian project seems delusional about its long term support (LTS).
At the time when Debian 11 was about to be released, PHP 8.0 was already 10 months old yet Debian 11 was shipped with PHP 7.4. That makes PHP 7.4 the standard in Debian stable for at least 3 years after its release. But PHP 7.4 only got upstream support until 28 Nov 2021 and security support is permanently ended at 28 Nov 2022 (which is seven month from when this post was published). This means that unless Debian has some really good C developers who can work directly on the PHP source code, no one can provide security fixes for PHP 7.4. Not only that, no one outside of Debian will be monitoring problems with PHP 7.4 because everyone else have long since upgraded to PHP 8.
Still, Debian users are left with the impression that because Debian promises long term support, there are no problems running these outdated packages because they will continue to get security patches backported. But this is not always the case. When upstream abandons a package version and no longer provides security updates or bug fixes for the package, then likewise the Debian package maintainer is stuck with the old version unless he/her starts doing some coding.
If e.g. upstream has abandoned version 1.2 of package foo and only code on version 2.0, then no one from upstream will backport security fixes from 2.0 to 1.2. Hence, someone from Debian has to do this himself/herself.
The Debian project is unique in this regard as it actually do have developers who does this kind of work, but the amount of developers capable are limited. As such, normally Long term support depends on upstream!
TIP: If you want to understand how well upstream packages are tracked in your OS, take a look at the packages that are important to you and compare the release dates from upstream with the release dates of the package on your OS. Also notice if any patches have been backported or applied.
This is a very basic list of what you need to do if security is important to you:
- Keep a list of all the important packages you install.
- Monitor bug reports and security reports filed upstream.
- Determine if and how a problem affects you. A buffer overflow problem in your favorite text editor is not a problem if you are the only user with access to the machine. An exploitable bug in something like Apache, if you run that as an Internet facing web server, is a serious issue.
- Keep a careful eye on whether Debian has noticed the bug report and whether they have reacted to it. You can help by letting the package maintainer know about the issue, but this is no guaranty that the package will be updated in a timely manner. If the package maintainer is ill, out of town, or simply doesn't have the time, you're on your own.
- Plan ahead on how to deal with such issues.
- Ideally, use an OS that makes it easy to build and compile your own packages directly from upstream. This is relatively easy on all the BSDs because of the ports system. It is also relatively easy on Linux distributions with similar systems to the ports system, such as Gentoo, Arch Linux, Void Linux, and others. The ports system is one the greatest assets for users who want flexibility and control over their software. On FreeBSD you can even use Poudriere on a build machine.