Skip to content

Fix bundled OpenSSL SONAME conflict with .NET HttpClient#225

Merged
MaxRev-Dev merged 2 commits intomainfrom
hotfix/openssl-soname-conflict
Apr 11, 2026
Merged

Fix bundled OpenSSL SONAME conflict with .NET HttpClient#225
MaxRev-Dev merged 2 commits intomainfrom
hotfix/openssl-soname-conflict

Conversation

@MaxRev-Dev
Copy link
Copy Markdown
Owner

Summary

Fixes #224 — Bundled libssl.so.3.2.0 / libcrypto.so.3.2.0 shadow system OpenSSL, breaking .NET HttpClient HTTPS on Linux systems with newer OpenSSL (e.g. Arch Linux with OpenSSL 3.6.1).

Root cause: The existing build patched NEEDED references and renamed files from libssl.so.3libssl.so.3.2.0, but the internal SONAME remained libssl.so.3. When GDAL loads first, the dynamic linker registers the bundled library under SONAME libssl.so.3, shadowing the system OpenSSL. .NET then uses the bundled (older/incompatible) version for TLS, causing SSL_ERROR_SSL at Interop.OpenSsl.Decrypt.

Fix: Add patchelf --set-soname to update the internal SONAME to match the renamed filename. After the fix:

  • Bundled: SONAME libssl.so.3.2.0 — used exclusively by GDAL's libcurl, libpq, etc.
  • System: SONAME libssl.so.3 — used by .NET for HTTPS

Verified via Docker container with LD_DEBUG=libs:

# After fix — two separate libraries, no conflict:
find library=libssl.so.3.2.0 → /app/runtimes/linux-x64/native/libssl.so.3.2.0  (GDAL)
find library=libssl.so.3     → /lib/x86_64-linux-gnu/libssl.so.3               (.NET)

Both GDAL (210 drivers) and HTTPS (HttpClient) work correctly after the fix.

Test plan

  • Docker repro: verified SONAME mismatch with readelf -d
  • Docker repro: confirmed LD_DEBUG shows separate library loading after fix
  • Docker repro: GDAL initializes correctly (210 drivers) after fix
  • Docker repro: HttpClient HTTPS succeeds after fix
  • Full Linux build with collect-deps-makefile changes (requires CI)

The bundled libssl.so.3.2.0 and libcrypto.so.3.2.0 had their files renamed
but retained the internal SONAME of libssl.so.3/libcrypto.so.3. When GDAL
loaded first, the dynamic linker registered the bundled libraries under the
system SONAME, shadowing the system OpenSSL. Subsequent .NET HTTPS requests
via HttpClient/SslStream would then use the bundled (older) OpenSSL instead
of the system version, causing SSL_ERROR_SSL on systems with newer OpenSSL
(e.g. Arch Linux with OpenSSL 3.6.1).

Fix: patch the SONAME inside the bundled libraries to match their renamed
filenames (libssl.so.3.2.0/libcrypto.so.3.2.0) so the dynamic linker no
longer confuses them with the system libssl.so.3/libcrypto.so.3.
The old 7z2107-extra.7z (v21.07) was removed from the 7-Zip server,
causing 404 errors in the Windows build. Update to 7z2501-extra.7z (v25.01).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Bundled libssl/libcrypto conflicts with .NET OpenSSL on Linux

1 participant