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