[strenholme]

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

If there’s a system where uint32_t is 64 bits, that’s a bug with the compiler (which isn’t following the spec), not MaraDNS.

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

[shakna]

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

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

[strenholme]

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.