I use Arch on my laptop, when I got it 2 years ago the amd gpu was a bit new so it was prudent to get the latest kernel, mesa, everything. Since I use it daily it's not bad to update weekly and keep on top of occasional config migrations.

I use Debian stable on my home server, it's been in-place upgraded 4-ish times over 10 years. I can install weekly updates without worrying about config updates and such. I set up most stuff I wanted many years ago, and haven't really wanted new features since, though I have installed tailscale and jellyfin from their separate debian package repos so they are very current. It does the same jobs I wanted it to do 8 years ago, with super low maintenance.

But if you don't want Debian stable, that's fine. Just let others enjoy it.

The thing to complain about is if the version in testing is ancient.

It's definitely bad.

Flawless software is hard for an LLM to write, because all the programs they have been trained on are flawed as well.

As a fun exercise, you could give a coding agent a hunk of non-trivial software (such as the Linux kernel, or postgresql, or whatever), and tell it over and over again: find a flaw in this, fix it. I'm pretty sure it won't ever tell you "now it's perfect" (and do this reproducibly).

The CVEs here have their fair share of silly C problems, but also more rigid input validation and handling. These more rigid validations exclude stuff which may even be valid by the spec, but entirely problematic in practice.

As examples, take a look how many valid XML documents are practically considered unsafe and not parsed, for example due to recursive entity expansion. This renders the parsers not flawless and in fact not in spec.

Or, my favorite bait - there should be a maximum length limit on passwords. Why would you ever need a kilobyte sized password?

Whatever the answer to that conundrum might be, LLMs are trained on these patterns and replicate them pretty faithfully.

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".

If I was to run dnsmasq on Debian, it would be in a container. Since I run Pihole (in a container), it kinda is.

Nowadays, even with Ubuntu’s two year or so release cycle I have to use 3rd party packages to have up to date software (PHP being one) and not some version from three years ago.

We no longer live in a world (with few exceptions) where running a 3-5 year old distribution (still supported) makes sense.

It's in popular projects.

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.

(mostly unrelated to topic at hand though)

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.

FWIW the fixes referenced here are already fixed in trixie: https://security-tracker.debian.org/tracker/source-package/d...

sure buddy

It is a distorted view, because projects become popular by allowing indiscriminate commits, bugs, maintainers.

If I'd start a new project I'd allow anyone in and blog about 100 exploits every year, because that is exactly what people want. I'm serious.

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.

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!)

For what you want, there are other distributions for that. Debian also has stable-backports that does what you want.

No need to rage on distributions that also provide exactly what their users want.

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.

DHCP and DNS are connected, PXE requires DHCP entries, so to do a simple setup you'd need to glue together at least 3 daemons otherwise, all with different config syntax

People seem to think that rewriting in rust just magically fixes all issues, but that's not how it works (See recent uutils CVEs). Rewrites tend to have more bugs because the code is new and hasn't been reviewed as much.

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.

Some people will even run Debian on the desktop. I would never, but some people get real upset when anything changes.

Debian does regularly bring newer versions of software: they release about every two years. If you want the latest and greatest Debian experience, upgrade Debian on week one.

From your description, you seem to want Arch but made by Debian?

Don't get me wrong, I use and encourage extensive automated testing. However only extensive manual testing by people looking for things that are "weird" can really find all bugs. (though it remains to be seen what AI can do - I'm not holding my breath)

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

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.

10/10, no regrets, would recommend.

> 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.

Meaning that AI/Rust enthusiasts are supposed to supply solutions. Of course they won't.

Maybe coreutils is so old that most security vulnerabilities was solved before CVE even existed. But I think this is also a good argument why we are replacing a solid piece of C code to Rust just because it is "memory safe" and then have lots of CVEs related to things like TOCTOUs (that Rust will not save you).

The problem with this take is that it’s stuck in the early 2000’s, where all servers are pets to be cared for and lovingly updated in place.

It’s also circular: you have the same problem with the current model if you don’t have a test environment. And if you do have a test environment, releases can be tested and validated at a much higher cadence.

Isn't that essentially Debian unstable (with potentially experimental enabled)? I've been running Debian unstable on my desktops for something like 20 years.

But that does nothing for people who write and support code Debian wants to ship - packaging code badly can create a real mess for upstream.

And despise the name is probably more stable than vast majority of rolling release distros

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/

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...

Is that the Linux way you are on about? No obviously not 8)

I think you mean the "unix idealized but never really happened exactly but we are quite close if you squint a bit ... way" where each tool does one job well and the pipeline takes up the slack.

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.

Debian patches defaults in OpenSSH code so it behaves differently than upstream.

They shouldn't legally be allowed to call it OpenSSH, let alone lecture people about it.

Let them call their fork DebSSH, like they have to do with "IceWeasel" and all the other nonsense they mire themselves into.

When you break software to the point you change how it behaves you shouldn't be allowed to use the same name.

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.

It's important to look at the actual vulnerability at the context, and not just list any CVE which matches by version.

Must they prove their software to you? They're offering an alternative, not bargaining for a deal.

The question is a matter of impact because of how used the software is.

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.

