How security is handled by package maintainers

Published on 2022-03-29. Modified on 2023-10-24.

A lot of myth and misunderstanding exist regarding how security is handled by package maintainers on the different Linux distributions and BSD variants. Let's take a look at the subject.

I will not consider small dependent Linux distributions or one-man projects, because the issue becomes mostly irrelevant in very small projects. Often they simply cannot keep up with upstream security updates if their project has even a tiny amount of third party packages.

Regarding the major Linux distributions and BSD variants, such as e.g. Debian, Arch Linux, OpenBSD, and FreeBSD, generally speaking, a package maintainer or ports maintainer is not a programmer and as such he or she cannot do any coding. The package maintainer is only responsible for making sure that the package is installable and working and that it is updated according to the project guidelines. Normally there is no coding involved, however the maintainer could also be the author of the application and as such, he or she would then be able to fix issues.

Security issues can be discovered by anyone. Sometimes an issue is discovered by the upstream developers themselves, sometimes it is discovered by a single individual with no relation to the upstream project. Sometimes a security issue is reported to the upstream bug tracker, email, or whatever other communication means they provide. At other times it is reported locally to a given Linux distribution or BSD variant, and it is up to the people responsible for security to make sure that the report gets filed upstream too.

If a security issue has been discovered in a package, a fix might not be possible to backport to an older supported version of a package. This can be a problem on e.g. a Linux distribution that doesn't run a rolling release, but instead runs a "point release".

As an example, Debian aims to provide long term support for third party packages. If upstream has created a patch that works with the older version of a package, the solution is simple, the package is patched and updated. If upstream has removed a functionality of the software that also removes the problem, and upstream doesn't care about the older version of the package, which is often reasonable, then there is sometimes nothing you can do. Sometimes the package maintainer and the security team can work together in order to determine if they are able to fix the problem themselves, but this requires that at least one person knows the programming language of the package and is able to provide a sound fix. If that is not possible because large amounts of code needs to be modified or rewritten, or they simply cannot do it, it becomes necessary to move to a new upstream version of the package. If they keep running with the old package, users of the package are vulnerable (if the security issue can be exploited).

On e.g. OpenBSD, FreeBSD and Arch Linux, the maintainers are expected to make sure that third party software is free of known vulnerabilities. This means that version upgrades are more common. All these projects generally do a good job of tracking upstream updates. On Debian the package maintainers are required to try not to compromise on the stability of a package in the stable release. The most important guideline for Debian, when making a new package that fixes a security problem, is to make as few changes as possible. Debian users and developers are relying on the exact behavior of a release once it is made, so any change that is made should never be able to break someone's system. This is especially true in case of libraries. Hence, it is a requirement that a maintainer makes sure he or she never changes the Application Program Interface (API) or Application Binary Interface (ABI), no matter how small the change is. On Debian this means that moving to a new upstream version is not a good solution, instead the relevant changes should be backported if possible.

Even when Debian has a new major release, the prior version continues to get security updates and important bug fixes for packages, as long as the package is not orphaned, and as long as upstream supplies these. This is true for FreeBSD as well. On OpenBSD only the current branch, which is the development branch (yet, extremely stable), and the stable branch (latest release) gets important security updates to third party packages.

Many Linux distributions have outdated packages of third party software. This means that you cannot simply install your favorite Linux distribution on your machines and then blindly trust that the package maintainers keep your third party packages updated. You need to personally track all the important packages you install and in some cases even use your own if you want to ensure your machines are updated in a timely manner.

As a simple example, CVE-2021-46667 is an integer overflow bug in MariaDB relevant for all the Linux distributions and BSD variants I have mentioned so far. The bug was reported on 2021-08-13.

This is a time table for when each project updated MariaDB. Notice also that the upstream developers themselves where very slow at fixing this issue.

2022-03-18Alpine Linux main upgrades to 10.6.7-r0.
2022-02-19Devuan Linux stable is upgraded to 10.6.5.
2022-02-19Debian Linux stable is upgraded to 10.6.5.
2022-02-16Devuan Linux security updates packages 10.3, 10.4 and 10.5.
2022-02-16Debian Linux security updates packages 10.3, 10.4 and 10.5.
2021-11-16OpenBSD upgrades to 10.6.5.
2021-11-13Gentoo Linux security updates ports 10.5, 10.4 and 10.3 They didn't have 10.6 in ports before 2021-11-23.
2021-11-10FreeBSD security updates ports 10.5, 10.4 and 10.3. They didn't have 10.6 in ports before 2022-02-20.
2021-11-08Artix Linux upgrades to 10.6.5.
2021-11-08Arch Linux upgrades to 10.6.5.
2021-11-08Fixed by upstream. MariaDB updated to 10.6.5. Upstream backports the fix to 10.5, 10.4 and 10.3.

This shows that Debian and Devuan was 3 month behind with the update, Alpine even longer.

Many other Linux distributions are much worse when it comes to timely updates.

A big problem is with Debians third party package "stability" policy. The idea is great in theory, but at the time when Debian 11 was about to be released, PHP 8.0 was already 10 months old, yet Debian's 11 release was upgraded from PHP 7.3 to PHP 7.4, not to PHP 8. That made PHP 7.4 the standard in Debian Stable for at least 3 years after its release. However, PHP 7.4 gets upstream support for only a year after that. This means that any bugs found in PHP 7.4 goes unfixed unless the Debian security team and/or package maintainers somehow manages to fix such problems themselves. Of course, you can always hope that a newer version gets ported to Debians "backport" repository, but that rarely happens. You can also decide to run a newer package from the testing or unstable repositories, but these repositories are meant for testing, and as such, security is not prioritized for these repositories on Debian.

Now, it is very important to understand that package maintainers are voluntary people. All major Linux distributions and BSD variants lack package maintainers. Debian has about 1/3 of the workforce it requires to keep everything up to date. Furthermore, not all package maintainers can provide upgrades in a timely manner due to work, family, health, and other issues.

Prior to OpenBSD 6.5 only the development branch got timely updates for third party packages due to a lack of resources.

Sometimes a package gets "orphaned" by the maintainer, for whatever reason, and there is no one available to keep the package updated. The projects handle orphaned packages differently. On some projects a package can be marked as "orphaned" or "outdated", so that all users know. On FreeBSD e.g., when you install an orphaned package, the package manager software (pkg) will tell you about it and warn you that the package might be removed from FreeBSD unless a new maintainer is found.

Arch Linux marks a package as outdated and if the maintainer doesn't respond, and a new maintainer isn't found, the package is removed.

OpenBSD quickly removes packages that has been without a maintainer if it is found that an important bug fix or a security update is lacking.

Sometimes it's not required to remove a package just because it doesn't have an active maintainer. Some software projects are more or less done, they don't require any updates if no new bugs or security issues are found.

If a project has a security team they sometimes steps in and uploads a high-urgency security-only fix when a maintainer is noticed to be inactive, but the security team has limited resources. The base system is always given a higher priority than any third party package.

Besides from whatever tool your Linux distribution or BSD variant provides in order for you to keep track of outdated packages, the Repology project monitors a large number of package repositories (comparing package versions across projects and gathering other information). Repology shows you in which repositories a given project is packaged, which version is the latest and which need updating, who maintains the package, and other related information.

The important point of this article is this: If you run any kind of important open source operating system, whether as a desktop, a laptop, a server, or an embedded device, it is up to you to keep an open eye and keep watch on both the operating system and on the third party packages you have installed. You can never simply trust that the package maintainer does the work for you. Sometimes a package maintainer just abandons a package with no prior warning to anyone.