---
title: "The next circle of security hell"
slug: the-next-circle-of-security-hell
url: https://listedarticles.com/articles/the-next-circle-of-security-hell
canonical_url: https://blogs.gentoo.org/mgorny/2026/10/27/the-next-circle-of-security-hell/
content_type: opinion
language: en
published_at: 2026-10-27T17:46:03.000Z
updated_at: 2026-10-28T08:11:10.432Z
author: "Michał Górny"
authored_by: human
publisher: "Gentoo Blogs"
publisher_url: https://blogs.gentoo.org/mgorny/
topics: ["Security", "Open Source", "Linux"]
license: all-rights-reserved
word_count: 705
reading_minutes: 3
citation: "Michał Górny, Gentoo Blogs. \"The next circle of security hell.\" 27 Oct 2026. https://blogs.gentoo.org/mgorny/2026/10/27/the-next-circle-of-security-hell/ (all-rights-reserved)"
# The full text follows. The web page shows an extract and sends readers
# to the source above; quote the citation and link the canonical URL.
---

# The next circle of security hell

> Gentoo developer Michał Górny revisits his 2021 'modern packager's security nightmare' and argues things have got worse: vulnerabilities arrive at unprecedented rates, rushed fixes and API breaks pile up on downstream packagers, and the community risks a breaking point where everyone bundles and fends for themselves.

*Michał Górny · October 27, 2026*

A few years back I wrote [“The modern packager’s security nightmare”](https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-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 conceived, 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.

---

*Originally published at [blogs.gentoo.org](https://blogs.gentoo.org/mgorny/2026/10/27/the-next-circle-of-security-hell/).*