Bundled BoringSSL symbols are exported globally and collide with other libcrypto (OpenSSL/SQLCipher)

[xander1421]

Ran into this building a desktop app that uses LiveKit for calls and also keeps an encrypted SQLite DB (SQLCipher through rusqlite/libsqlite3-sys, built against OpenSSL).

The prebuilt libwebrtc that webrtc-sys ships bundles BoringSSL statically, and it exports all the crypto symbols globally — EVP_*, HMAC, PKCS5_PBKDF2_HMAC, AES_*, RAND_bytes, and so on. The moment anything else in the binary pulls in another libcrypto (OpenSSL in my case), the linker sees the same symbols defined twice and gives up — LNK1169 on MSVC, multiple definition from mold on Linux.

You can force it through with /FORCE:MULTIPLE (or -Wl,--allow-multiple-definition on Linux), but all that does is keep the first definition it sees and drop the rest, so the whole binary ends up using one of the two implementations for everything. In my case SQLCipher was compiled against OpenSSL's headers but got linked to BoringSSL's implementation. Different struct layouts, so it corrupted the heap the first time it actually did crypto — the app crashed natively on the first PRAGMA key when opening the DB, no Rust panic, and it took me ages to even realize it was a linking issue and not a logic bug.

I've got it working by pointing SQLCipher at the same BoringSSL that webrtc already bundles, so there's only one libcrypto in the binary. That works (SQLCipher 4.5.x happens to be BoringSSL-compatible) but it feels fragile and leans on webrtc-sys's prebuilt internals being there and not changing.

Since BoringSSL is an internal detail of webrtc-sys and nobody links against it directly, would it be possible to build the prebuilt with those symbols hidden/localized? Something like -fvisibility=hidden plus an export allowlist for the actual WebRTC API, or an objcopy --localize-symbols / version-script pass on the static lib. Then it wouldn't step on any other crypto library in the same process and people wouldn't need the force-multiple hack (which is a memory-corruption footgun, as above).

Versions: webrtc-sys 0.3.29, livekit 0.7.37. Hit it on both x86_64-pc-windows-msvc and x86_64-unknown-linux-gnu. Happy to put together a minimal repro (SQLCipher + LiveKit in one binary) if that'd help.

[xander1421]

Did some digging and this isn't new — it's the same underlying thing showing up more than once:

• libwebrtc-sys conflicting with openssl-sys #89 (closed) is this exact BoringSSL vs OpenSSL collision. Same crash signature too: OpenSSL-side Rust code ends up in BoringSSL's CRYPTO_get_ex_new_index / mutex and segfaults. The suggestion there was to rebuild webrtc with rtc_build_ssl=false + rtc_ssl_root=... so it uses your OpenSSL, or to use BORINGSSL_PREFIX per BoringSSL's INCORPORATING.md. Both work, but both mean building your own libwebrtc — nothing changed in the shipped prebuilt, and the issue got closed without a fix, so here it is again.
• libwebrtc.a bundles stripped FFmpeg, collides with ffmpeg-next in same binary (avformat/avcodec symbols resolved from webrtc, not system lib) #1033 (open) is the same problem with a different bundled lib — libwebrtc.a also bundles a stripped FFmpeg and exports avformat/avcodec/etc globally, so anything using ffmpeg-next in the same binary silently binds to webrtc's copy and breaks.

So the real issue isn't BoringSSL specifically, it's that the prebuilt exports everything it statically bundles into the global symbol namespace. Anyone who links one of those same libs (OpenSSL, FFmpeg, …) collides, and the only escape hatches are /FORCE:MULTIPLE (which silently corrupts memory, as above) or rebuilding webrtc yourself.

Would it be possible to fix this once at the prebuilt level — build libwebrtc with the bundled deps' symbols hidden/localized (visibility=hidden + an allowlist for the actual webrtc API, or a prefix/localize pass on the static lib)? That'd solve BoringSSL, FFmpeg, and whatever's bundled next, without every consumer needing custom webrtc builds. Happy to help test a build if useful.