3 ms·

Thank you for your concern. I fixed CVE-2014-5461 for Lunacy back in 2021: https://github.com/samboy/lunacy/commit/4de84e044c1219b06744bfc0d80f6b8568e58e9a ht

• shakna 5mo ago
  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.)
  • strenholme 5mo ago
    >>>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/2e154c163a465ee7ead3f2827be782e9e3fd7c8c https://github.com/samboy/MaraDNS/commit/2e154c163a465ee7ead... I patched it on my own in 2021: https://github.com/samboy/MaraDNS/commit/efddb3a92b9cee30f115a42b6745f3c88b8e341a 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 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 5mo ago
      > 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 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 https://github.com/samboy/LUAlibs/blob/master/rg32.c#L59
      • strenholme 5mo ago
        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 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/LUAlibs/blob/master/rg32.c#L45 https://github.com/samboy/MaraDNS/blob/master/coLunacyDNS/lunacy/lmathlib.c#L203 https://github.com/samboy/MaraDNS/blob/master/coLunacyDNS/lu... https://github.com/samboy/lunacy/blob/master/src/lmathlib.c#L203 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.
• asddubs 5mo ago
  Why is Lua 5.1 the most popular version?
  • strenholme 5mo ago
    Very good question. I can tell you why I chose Lua 5.1 for MaraDNS: • 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.
    • asddubs 5mo ago
      appreciate the answer!
• tosti 5mo ago
  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 :)