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

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

See this, for example:

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

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.

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)

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

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.

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.

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.

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