fidzu : gentoo

A few years back I wrote "The modern packager's security nightmare". Have things improved since? On the contrary, I feel like we're slipping down a well-oiled slope with no end in sight. Vulnerabilities are reported at unprecedented rates. A lot of people are doing everything they can to patch them up, which doesn't necessarily mean they're not making things even worse. Complex software involves complex trees of dependencies, and every branch on that tree needs tending to. When they stop being reliable, people further down the tree start taking more weight. And there's a limit of how much a single person can do, so what started as an effort to resolve an issue upstream may quickly become a weakness.

Is software less secure these days? It's tempting to say yes. I'd love to blame the corporate sector for egotistically dumping low quality software on us. I'd love to blame marketing-oriented people developing stuff with the sole goal of making a profit. I'd love to blame Rust for getting people obsessed about memory safety, and ignoring the kinds of vulnerabilities that aren't caught by the compiler. Finally, I'd really love to blame slop. But the truth is, I don't know. That's really beside the point.

The point is that nowadays everyone and their chatbot became security researchers. Projects are being flooded with vulnerability reports. Even though pretty much every bug bounty was discontinued because of slop, people aren't stopping. And even if we disregard truly invalid junk reports, there's a lot left, and you have to deal with them somehow. You have to figure out how important they are, and how to fix them (or more likely, whether the fixes submitted are truly valid and don't introduce regressions), or if you should reject them and why.

In the end, security is tricky. We're seeing lots of bugs like REDoS, or other kinds of "performance bugs". Are they really vulnerabilities? Well, it depends on the attack vector. And that in turn depends on how the software is used. Some scenarios are really contrived, and feel like "shell can execute dangerous commands if you type them in". But then, you also have really serious issues such as "timing attack can be used to guess user's secret". You need to know a lot to make that kind of judgment, and sometimes your judgment doesn't really match users' expectations.

In the end, what can project maintainers do? Even if they have the expertise and the energy to judge, if they can "know better", there's likely a CVE assigned already. It may have absurdly high score. All security scanners will complain unless you fix it, and users will come asking or complaining, or attacking, or forking. I mean, technology can't handle nuances. More than once I've been doing unnecessary security stabilizations over vulnerabilities that didn't affect Gentoo (for example, because we already unbundled the vulnerable dependencies), to avoid false positives from security scanners. I've been also doing meaningless version bumps (with no real changes or no changes that applied to Gentoo) so that our packages don't get reported as being "outdated". It's a hassle and it sucks, but it saves people from worrying.

I've said this before and I'll say it again: most projects aren't really prepared to handle security issues. And it's not just about triage. It's about having LTS or security branches, it's about making proper security releases with minimal changes. Unfortunately, it's quite common for security fixes to be combined with new features, deprecations, API changes. In extreme cases, people are caught with their metaphorical pants down, and suddenly need to make a security release in the middle of a major rewrite, or along with barely tested new code. And then, people downstream discover that they need to quickly deal with major API changes to upgrade past a vulnerable version. These things keep piling up.

What happens next? The community reaches a breaking point. People can't keep up. You discover you can't rely on others, so you work around them. You start bundling more stuff. Soon enough your workload goes beyond your ability. Software development becomes "every chatbot for itself". The nightmare becomes worse, and the wheel keeps turning.

27 Oct 2026 5:46pm GMT

As we all know, PHP 8.1 reached EOL on December 31, 2025, and the Gentoo PHP package maintainers, as usual, followed the upstream project's line.

PHP releases often include fixes for CVEs, and once a release series reaches EOL, no further releases are published to address those vulnerabilities.

Until recently, even though some published CVEs were reproducible on PHP 8.1, upgrading was not strictly essential. However, with CVE-2026-109618 and CVE-2026-109619, I believe upgrading has become mandatory.

Unfortunately, I still have a few installations running PHP 8.1 because the software that requires it cannot be upgraded.

I imagine many other people are in the same situation, so I decided to publish this article to provide a practical solution.

All it took was resurrecting the latest php-8.1.x ebuild from the Gentoo Git repository and making a few minor changes to turn it into a live ebuild (9999) that uses Remi Collet's repository.

Remi Collet is a PHP contributor who maintains repositories for EOL PHP branches, backporting security patches so that users can continue running older PHP versions without leaving them vulnerable to known security issues. He also packages PHP for RHEL-based distributions.

I'd like to take this opportunity to thank Remi for his great work.

For convenience, I've added the ebuild to my overlay, so anyone who wants to install a PHP 8.1 version containing backported security patches can do so with:

layman -a ago
emerge =php-8.1.9999

A few things worth mentioning

1. Build environment

As of the time of writing, the ebuild builds successfully with a stable toolchain: gcc-16.2.1 and glibc-2.43-r4. I've also verified that the build succeeds with gcc-14.2.1 and glibc-2.42-r7.

2. Tests

src_test() pass successfully, however there are few unexpected failing tests that I'm investigating. In my view, a failing test can be an indication that software running in production may not be working as expected, so I strongly recommend enabling the tests.

3. Init system

The ebuild has been tested with OpenRC.

4. USE flags

Not all USE flag combinations have been tested, so enabling options different from the ones I used may cause the build to fail.
If you encounter a compilation failure, please report it to Remi Collet, as it is likely related to the PHP source code or its security patches.
If, on the other hand, you encounter an issue with the ebuild itself, please report it to me so I can investigate and make the necessary changes.

5. PHP_VERSION and the upstream commit

After installing php-8.1.9999, running:

php -r 'echo PHP_VERSION;'

will still output 8.1.34, because the version string is hardcoded here and here.

It would be nice if it printed something like 8.1.SHA or 8.1-SHA instead. Making this change in the ebuild would be trivial, but I don't want to do it without a proper audit of where this string is used and whether it is involved in version comparisons or other operations.

If having the commit SHA in the version string is important to you, feel free to bring it up with Remi, who can decide whether to make the necessary changes to the repository.

Therefore, if you want to determine which commit your build was compiled from, you'll have to use qlop -m to find the build date and then check the state of the php-src-security/PHP-8.1-security-backports repository at that time.

6. Older PHP versions

I don't have any software that requires a PHP version older than 8.1, but if you do, you can apply the same approach in your own local repository by changing EGIT_BRANCH to point to whichever branch you need.

Keep in mind that different branches may require different build instructions, which you'll need to adapt accordingly.

7. Backporting Gentoo ebuild changes

Although the ebuild worked out of the box and required no major modifications, since I decided to publish it and make it available to others, I also took the opportunity to backport some of the changes that the Gentoo PHP maintainers had made to ebuilds for versions newer than 8.1.

8. Keeping up with security updates

I recommend setting up a watch on the repository. Whenever a new commit introducing a security patch is published, you'll need to rebuild and reinstall the package by running:

emerge =php-8.1.9999

This ensures that your installation picks up the latest available security patches.

That's all.

26 Oct 2026 1:23pm GMT

On 2026-10-20, it has been disclosed that the private keys of eight eMudhra intermediate CA certificates have been compromised. These keys can be used to issue forged CA certificates that would be considered fully trusted by the affected software, and therefore could be used to perform man-in-the-middle attacks.

Importantly, the vulnerability can also affect software self-update processes that use TLS verification as the only security measure, with an attempt to upgrade the system leading to it being compromised. The standard Gentoo configuration mitigates this risk, as both the ebuild repository updates and binary package downloads are secured using OpenPGP keys. A malicious third party may be able to intercept update requests, but Portage will reject any tampered packages or metadata.

The baseline remediation is to upgrade to >=app-misc/ca-certificates-20260816.3.125. However, some packages are using bundled certificate stores and require separate remediation. In some cases the bundled certificates are updated automatically, in others, the relevant packages will need to be upgraded. We are actively tracking the affected packages in bug 984601, and releasing fixed versions to Gentoo stable ASAP. We are also looking into forcing the use of the system certificate store in more packages, per our unbundling policy.

Please note that packages installed outside Gentoo package manager are also affected. For example, Python virtual environments featuring the prior versions of certifi, pip or uv packages are vulnerable. Please refer to the Python upstream announcement for more details and the recommended remediation.

24 Oct 2026 5:00am GMT