CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

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.

Other than security, Rust brings major improvement to the tooling and may help bring fresh members that wouldn't want to contribute to C code. I understand why some projects go that route

Given a comprehensive test suite for the original, probably, yes. if the test suite isn't great, you are still going to spend a lot of time/tokens chasing edge cases.

> that's 100% security bug for security bug compatible with the original

You can do this part without AI. c2rust will give you a translation that retains all the security bugs (and all the memory unsafety). The hope is that the AI in the loop will let you convert it to idiomatic rust (and hence avoid the memory unsafely, and in doing so, also resolve some of the security issues).

"bigiain" comment, in the same discussion is an example: https://news.ycombinator.com/item?id=48120707

There is comment like this everywhere, if you don't see them it's just that you don't want to see them. There are a little less frequent than 5 years ago but still frequent enough in each c, c++ or rust discussions.

At a talk to showcase how dumb stars/downloads are to measure popularity I showcased a tool to reach the most downloaded list very easily.

The owners of code repositories that release download counts stats without even aggregating them by IP address are fully aware of it.

Probably some people play the stats to seem popular and get VC funding.

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

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

See this, for example:

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

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

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

• Lua 5.1 is smaller than Lua 5.4

• Lua 5.1 is LuaJIT compatible; Lua 5.4/5.5 isn’t as compatible

LuaJIT is a version of Lua 5.1 which is an incredibly fast scripting language because it, in real time, compiles Lua 5.1 code in to native instructions. The only wart LuaJIT has is that its RISC-V port is incomplete, but that will undoubtedly change as RISC-V slowly gets more popular.

The other reason to stick to Lua5.1 is because Lua changes its syntax between versions; e.g. bitwise operations in Lua 5.4 are very different than how they are done in Lua5.1, to the point it’s difficult to make a polyglot library which can do bitwise operations in both Lua 5.1 and Lua 5.4. I am of the opinion Lua 5.3 should had been named Lua 6.0 for the simple reason that having native integers in Lua is a pretty significant backwards compatibility breaking change.

Since Lua (well, Lunacy) is the only tool in MaraDNS which isn’t standardized (e.g. MaraDNS uses only POSIX-comatible shell scripts, it uses “make” because that’s a standardized tool with multiple implementations, C is also a standard with multiple implementations, etc.), sticking to Lua5.1 allows me to use a version of Lua with multiple implementations and, as such, is informally standardized.

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.

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

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

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.

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.

Not every software needs updates, and if it doesn't, just using the new name for the API all the time is useless churn.

I'm starting to appreciate java, where all my software written for java5 still works fine without a single change.

Updating often would mean waste time every year rather than every 6 years. Do we agree that 6 > 1?

At work they pay me so I'm there no matter what, but it's still a cost for the company to have me do that rather than something useful.

> We've already asked you once.

there are no notifications of any kind about that or the fact the comment has been flagged so I genuinely didn't notice previous one and only noticed this after I noticed rate limiting.