Ocaml was fine in 2001.

In C you can normally directly map struct to network packets so that's quite easy. In other languages it's not often as simple.

Plus of course they are slower and bigger.

If humans can find bugs, why can't humans write flawless code?

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

Have you ever met a security engineer? I’ve never met one who was also a good engineer (not saying they don’t exist, I just haven’t met one). Do they find vulnerabilities? Sure. Could they write the tools they use to find vulnerabilities, most probably not.

How do you define flawless though?

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?

Just because something is good at finding bugs, it may not find all the bugs. Finding a bug only tells you there was one bug you found, it doesn't tell if the rest is solid.

You could argue the answer to this question depends on if you believe P=NP

Yeah, you still have to check for the limits, not just declare them. Then have fun smashing anything.

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.

"Oh, I see you've discovered subatomic particles... here, have some quantum phenomena, see how long that keeps you busy"

I use maradns to provide dns, not to resolve it. My vps does not require its own dhcp server.

I use dhcpd. It doesn't update local DNS entries. I have no need for that.

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.

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.

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.

"Too few contributors".

I was a language explorer and I think I hadn't heard of Ocaml by then. Even if you built the best dnsmasq project ever in Ocaml nobody would have heard of it or known how to build it.

An eternal summer of CVEs is upon us

> What's stopping you?

Based on their comment I guess they are worried they won't earn enough stars on github

Could you please stop breaking the site guidelines? We've already asked you once.

https://news.ycombinator.com/newsguidelines.html

No, a collection of fuzzers and the lean proof assistant found (almost) no bugs.

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.

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.

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.

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

The only thing worse than changing APIs is never changing APIs. Having to use APIs from 5 years ago sucks.

> That means that the python code on them no longer works on current python versions, C++ needs some tweaks because some library changed API.

And this is why you update often, to keep up with the programming language ecosystem too. I have seen way too many times software unmaintained for years and then when it was actually time to upgrade it would take much more time to bring it to current framework versions than it would have taken if it was updated regularly throughout the years.

And I was not referring to hobby projects you do at home.

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

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

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

> Demonstrably some software has fewer bugs

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

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

They really are, though. Security is all-encompassing, including not just programming languages, libraries, programs, but also systems, humans and their processes. Don't forget physical security either.

There are no silver bullets, and if the Rust Hype Squad told you there were and all you had to do was buy their product, they were just bamboozling you to push adoption of their pet language.

Write in whichever language you like. Including Rust. Including C. Even PHP. You can write secure software if you put your mind to it.

Ah...these security issues are perfectly cromulent because my shiny new magical beans language let's me screw up in brand new ways, not the old and busted boomer screwups. New is always awesome.

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

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

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

I don't think you should take responsibility for bugs. Debugging is the act of removing bugs, so programming is the act of putting them in. Free software, per license, must not come with guarantees because the legal implications of any warranty whatsoever could cripple free software projects. The license of your nice DNS server includes the "as-is" wording for good reason.

That said, it is comendable that you've gone out of your way to hold up your software against very high standards. That kind of quality speaks for itself :)

Why is Lua 5.1 the most popular version?

Not sure how reliable this site is, but if it is correct it looks like 10: https://www.cvedetails.com/vulnerability-list/vendor_id-72/p....

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 project has the advantage of being old enough for them to be fixed.

That's exactly the point though - replacing established projects is inherently risky no matter how many safety buzzwords the replacement can cram into its GitHub tags.

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

One sees “b0e6725c”, i.e. a 32-bit unsigned number

Likewise:

  rg32.randomseed("shakna3")
  print(string.format("%x %x",rg32.rand16(),rg32.rand16()))

Gives us “b0e6 725c”.

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.

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.

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

Yes, I can.

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

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

I'm personally not against Rust rewrites in principle. But doing them in this drive-by hostile manner, esp. with non-GNU licenses smells "hostile takeover" for me, and dismantling core free software utilities is not nice in general.

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

I'm pretty sure we are getting close to the point where a few thousand bucks worth of tokens is enough for an agent coding session to reproduce a significant sized (but not linux kernel sized) C codebase in Rust that's 100% security bug for security bug compatible with the original. And _maybe_ "given enough eyeballs, all bugs are shallow" was true or even close top true once. But non of the "new code" ever has a _single_ eyeball cast over it. You know how sometimes you can stare into the code you wrote for weeks, but as soon as somebody else sees it they go "Hmmm, that bit looks odd. Are you sure it's right?" For most vibe coders or agents coders, it's all the same tool that generated the code that's looking for the bugs - it seems reasonable to assume that if a particular LLM generated the buggy code in the first place, it's at least as unlikely to find the bugs as a human who write buggy code?

