Closed OmentaElvis closed 1 month ago
Hi @OmentaElvis we currently doesn't support this module on 32bit. All cdef is assuming it's 64 bit. PR's are welcomed!
I would still recommend use of correct types as requested by external c functions regardless of the system. Using different types may lead to undefined behaviour even if it matches the desired bit width.
In this case EVP_PKEY_derive
expects a size_t*
and the ctypes has the defination for ptr_of_size_t
which is the correct type required.
That will ensure correctness and making it more platform independent without worrying about compatibility in the first place.
ptr_of_size_t
is actually ffi.typeof("size_t[1]")
which is the correct way to create a size_t*
and at same time initialize
the address of the pointer that points to.
Is that not the intended type? I followed through the ffi code
local outlen = ctypes.ptr_of_size_t() -- size_t*
outlen[0] = 32 -- assign example value
C.EVP_PKEY_derive(ctx, buf, outlen) -- pass the ptr to size_t
I see your point, you are mentioning the error in kdf
, but i was looking at the usage of EVP_PKEY_derive
in pkey
.
When running OpenResty on a 32-bit system, I encountered an error originating from lua-resty-sessions, which originated from lua-resty-openssl. The specific error message is:
The error occurs on invokation of
EVP_PKEY_derive
After tracing the parameters, I found that the issue is caused by the
outlen
variable inkdf.lua
being initialized asHowever, the target FFI function
EVP_PKEY_derive
expects asize_t*
argument, which is 32-bit on a 32-bit machine.The problem arises because
size_t
is architecture-dependent, and the current implementation assumes a 64-bit system. To ensure cross-compatibility, theoutlen
variable should be initialized assince there is already a
ptr_of_size_t()
in ctypes definitions.Steps to reproduce:
events { worker_connections 1024; }
http { init_by_lua_block { require "resty.session".init({ remember = true, audience = "demo", secret = "RaJKp8UQW1", storage = "cookie", }) }
server { listen 8080; server_name localhost; default_type text/html;
} }
Note I know little about cryptography but I am a c dev and I believe this was not the intended behaviour. I tried to patch my copy and it worked but restrained myself from making a pull request to avoid breaking stuff.