Hi Jakub, I see...
I was using 0.10 because this is what comes with RHEL 9. But now I think it makes sense to add our own version, so it will be 0.11. Cheers, Till July 2, 2025 9:09 PM, "Jakub Jelen" <jje...@redhat.com (mailto:jje...@redhat.com?to=%22Jakub%20Jelen%22%20<jje...@redhat.com>)> wrote: Hi, thank you for the report. The OpenSSL backend involved a lot of refactoring and cleanup over the last years and its possible the 0.10 branch has still some uncaight memory leaks. Frankly speaking, they are not of high priority now. I tried to backport what made sense, but this probably did not made it. If you are still interested in getting this fixed, please open an issue on gitlab and we will see what we can do: https://gitlab.com/libssh/libssh-mirror/-/issues (https://gitlab.com/libssh/libssh-mirror/-/issues) But using the latest release (now 0.11), is your best bet, unless you need to support something old. Jakub On Mon, Jun 30, 2025 at 5:17 PM <g4-l...@tonarchiv.ch (mailto:g4-l...@tonarchiv.ch)> wrote: Now I tried with the latest source tarball (libssh-0.11.2) and the issue has disappeared. So I guess this was a problem with libssh 0.10.4 and not with libcrypto... June 30, 2025 12:35 AM, g4-l...@tonarchiv.ch (mailto:g4-l...@tonarchiv.ch) wrote: Hi there, I'm running my application with valgrind and always end with some lost blocks. With --leak-check=full I get this errors: ==1885125== 128 (96 direct, 32 indirect) bytes in 4 blocks are definitely lost in loss record 9 of 16 ==1885125== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==1885125== by 0x4F1179D: CRYPTO_zalloc (in /usr/lib/x86_64-linux-gnu/libcrypto.so.3) ==1885125== by 0x4E42E13: BN_new (in /usr/lib/x86_64-linux-gnu/libcrypto.so.3) ==1885125== by 0x49363EC: ssh_make_string_bn (bignum.c:77) ==1885125== by 0x4977D18: pki_pubkey_build_rsa (pki_crypto.c:1778) ==1885125== by 0x4964869: pki_import_pubkey_buffer (pki.c:1389) ==1885125== by 0x496523B: ssh_pki_import_pubkey_blob (pki.c:1704) ==1885125== by 0x49317CF: ssh_agent_get_next_ident (agent.c:448) ==1885125== by 0x4933756: ssh_userauth_agent (auth.c:981) ==1885125== by 0x4933A4E: ssh_userauth_publickey_auto (auth.c:1121) Or ==1885125== 128 (96 direct, 32 indirect) bytes in 4 blocks are definitely lost in loss record 8 of 16 ==1885125== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==1885125== by 0x4F1179D: CRYPTO_zalloc (in /usr/lib/x86_64-linux-gnu/libcrypto.so.3) ==1885125== by 0x4E42E13: BN_new (in /usr/lib/x86_64-linux-gnu/libcrypto.so.3) ==1885125== by 0x49363EC: ssh_make_string_bn (bignum.c:77) ==1885125== by 0x4977D18: pki_pubkey_build_rsa (pki_crypto.c:1778) ==1885125== by 0x4964869: pki_import_pubkey_buffer (pki.c:1389) ==1885125== by 0x496523B: ssh_pki_import_pubkey_blob (pki.c:1704) ==1885125== by 0x494725A: ssh_dh_import_next_pubkey_blob (dh.c:289) ==1885125== by 0x4946746: ssh_packet_client_curve25519_reply (curve25519.c:296) ==1885125== by 0x495F343: ssh_packet_process (packet.c:1494) ==1885125== by 0x495ECB8: ssh_packet_socket_callback (packet.c:1336) Or maybe this is an issue with libcrypto? I compiled my program on PopOS (Ubuntu), which uses openssl libssl3 3.0.2-0ubuntu1.19 And libssh version is 0.10.4, compiled from source package. For a simple application I would not worry about this, but this will be a deamon running 24/7 and opening many SSH connections. Cheers, Till
