Segfault with scram and Npgsql tests

[JelteF]

Running the tests of Npgsql results in a segfault when using scram-sha-256 with odyssey: https://github.com/npgsql/Npgsql

#0  0x00007f36e4221444 in SSL_get_certificate () from /lib/x86_64-linux-gnu/libssl.so.3
#1  0x0000557b251846af in mm_tls_get_cert_hash (io=io@entry=0x7f36d8025810, cert_hash=cert_hash@entry=0x7f36e3a3e8c0, len=len@entry=0x7f36e3a3e898)
    at /home/jelte/opensource/odyssey/build/third_party/machinarium/sources/tls.c:744
#2  0x0000557b25188f5d in machine_tls_cert_hash (obj=obj@entry=0x7f36d8025810, cert_hash=cert_hash@entry=0x7f36e3a3e8c0, len=len@entry=0x7f36e3a3e898)
    at /home/jelte/opensource/odyssey/build/third_party/machinarium/sources/cert_hash.c:16
#3  0x0000557b2517ba38 in od_scram_read_client_final_message (io=0x7f36d8025810, scram_state=scram_state@entry=0x7f36e3a3e9a0, auth_data=<optimized out>, auth_data_size=<optimized out>,
    final_nonce_ptr=final_nonce_ptr@entry=0x7f36e3a3e988, final_nonce_size_ptr=final_nonce_size_ptr@entry=0x7f36e3a3e990, proof_ptr=0x7f36e3a3e998) at /home/jelte/opensource/odyssey/sources/scram.c:644
#4  0x0000557b25157389 in od_auth_frontend_scram_sha_256 (client=0x7f36d8025b10) at /home/jelte/opensource/odyssey/sources/auth.c:551
#5  0x0000557b25157fad in od_auth_frontend (client=client@entry=0x7f36d8025b10) at /home/jelte/opensource/odyssey/sources/auth.c:684
#6  0x0000557b2516cdef in od_frontend (arg=0x7f36d8025b10) at /home/jelte/opensource/odyssey/sources/frontend.c:2230
#7  0x0000557b2518a6e4 in mm_scheduler_main (arg=0x7f36c0000c70) at /home/jelte/opensource/odyssey/build/third_party/machinarium/sources/scheduler.c:17
#8  0x0000557b2518ba99 in mm_context_runner () at /home/jelte/opensource/odyssey/build/third_party/machinarium/sources/context.c:28

[x4m]

This might happend when Odyssey is build with OpenSSL that is different from OpenSSL used when building SCRAM part of Postgres (Odyssey depends on postgresql-server-dev). Thanks for letting us know!

@reshke I think this is related to Jammy + OpenSSL 3.0 issues you observed recently

[JelteF]

I wanted to confirm that this issue was indeed happening on Ubuntu 22.04