How security is handled by package maintainers

Published on 2022-03-29. Modified on 2022-04-02.

A lot of myth and misunderstanding exist regarding this issue and it is easy to get confused because it varies from project to project. This post is not about base systems or base packages, rather it's about third party packages.

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

Regarding the major Linux distributions and BSD variants, such as e.g. Debian Linux, Arch Linux, Artix 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.

Most major Linux distributions and BSD variants has some kind of a security team, often with one or more members capable of programming. Whenever there is a security problem, upstream maintainers are often willing to help, but otherwise the security team tries to solve the problems internally.

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 version of a package. This problem is not relevant for Arch Linux or Artix Linux because both runs with bleeding edge software, they generally don't use backports unless upstream has some variant of a package that is considered important, like the long-term support (LTS) for the Linux kernel.

However, this can be a problem on a project like Debian and other projects that aim to provide long term support for third party packages. If upstream has created a patch that works with the older version of the 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 little help from upstream. In this case the package is typically just updated to the latest upstream version. However sometimes the package maintainer and the security team can work together in order to determine if they are able to fix the problem themselves. 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 software.

On OpenBSD, FreeBSD, Arch Linux, and Artix 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 to not 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 can possibly 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 hopelessly outdated packages of third party software.

Debian and - as a direct result thereof - Devuan too, suffers greatly from a lack of maintainers. Even important security updates can go unfixed for months! Alpine Linux suffers from the same problem.

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.

DateProject
2021-11-08Fixed by upstream. MariaDB updated to 10.6.5. Upstream backports the fix to 10.5, 10.4 and 10.3.
2021-11-08Arch Linux upgrades to 10.6.5.
2021-11-08Artix Linux upgrades to 10.6.5.
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-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-16OpenBSD upgrades to 10.6.5.
2022-02-16Debian security updates packages 10.3, 10.4 and 10.5.
2022-02-16Devuan security updates packages 10.3, 10.4 and 10.5.
2022-02-19Debian stable is upgraded to 10.6.5.
2022-02-19Devuan stable is upgraded to 10.6.5.
2022-03-18Alpine main upgrades to 10.6.7-r0.

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

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

At the time above, Artix was using Arch repositories, which is why they had the package updated at the same time as Arch. They have since moved to their own repositories and are generally about 1-2 days behind Arch in package updates. Devuan mirrors Debian and are cloning packages at about 30 minutes interval (with the exception of the packages they change or remove - mainly systemd related).

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.

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 noone 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 for example, when you install an orphaned package, the package manager will tell you about it and warn you that the package might be removed from FreeBSD unless a new maintainer is found. Arch and Artix 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 and time. 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 needs 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 a 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 all the work for you. Sometimes a package maintainer just abandons a package with no prior warning. Also, you're allowed to help. If a package is important to you perhaps you can provide a quick patch.

Last, but not least, a package maintainer might be the upstream author of the package, but very often it's just someone else, someone who has decided to dedicate a small amount of his free time in order to keep a package running on a specific Linux distribution or BSD variant. Always try to be kind and helpful to both open source developers and open source package and ports maintainers. They are all voluntarily helping to keep your system up and running! Some maintainers experience burnout due to hostility from users.