CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq
lists.thekelleys.org.uk318 points by chizhik-pyzhik 16 hours ago
318 points by chizhik-pyzhik 16 hours ago
I think this is the breaking point where replacing our code written in C for code written in memory safe languages is becoming urgent.
The vast majority of vulnerabilities found recently are directly related to being written in memory unsafe languages, it's very difficult to justify that a DNS/DHCP server can't be written in rust or go and without using unsafe (well, maybe a few unsafe calls are still needed, but these will be a very small amount)...
The problem is the lack of talent that is willing to work on this, not the language.
AI Security researchers at least do something. If it was so easy to rewrite everything in rust, I don't know why the response to this incidents isn't a rock solid replacement in rust, the next day.
I tell you why that is. Working on these things doesn't give you stars on github.
https://news.ycombinator.com/item?id=47943499 - 44 CVEs trying to replace coreutils with a greenfield rust rewrite. There's no free lunch.
How many CVEs in coreutils over the years? The project has the advantage of being old enough for them to be fixed. Call me when the rust rewrite has been there that long and still has more CVEs than the GNU counterpart.
I disagree -- we're clearly getting better safeguards by way of AI agents to spot potential vulnerabilities!
The question is whether the current situation is a short burst of action, and once those most critical bugs get fixed the hype around AI vulnerability scanning will die down, or whether the current crop of system/infra software written in vulnerable languages like C are beyond redemption and they will provide an endless source of critical bugs for AI to find until we fix them by rewriting them in Rust/Go/whatever.
An eternal summer of CVEs is upon us
Seems like those “rewrite in Rust” folks had a point after all (the viability of it for any number of projects being another thing entirely).
A better use of LLMs: To help translate the vast majority of C/C++ developers' output into memory-safe languages. :p
You're likely joking, but in case someone else misunderstands; this is not going to work. Rust with unsafe{} is the only thing you can translate directly to, even with LLMs. Rust with extensive unsafe{} is not something anyone wants to debug or maintain, and is near impossible to improve quickly.
It's a good thing this software isn't used in millions of devices which almost never receive updates.
It's more of a good thing that, in most cases, it's on devices that won't send it any packets unless a client first authenticates to a Wi-Fi station or physically plugs into an Ethernet port.
That is pretty bad!
"a remote attacker capable of asking DNS queries or answering DNS queries can cause a large OOB write in the heap."
Malformed DNS response causes "infinite loop and dnsmasq stops responding to all queries."
Malicious DHCP request can cause buffer overlow.
To quote a famous (in certain circles) bowl of petunias, "oh no, not again!"
For a number of reasons, I feel that the only way we got here was via some kind of infinite improbability drive.
(mostly unrelated to topic at hand though)
> For a number of reasons, I feel that the only way we got here was via some kind of infinite improbability drive.
Oh very much so! In my mind, it seems that someone must have figured out what the universe was for, and now it's been replaced with something even more bizarre and inexplicable.
What is the nature of these findings? There’s a big difference between AI finding a buffer overflow vs. identifying a fundamental protocol flaw. Could AI realistically discover something like the Kaminsky attack? or even something which is an amplification exploit like the NXNSAttack?
Shameless plug time:
My own MaraDNS has been extensively audited now that we’re in the age of AI-assisted security audits.
Not one single serious security bug has been found since 2023. [1]
The only bugs auditers have been finding are things like “Deadwood, when fully recursive, will take longer than usual to release resources when getting this unusual packet” [2] or “This side utility included with MaraDNS, which hasn’t been able to be compiled since 2022, has a buffer overflow, but only if one’s $HOME is over 50 characters in length” [3]
I’m actually really pleased just how secure MaraDNS is now that it’s getting real in depth security audits.
[1] https://samboy.github.io/MaraDNS/webpage/security.html
Well, as you bundle Lua 5.1 (as Lunacy), instead of making a library and loading it, and you bundled the 2012 version, you're probably affected by CVE-2014-5461 and others. Lua hasn't been security fix free.
Thank you for your concern.
I fixed CVE-2014-5461 for Lunacy back in 2021:
https://github.com/samboy/lunacy/commit/4de84e044c1219b06744...
This is discussed here:
https://samboy.github.io/MaraDNS/webpage/security.html#CVE-2...
In addition, I have done other security hardening with Lunacy compared to Lua 5.1:
https://samboy.github.io/MaraDNS/webpage/lunacy/
Now, I should probably explain why I’m using Lua 5.1 instead of the latest “official” version of Lua. Lua has an interesting history; in particular Lua 5.1 is the most popular version and the version which is most commonly used or forked against. Adobe Illustrator uses Lua 5.1, and Roblox uses a fork of Lua 5.1 called “luau”. LuaJIT is based on Lua 5.1, and other independent implementations of Lua (Moonsharp, etc.) are based on versions mostly compatible with Lua 5.1.
Lua 5.1 has a remarkably good security history, and of course I take responsibility for any security bugs in the Lua 5.1 codebase since I use the code with the relatively new coLunacyDNS server (Lua 5.1 isn’t used with the MaraDNS or Deadwood servers).
Lua 5.1 is used to convert documentation, but those scripts are run offline and the converted documents are part of the MaraDNS Git tree.
Yeah, I've had patches submitted to Moonscript, Fengari, and luau. Don't need to sell on why 5.1 is useful. Each version is a new lang, not just a few fixes or niceties.
I'm not convinced that vendoring, instead of embedding, is the right way.
The patch landing in 2021, instead of 2014, being one of those concerns.
(And you might want to recheck your assumption of how big 'int' will be, for rg32. C defines it in terms of minimum size, not direct size. int16_t isn't necessarily an alias.)
>>>The patch landing in 2021, instead of 2014, being one of those concerns.<<<
What makes you think I was using Lua in 2014? Seriously, do you even know how to use “git log”?
I added Lua to MaraDNS in 2020:
https://github.com/samboy/MaraDNS/commit/2e154c163a465ee7ead...
I patched it on my own in 2021:
https://github.com/samboy/MaraDNS/commit/efddb3a92b9cee30f11...
>>>you might want to recheck your assumption of how big 'int' will be
uint32_t is always 32-bit:
https://en.cppreference.com/c/types/integer
And, yes, this can be easily checked with a tiny C program:
#include <stdint.h>
#include <stdio.h>
int main() {
uint32_t foo = 0xfffffffd;
uint64_t bar = 0xfffffffd;
uint32_t a = 0;
for(a=0;a<20;a++) { printf("%16llx:%16llx\n",foo++,bar++); }
return 0;
}
Are you going to make any other negative false implications about MaraDNS? Because you’re making a lot of very negative accusations without bothering to check first.
Edit: Here’s a version of the above C program which works in tcc 0.9.25:
#include <stdint.h>
#include <stdio.h>
void shownum(uint64_t in) {
int32_t a;
for(a=60;a>=0;a-=4) {
int n = (in >> a) & 0xf;
if(n < 10) {printf("%c",'0'+n);}
else {printf("%c",'a'+(n-10)); }
}
return;
}
int main() {
uint32_t foo = 0xfffffffd;
uint64_t bar = 0xfffffffd;
uint32_t a = 0;
for(a=0;a<20;a++) {
shownum(foo++);
printf(":");
shownum(bar++);
puts(""); }
return 0;
}> What makes you think I was using Lua in 2014? Seriously, do you even know how to use “git log”?
... It was fixed, upstream, in 2014. Thanks for not checking the number at the start of the CVE, before launching straight into attack mode.
https://www.lua.org/bugs.html#5.2.2-1
Which is the point. In 2020, when you added Lua, you added a vulnerability that had officially been fixed for six years. Because you vendored, and did not depend on any system package.
> uint32_t is always 32-bit:
Yah. Which is why I said 'int'.
As in the assumptions you made here:
Apologies for being confrontational; accusations of there being security holes are serious accusations in my book, and need to be backed up with solid facts. Yes, that’s how seriously I take security with the software I make available on the Internet.
That number is a 32-bit number in the C code, but it’s converted in to a 16-bit number. I used “int” to have it interface with other Lua code, but safely assume “int” can fit 16 bits, and yes I do convert the number to a 16-bit one before passing it off to other Lua code:
https://github.com/samboy/LUAlibs/blob/master/rg32.c#L77
Here, I assume lua_number can pass 32 bits:
https://github.com/samboy/LUAlibs/blob/master/rg32.c#L45
https://github.com/samboy/MaraDNS/blob/master/coLunacyDNS/lu...
https://github.com/samboy/lunacy/blob/master/src/lmathlib.c#...
But it works without issue:
rg32.randomseed("shakna3")
print(string.format("%x",rg32.rand32()))
Likewise:
rg32.randomseed("shakna3")
print(string.format("%x %x",rg32.rand16(),rg32.rand16()))
Vendoring Lua 5.1 was forced; since I wanted to use Lua 5.1 (for reasons described above, e.g. LuaJIT compatibility), I had to use code which hasn’t been updated upstream since 2012.
Unless the service accepts Lua code from the internet (and that would be a completely insane thing), the CVE-2014-5461 will not apply. And while I have not reviewed every Lua CVE, I bet most (all?) of then require a specifically crafted code, or at least highly-complex user input (such as arbitrary json)
It's important to look at the actual vulnerability at the context, and not just list any CVE which matches by version.
I should explain how MaraDNS uses Lua 5.1 (actually, Lunacy, my own fork with security bugs fixed as well as security hardening—including, yes, a patch against CVE-2014-5461), so you can get an idea of its attack surface.
MaraDNS has three components:
• MaraDNS, the authoritative server, which goes back all the way to 2001
• Deadwood, the recursive server, which was started back in 2007
• coLunacyDNS, which allows a DNS server to use Lua scripting; this didn’t exist until the COVID pandemic
Neither MaraDNS nor Deadwood use Lunacy (except as a scripting engine for converting documents); only coLunacyDNS uses Lunacy. coLunacyDNS uses a sandboxed and security hardened version of Lunacy (and, yes, I would accept bugs where someone could escape that sandbox), and the Lua scripts which coLunacyDNS uses can only be controlled by a local user and there is no capability to run Lua scripts remotely.
> coLunacyDNS, which allows a DNS server to use Lua scripting; this didn’t exist until the COVID pandemic
Why would a DNS server use Lua scripting? Is this for dynamically responding to requests rather than doing a pure lookup?
It’s useful for things like 10.1.2.3.ip4.internal style queries, or having a DNS server that always returns a given IP for any query given to it.
More discussion is on the coLunacyDNS overview page:
Its important to maintain your dependencies, by say embedding Lua, rather than rebranding it and then claiming you have no security flaws.
If I can find a CVE that _may_ affect the stack in five minutes, what _actual_ problems lurk there?
You vendor Lua - thus, it _is_ your responsibility to review every Lua CVE. You've set yourself up as the maintainer by vendoring.
You weren’t replying to me. The parent poster made a good point—a vulnerability in Lua doesn’t mean software running Lua can necessarily be exploited—but, more to the point, I do update Lunacy and make sure it’s secure, just as I still take responsibility for verified important security holes in MaraDNS.
See this, for example:
https://samboy.github.io/MaraDNS/webpage/security.html#CVE-2...
> It's important to look at the actual vulnerability at the context, and not just list any CVE which matches by version.
Unfortunately, that's not enough. Even if the vulnerable parts of the code are not being built, heck even if they have been completely erased from the source code, the auditors will still insist that you're vulnerable and must immediately upgrade, or else they will give your software a failing grade.
That seems wildly naive in the post-XSS era. We've been here before, and that kind of analysis turns out to be wrong almost every time.
"Well, sure, this component is insecure but an attacker can't reach it" is like a 50%+ positive signal for an unexpected privilege elevation bug.
MaraDNS is much less popular than dnsmasq though.
I have several libraries that I've written. Not one single serious security bug in them has been found since 1991. Granted, nobody uses my libraries...
Not to diminish your team's achievement! :D But it's important to contextualize claims like this with information about what your userbase looks like
A lot of security and other audits have been performed against it though; MaraDNS, after all, is notable enough to have a Wikipedia page and hundreds of GitHUB stars.
For example, when the Ghost Domain Name DNS vulnerability was discussed, MaraDNS was audited and named (MaraDNS was immune to the security bug, for the record)
https://web.archive.org/web/20120304054959/https://www.isc.o...
I don't think that's relevant. You can still find security issues in software nobody uses.
The question is a matter of impact because of how used the software is.
Way fewer people are going to look at obscure things, so a lower percentage of issues will likely have been found. There is less fame and fotune in spending security research time on obscure software. Most small libraries won't be covered by any bug bounty programs either for example.
You don't need other people anymore to find security issues, you can do it yourself with AI.
Even accepting the premise, is it not immediately obvious to you that folks will be spending more money and effort aiming AI at higher-impact targets? This isn’t all-or-nothing.
I remember being delighted finding maradns as an alternative to the “do everything” of dnsmasq way back when I set up a dns server, and more importantly, I haven't had to think about it since then.
> Shameless plug time: My own MaraDNS has been extensively audited now that we’re in the age of AI-assisted security audits.
Out of curiosty: what is the point you’re trying to make? That there are alternatives to dnsmasq? That somehow your software is “better”?
This plug provides zero value to the dnsmasq discussion.
As others have pointed out: the more used a software is, the more scrutiny it gets and more bugs or edge cases are found.
good job. but it is amazing we are still writing core networking tools in vulnerable language such as c in 2026.
Agreed, it made a lot more sense to write MaraDNS in C in 2001 though.
The main advantage of writing in C over Rust here in 2026 is that C has two different Lua interpreters, and there isn’t a port of Lua to Rust yet; [1] yes, there are ways to use the C version of Lua in Rust, but that’s different.
If I were to write a new server today, I could very well write it in Go, then use GopherLua for the Lua engine:
https://github.com/yuin/gopher-lua
Although, even here, the advantage of C is that I could increase performance by using LuaJIT:
https://luajit.org/luajit.html
[1] If I were to use Rust, I would consider using Rune as an embedded language as per https://rune-rs.github.io/
Flagged because this discussion about dnsmasq and another dns resolver implementation that has relatively no rollout worldwide by comparison is pointless.
That's a bit shameless, indeed.
dnsmasq has served me well for like an eternity in multiple setups for different use cases. As all software it has bugs. And once located those get fixed. Its author is also easy to communicate with.
Why should I switch over to something way less proven? I'm quite sure your software also has bugs, many still not located. Maybe because it's less popular/ less well known nobody cares to hunt for those bugs? Which means even if the numbers of found bugs is less in your software at the moment, and it may look more audited for this reason, it may actually be way less secure.
"All software has bugs" is the most meaningless statement ever. It is just used for bonding with fellow bug writers who sit at a virtual campfire and muse about inevitabilities.
Demonstrably some software has fewer bugs, and its authors are often hated, especially if they are a lone author like Bernstein. Because it must not happen!
Projects with useless churn and many bug reports are more popular because only activity matters, not quality.
If DJB is "hated", it isn't because he's a lone author (Linus Torvalds was once a lone author and I don't think he was hated). It's because he can be an asshole. To quote George Bernard Shaw, “The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”
DJB is a lot of things, and I have great respect for him, even though I feel he didn’t responsibly maintain Qmail/DJBdns/Publicfile. He made MaraDNS more secure because I carefully read his documentation—I got the idea to have a random source port to give MaraDNS more security from him, which means MaraDNS was unscathed when DNS spoofing was independently discovered in 2007.
The point DJB made was this: It was possible for a skilled C programmer to make a server with few security holes. Even though that’s not as relevant now, with Rust having most of the speed of C and security built in, it did make the Internet a safer place for many years. I remember using Qmail and DJBdns to make the servers at the small company I worked for at the time more secure.
“Fellow bug writers” is everyone. People who write fewer bugs exist, and a lone few who write many fewer.
I haven’t noticed antipathy, but I have noticed skepticism. I assume people with outlier records in any field get some extra inspection.
If it becomes jealousy-fueled not-picking, those people are insecure jerks. But unusual track records are worth understanding.
> "All software has bugs" is the most meaningless statement ever.
It's not! It's the foundation of all dev AI products marketing.
"All software has bugs" so "be wary of the one trying to say they haven't had any in 3 years" not so "I guess all are equal". For extremely low security bug rates either the scope is extremely narrow, the claim is dubious, or the project is a massive effort which the community talks about directly in posts rather than plugs (e.g. curl).
DJB, with Qmail and DjbDNS (as well as Publicfile, which didn’t catch on in an era of CGI scripts), showed that one could have (mostly) security bug free software without the scope being “extremely narrow”, and without the claim being “dubious”.
It’s not normal for software to be so poorly written, one doubts the claim that a security bug hasn’t been found in over three years. If one thinks the claim of no security bugs of consequence in three years is dubious, feel free to do a security audit of MaraDNS (or DjbDNS, which I also will take responsibility for even though my software is, if you will, a “competitor” to DjbDNS), and report any bugs you find.
Speaking of DJB, DjbDNS has had a few security bugs over the years (but not that many), but I’m maintaining a fork of DjbDNS with all of the security bugs I know about fixed:
https://github.com/samboy/ndjbdns
I am saying all this as someone who has had significant enough issues with DJB’s software, I ended up writing my own DNS server so I didn’t have to use his server (I might not had done so if DjbDNS was public domain in 2001, but oh well).
(As a matter of etiquette, it’s a little rude to claim someone is saying something “dubious”, especially when the claim is backed up with solid evidence [multiple audits didn’t find anything of significance in the last year, as I documented above], unless you have solid evidence the claim is dubious, e.g. a significant security hole more recent than three years old)
People here don't know that MaraDNS was already popular on extremely critical security mailing lists that basically hated anything but qmail and postfix. If you introduce more bugs and blog about them, it will probably gain in popularity. :)
> It’s not normal for software to be so poorly written, one doubts the claim that a security bug hasn’t been found in over three years.
Can you back that claim up with at least some sort of theory? Because it doesn't match my perception of the real world, nor does it match my mental model of how CVEs happen.
Yes, I can.
https://samboy.github.io/MaraDNS/webpage/DNS.security.compar...
Also, my sister post: https://news.ycombinator.com/item?id=48112042
Is that not begging the question? You have asserted X and now you point to a particular track record to back the claim of X up but the track record only serves as valid evidence of X if we already accept your assertion that X is the case.
I never used Qmail, so I won't comment on it, but I will say I absolutely consider djbdns narrow in scope as well (before accounting the Unix approach, utilized perhaps even more than in MaraDNS, to break that already narrowed scope down into even more focused binaries).
I had believed (and continue to hold) DNS software containing, e.g., an authoritative DNS server which lacks native TCP or DNSSEC support falls squarely into the "narrowly scoped" bucket and would appreciate if you'd not try to decide my opinion for me on any given project in the future.
The point of djbdns and qmail was this: It allowed administrators to run a local DNS server securely without needing to constantly patch the code. They were limited in scope, but were perfect for admins who valued security over features.
In an era when DNS was otherwise a monoculture, djbdns was a welcome breath of fresh air.
> Demonstrably some software has fewer bugs
You literally write fewer instead of none, therefore agreeing with the sentence you claimed to say is meaningless.
> Why should I switch over to something way less proven?
Must they prove their software to you? They're offering an alternative, not bargaining for a deal.
When you offer up an alternative as technically superior in some manner then yes, it is on you to demonstrate such a claim in a convincing manner. "No bugs in 3 years in this software with a much smaller audience and also look AI audits!" comes across as off topic shameless self promotion. At least if an insightful technical discussion ensued the subthread might prove worthwhile but so far it's just the usual tired shit flinging.
I have far more evidence of a very good security record with MaraDNS than “No bugs in 3 years in this software with a much smaller audience and also look AI audits!”
• The software has been around for 25 years
• The software is popular enough to have been subjected to dozens of security code audits, including two audits in the post-AI era
• In those 25 years, only two remote “packet of death” bugs have been found
• Also, in those same 25 years, only one single bug report of remotely exploitable memory leaks has been found
This isn’t something which, as implied here, has a lot of security bugs only because no one has used or audited the software. This is a long term, mature code base which has only had a few serious security bugs in that timeframe.
Here is my evidence:
https://samboy.github.io/MaraDNS/webpage/security.html
If this evidence isn’t “convincing” to you, I don’t know what evidence would be “convincing”.
For what it's worth I didn't know about maradns prior to this. Maybe it actually sees fairly wide use? Whether or not I accept your evidence would hinge on that. Regardless I think my point stands - if you don't lead with a convincing line of reasoning all that's left is an empty assertion. Unless I happen to recognize you as an authority in the field that's not going to do anything for me since by default you're some stranger on the internet that might be a dog for all I know.
To illustrate the issue with an extreme example, consider that a disused repository on github full of security holes is highly unlikely to have any CVEs regardless of age. The software has to present a worthwhile target (ie have a substantial long term userbase) before anyone will bother to look for exploits. (I guess that might change in the near future thanks to AI but I don't think we're there just yet.)
“The software has to present a worthwhile target (ie have a substantial long term userbase) before anyone will bother to look for exploits”
MaraDNS is a worthwhile target; two people have been auditing it this year, in fact:
https://github.com/samboy/MaraDNS/pull/137
https://github.com/samboy/MaraDNS/security/advisories/GHSA-c...
Has OpenWRT released a new build yet?
Answer: no, but they're working on it.
https://forum.openwrt.org/t/dnsmasq-set-of-serious-cves/2500...
DD-WRT is also on point...
https://github.com/mirror/dd-wrt/issues/465
https://svn.dd-wrt.com/changeset/64944
https://svn.dd-wrt.com/changeset/64905
The release is "coming soon".
Maybe this is the kick in the ass Debian needs to upgrade the embarrassingly ancient dnsmasq in "stable" because while I can't think of any new features, the latest versions contain many non-CVE bug fixes.
But I doubt it, they will lazily backport these patches to create some frankenstein one-off version and be done with it.
Before anyone says "tHaT's wHaT sTaBlE iS fOr": they have literally shipped straight-up broken packages before, because fixing it would somehow make it not "stable". They would rather ship useless, broken code than something too new. It's crazy.
They're not going to put a newer version in stable. The way stable gets newer versions of things is that you get the newer version into testing and then every two years testing becomes stable and stable becomes oldstable, at which point the newer version from testing becomes the version in stable.
The thing to complain about is if the version in testing is ancient.
Looks like the version in stable is 2.91, which was released within a couple months of trixie. It's not 'ancient' by any stretch.
FWIW the fixes referenced here are already fixed in trixie: https://security-tracker.debian.org/tracker/source-package/d...
Yeah was about to comment, parent says "if it is ancient", it is not. So the root comment is nothing burger. Stable has 1 release cycle old, and depending on how things play out, testing may have 2.93 or later anyways.
No, that's exactly the thing to complain about.
That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. Not to mention, you think the C of today is bad? Have you looked at old C?
And the disadvantage is that backporting is manual, resource intensive, and prone to error - and the projects that are the most heavily invested in that model are also the projects that are investing the least in writing tests and automated test infrastructure - because engineering time is a finite resource.
On top of that, the backport model heavily discourages the kinds of refactorings and architectural cleanups that would address bugs systemically and encourage a whack-a-mole approach - because in the backport model, people want fixes they can backport. And then things just get worse and worse.
We'd all be a lot better off if certain projects took some of the enthusiasm with which they throw outrageous engineering time at backports, and spent at least some of that on automated testing and converting to Rust.
> That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. Not to mention, you think the C of today is bad? Have you looked at old C
The automatically tested Debian release is called Debian Testing. And it is stable enough.
Debian Stable is basically "we target particular release with our dependencies instead of requiring customer to update entire system together with our software". That model works just fine as long as you don't go too far back.
> On top of that, the backport model heavily discourages the kinds of refactorings and architectural cleanups that would address bugs systemically and encourage a whack-a-mole approach - because in the backport model, people want fixes they can backport. And then things just get worse and worse.
Narrator: It turned out things were not getting worse, they were just fine.
> We'd all be a lot better off if certain projects took some of the enthusiasm with which they throw outrageous engineering time at backports, and spent at least some of that on automated testing and converting to Rust.
That project is RedHat, not Debian, they backport entire features back to old versions (together with bugs!)
> That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time.
That's not what it's about.
What it's about is, newer versions change things. A newer version of OpenSSH disables GSSAPI by default when an older version had it enabled. You don't want that as an automatic update because it will break in production for anyone who is actually using it. So instead the change goes into the testing release and the user discovers that in their test environment before rolling out the new release into production.
> On top of that, the backport model heavily discourages the kinds of refactorings and architectural cleanups that would address bugs systemically and encourage a whack-a-mole approach - because in the backport model, people want fixes they can backport.
They're not alternatives to each other. The stable release gets the backported patch, the next release gets the refactor.
But that's also why you want the stable release. The refactor is a larger change, so if it breaks something you want to find it in test rather than production.
You're going to have to update production at some point, and delaying it to once every 2 years is just deferred maintenance. And you know what they say about that...
So when you do update and get that GSSAPI change, it comes with two years worth of other updates - and tracking that down mixed in with everything else is going to be all kinds of fun.
And if you're two years out of the loop and it turns out upstream broke something fundamental, and you're just now finding out about it while they've moved on and maybe continued with a redesign, that's also going to be a fun conversation.
So if the backport model is expensive and error prone, and it exists to support something that maybe wasn't such a good idea in the first place... well, you may want something, but that doesn't make it smart.
Get thru the issues once every 2 years is entirely fine. Farther than that and you get problems. We do that for ~500 systems of very varied use. I wouldn't want to do it yearly (or dread on rolling release) but I also wouldn't want to do it any less often coz of issues you mentioned.
> And if you're two years out of the loop and it turns out upstream broke something fundamental, and you're just now finding out about it while they've moved on and maybe continued with a redesign, that's also going to be a fun conversation.
Having that sprung on you because you decided to run everything on latest is worse.
"Oh we have CVE, we now need to uproot everything because new version that fixes it also changed shit"
With release every year or two you can *plan* for it. You are not forced into it as with "rolling" releases because with rolling you NEED to take in new features together with bugfixes, but with Debian-like release cycle you can do it system by system when new version comes up and the "old" one still gets security fixes so you're not instantly screwed.
> So if the backport model is expensive and error prone, and it exists to support something that maybe wasn't such a good idea in the first place... well, you may want something, but that doesn't make it smart.
It exists in that format because people are running businesses bigger than "a man with a webpage deployed off master every few days"
> You're going to have to update production at some point, and delaying it to once every 2 years is just deferred maintenance. And you know what they say about that...
Updated what, specifically in production?
If you need a newer version of Python or Postgres or whatever it is possible to install it from third-party repos or compile from source yourself. But having a team of folks watch all the other code out there is a load off my plate: not worrying about libc, or OpenSSH, or OpenSSL, or zlib, or a thousand other dependencies. If I need the latest version for a particular service I would install that separately, but otherwise the whole point of a 'packagized' system is to let other folks worry about those things.
> So when you do update and get that GSSAPI change, it comes with two years worth of other updates - and tracking that down mixed in with everything else is going to be all kinds of fun.
I've done in-place upgrades of Debian from version 5 to 11 at my last job on many machines, never once re-installing from scratch, and they've all gone fine.
Further, when updates come down from the Debian repos I don't worry about applying them because I know there's not going to be weird changes in behaviour: I'm more confident in deploying things like security updates because the new .deb files have very focused changes.
There are two different kinds of updates.
One is security updates and bug fixes. These need to fix the problem with the smallest change to minimize the amount of possible breakage, because the code is already vulnerable/broken in production and needs to be updated right now. These are the updates stable gets.
The other is changes and additions. They're both more likely to break things and less important to move into production the same day they become public.
You don't have to wait until testing is released as stable to run it in your test environment. You can find out about the changes the next release will have immediately, in the test environment, and thereby have plenty of time to address any issues before those changes move into production.
> One is security updates and bug fixes.
That's where you're wrong. They're not one and the same.
Debian stable often defers non-security bug fixes for up to two years by playing this game.
I'm not interested in new features unless they make things actually work.
Debian stable time and again favors broken over new. Broken kernels, broken packages. At least they're stable in their brokenness.
Hence my complaint.
Haven't noticed much broken.
But I have noticed far more broken in distro that DOES backport features, RHEL/Centos. So many that we migrated away from it, when they backported a driver bug into centos 5 and then did the same backport of a bug for centos 6.
Also rebuilding package is trivial if you don't agree with what should and should not go into stable version
You definitely need different channels for high priority fixes and normal releases, stable and testing releases and all that.
But two years is impractical and Debian gets a ton of friction over it. Web browsers and maybe one or two other packages are able to carve out exceptions, because those packages are big enough for the rules to bend and no one can argue with a straight face that Debian is going to somehow muster up the manpower to do backports right.
But for everyone else who has to deal with Debian shipping ancient dependencies or upstream package maintainers who are expected to deal with bug reports from ancient versions is expected to just suck it up, because no one else is big enough and organized enough to say "hey, it's 2026, we have better ways and this has gotten nutty".
Maybe the new influx of LLM discovered security vulnerabilities will start to change the conversation, I'm curious how it'll play out.
> ...upstream package maintainers who are expected to deal with bug reports from ancient versions...
They are not expected to deal with this. This is the responsibility of the Debian package maintainer.
If you (as an upstream) licensed your software in a manner that allows Debian to do what it does, and they do this to serve their users who actually want that, you are wrong to then complain about it.
If you don't want this, don't license your software like that, and Debian and their users will use some other software instead.
If package maintainers were always fine upstanding package maintainers as you imagine them to be I wouldn't be complaining, but I have in fact had Debian ship my software and screw it up and gotten a flood of bug reports, so... :)
I think you need to chill out. Relicensing the way you suggest would be _quite_ the hostile act, and I'm not going to that either. But I am an engineer, so of course I'm going to talk about engineering best practices when it comes up.
You don't have to take it as an attack on your favorite distro - that really does pee in the pool of the upstream/downstream relationship between distros and their upstream.