I concur. The last part, however, is quite worrisome. Dnsmasq is ran by one person, published on their own git and I did not see any information about other maintainers.

It is a super important (and great, and useful, and everything) software and i have fears of what will happen one day.

Sure, someone can clone and push to github but it may seriously fragment the ecosystem.

Yes, you can go further, possibly faster. OTOH, nothing replaces experience and in-depth knowledge. GNU Coreutils embodies that knowledge and experience. uutils has none, and just tries to distill it with tests against the GNU one.

...and they get 44 CVEs as a result in their first test.

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.

> 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"

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.

If you want the rolling release like distro, just run debian unstable. That's what you get. It's on par with all the other constantly updated distros out there. Or just run one of those.

Also, Debian stable has a lifetime a lot longer than 2 years, see https://www.debian.org/releases/. Some of us need distros like stable, because we are in giant orgs that are overworked and have long release cycles. Our users want stuff to "just work" and stable promises if X worked at release, it will keep working until we stop support. You don't add new features to a stable release.

From a personal perspective: Debian Stable is for your grandparents or young children. You install Stable, turn on auto-update and every 5-ish years you spend a day upgrading them to the next stable release. Then you spend a week or two helping them through all the new changes and then you have minimal support calls from them for 5-ish years. If you handed them a rolling release or Debian unstable, you'd have constant support calls.

Doing terrible work every 2 years is better than doing it every day?

"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.

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.

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.

It's not! It's the foundation of all dev AI products marketing.

You literally write fewer instead of none, therefore agreeing with the sentence you claimed to say is meaningless.

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.

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.)

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.

Iirc the bugs had to do with linux system details like fs toctou and other things you'd only find out about in production.

Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs, so that every project doesn't have to relearn them at runtime. But the rewrite isn't pure downside.

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.

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.

And by skipping some releases, you will have less of that work. When something is changed in one release, then changed again on the next one, by waiting you only have to do the change once, instead of twice. And sometimes you don't even have to do anything, when something is introduced in one release and reverted in the next one.

LetsEncrypt has been a great example of this in certificate management.

See this, for example:

https://samboy.github.io/MaraDNS/webpage/security.html#CVE-2...

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;
  }

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.

> Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs

I believe trying to make something idiot-proof just generates better idiots, so I prefer having thinner abstractions on the lower level for maintenance, simplicity and performance reasons. The real solution is better documentation, but who values good documentation?

Graybeards and their apprentices, mostly from my experience. I personally still live with reference docs rather than AI prompts, and it serves me well.

Why would a DNS server use Lua scripting? Is this for dynamically responding to requests rather than doing a pure lookup?

• 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”.

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)

I assure you, enormous sums of people prefer Debian the way it is. I do not, ever, want "new stuff" in stable. I have better things to do than fight daily change in a distro, it's beyond a waste of time and just silly.

If you want new things, leave stable alone, and just run Debian testing! It updates all the time, and is still more stable than most other distros.

Debian is the way it is on purpose, it is not a mistake, not left over reasoning, and nothing you said seems relevant in this regard.

For example, there is no better way than backporting, when it comes to maintaining compatibility. And that's what many people want.

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

Personally, If the hardware is working great, seems like a waste of money replacing it, just to upgrade software. Especially with Debian oldstable -> Debian stable where it's usually quite easy and painless.

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.

... 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:

https://github.com/samboy/LUAlibs/blob/master/rg32.c#L59

More discussion is on the coLunacyDNS overview page:

https://samboy.github.io/MaraDNS/coLunacyDNS/

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.)

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.

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.

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.

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.

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...

In an era when DNS was otherwise a monoculture, djbdns was a welcome breath of fresh air.

https://lwn.net/2001/0208/

https://samboy.github.io/MaraDNS/webpage/DNS.security.compar...

Also, my sister post: https://news.ycombinator.com/item?id=48112042

OpenBSD in particular can use competent developers to fix their dogshit filesystem.

The trouble is you seem to be assuming that best practices for you, in your opinion, also apply to everyone else. They don't. Not everyone sees things the way you do or is facing the same issues or is making the same set of tradeoffs. There are downsides to what debian does but there are also upsides.

At this point, given the plethora of high quality options available as well as how easy it is to mix and match them on the same system thanks to container-related utilities and common practices I really don't think there's any room for someone who doesn't like the debian model (ie in general, as opposed to targeted objections) to complain about how they do things. If you want cutting edge userspace on debian stable at this point you have at least 3 options between nix, guix, and gentoo. There's also flatpak and snap which come built in.

I wager it's only a matter of time before we see a mass rooting event that hits Debian hard while everyone running something more modern has already been patched.

I think that might be what cuts down on the grandstanding about "freedoms" and "that's how we've always done things". You certainly are, up until it becomes a public nuisance.

Why would you expect LLMs not to be simultaneously leveraged to catch backports that were missed or inadvertently broken?

Given recent headlines I think it's far more likely that we see a mass rooting event hit one or more of the bleeding edge rolling release distros or language ecosystems due to supply chain compromise. Running slightly out of date software has never been more attractive.