I think I was ambiguous.

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

> People seem to think that rewriting in rust just magically fixes all issues

Citations and links, please.

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

If you want that, you don't want Debian. Other people do.

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?

Refactoring and rewrites prove time and time again that they also introduce new bugs and changes in behaviour that users of stable releases do not want.

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.

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

How do you do QA without locking a set of features?

You have far too much faith in automated testing.

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)

...or just leave grandparents on the previous version of Stable until they get a new computer. Honestly not a huge fan of upgrading software at all, if I'm the one supporting the machines.

> Which part of the comment comes off as fanatic to you?

I didn't use the word 'fanatic' neither the previous comment you were responded too.

> Can you discuss productively without attacks?

So you thing someone telling you "look a little harder" is a "personal attack" ? After I took some time to give you a link you ask for ?

> I'm not seeing fanaticism.

You are the only one using this word in this discussion.

I've brought this up with leap second adjustments; a process you do once every two years is one you'll never get good at. If you want them to go smoothly, do them monthly.

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

Personally I'd rather have a manageable stream of little bad things consistently over time rather than suddenly having a mountain of bad things one day.

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

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.

I like rust as a language, but boy, the violent, zero-sum proselytising gets on my nerves. It's not enough for Rust to win, but C must be beaten to a pulp and its head mounted on a pike.

New projects wearing an another project's skin have always bothered me - regardless of language. Ubuntu did a similar thing way back with libav masquerading as ffmpeg.

But removing all the memory footguns while introducing hundreds of syscalls footguns where rust won't help you at all might not be better at all,

Well, recursively trying to perfect lower layers is what I am advocating for us to not do.

As a guy who prefers to stop and think before coding, to me a lot of the older UNIX / GNU primitives seem broken (like the env vars process inheriting discussion that was here a while ago) and should be completely rethought. I also think people overreact and believe "everything will break". And we have libraries and runtimes that only implement small parts of libc and the deployed apps that use them are running mostly fine for years.

My broader point was: shall we not start breaking away from all this legacy? Must we always rely on corporations to lead the charge?

But yes, I do of course agree with the only 24h a day thing. And likely nobody would want to pay for such a trail-blazing work anyway. Sad world.

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

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.

Why not indeed? It would bring me a lot of hope.

Some time ago I loved the idea of Fuchsia... but then I learned it's made by Google. Sigh.

Well, I don't see them in HN is what I am saying. Obviously not scanning 24/7 but every time I enter an HN thread where Rust is even loosely mentioned, I brace for the inevitable bullies imagining they are victims. And this thread is exactly the same, sadly.

I am genuinely curious where this fanatic group is. Where are you witnessing them?

> But why avoid Rust itself? Why look down on any rewrite-in-Rust initiatives?

It's not avoiding, but choosing not to work with it, and it boils down to a couple of reasons. First, I don't work with a language which doesn't have a native GCC frontend. This is part due to supporting GCC & Free Software, and part don't liking rugpulls like license changes and whatnot. My personal weight is beyond negligible in changing outcomes of big currents, but at least I have my principles and stick to them. It's worth noting that I'm not "burning inside" to keep this stance. It's natural for me to do this, and I already like and write C++ and I'm somewhat experienced in that preventing race conditions and memory safety, so that keeps me covered. For smaller stuff I like Go these days. It's a goofball of a language which is very performant and excellent for what it's designed for.

I like to have a tool belt covering a wide gamut of scenarios, and what I use most covers all the needs I have. So Rust is interesting, I don't need it for now.

For the rust rewrites, while I'm not against them in principle, rewriting GPL software with MIT and other permissive licenses is against my values, so I don't support any of them. Writing GPL software with Rust is very possible, and I might do that in the future, but currently I have a couple of heavyweight C++ projects I'd rather work on (in the caliber of material simulations running on HPC systems).

> I refuse to feel shame about wanting to learn and absorb other people's expertise.

My reasons for not interacting with communities are very different. I'm not ashamed of failing, doing mistakes or whatnot. The reasons of I'm tired of interacting with rude people who gets their dopamine from putting people down, so I don't want to navigate all the thorns of the people to get a small bit of knowledge from them. Second, I'm relatively good with reading language references and documentation. I can ingest API documentation with ease and work from first principles.

If required, I can fight the good fight in any arena. I just don't see value of doing it for anything and everything.

In short, I'm not that hopeless to play that game. I'll rather die on hills which are worthy of the fight.

> I start with an LLM session

I don't use LLMs because I don't condone how they are trained, and again reading the reference is much better than a chat interface for me.

Hope that helps.

> I am an engineer, so of course I'm going to talk about engineering best practices when it comes up.

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.

[flagged]