The Lua hook based signal handling does not work correctly if signal
handling is setup in a coroutine. signalfd solves that in a nice way,
but is Linux-only.
pkey_meth_derive: to derive a shared symmetric key from two ECC keys
pkey_meth_public_raw: to get the raw form of the public key
import_public_ec_raw: to import the raw form of the public key
generate_p256_keypair: key generation for the P-256 curve
signalfd allows handling signal events using the same method as sockets,
via file descriptors. Thus all signal dispatch can go through the same
main event loop as everything else, removing need for thread-scary
signal handling where execution would just jump to the signal handler
regardless of the state of Lua, and needing to keep track of Lua
states/threads.
Downloaded from http://www.inf.puc-rio.br/~roberto/struct/
This is for compatibility with Lua 5.2 (and 5.1). Eventually we can replace
this with string.pack/string.unpack which are available in 5.3+.
With epoll(7), MAX_EVENTS controls how many events can be retrieved in one
epoll_wait call, while with poll(2) this MAX_WATCHED controls how many
sockets or other FDs can be watched at once.
With `gcc-12 -Wstrict-prototypes` the following warning is shown:
crypto.c:43:13: warning: function declaration isn't a prototype [-Wstrict-prototypes]
43 | static BIO* new_memory_BIO() {
| ^~~~~~~~~~~~~~
This fixes the signature parsing and building to work correctly. Sometimes
a signature was one or two bytes too short, and needed to be padded. OpenSSL
can do this for us.
In Lua 5.3 LUAL_BUFFERSIZE is a macro computed from sizeof and is thus
not known at pre-processing time, so this does not work.
Since Lua 5.1 is no longer supported, we can use luaL_prepbuffsize()
which is available from Lua 5.2
Removes assumption that LUAL_BUFFERSIZE is known at pre-processing time,
which it is not in Lua 5.3 and 5.4, where it is a computed macro based
on sizeof.
Allocation of stack space is safer and faster, no need to worry about
luaL_prepbuffer failing to allocate memory and skipping free()
Probably a duplicate of the comment next to Lmove, recorded by mistake
Lpack can probably be removed at some point in the near future once we
are confident it is not used anywhere.
Equivalent to 'local' in Lua, these functions are exported via the
luaopen_ function, which is the only one needing to be visible outside
of the file.
Pointed out by Link Mauve at some point, but there wasn't really any
rush here.