build: avoid exporting secp256k1 symbols
What the developer wrote
Authored by Cory Fields
build: avoid exporting secp256k1 symbols
Take advantage of the new secp256k1 option to avoid visibility attributes on
API functions.
While most users of a shared libsecp always want API functions exported so that
they can actually be linked against, we always build it statically. When that
static lib is linked into a (static or shared) libbitcoinkernel, by default its
symbols end up exported there as well.
As libsecp is an implementation detail of the kernel (and any future Core lib),
its symbols should never be exported.
What changed, and why it matters
This change adjusts how Bitcoin Core builds an internal cryptographic library (libsecp256k1) so that its internal function names are no longer exposed in the final library files. It is a hardening/cleanup change rather than a fix for an active bug or exploit. The commit message frames it as preventing implementation-detail symbols from leaking out of the kernel library, which can reduce attack surface but does not by itself fix a known vulnerability.
Treat as a routine hardening improvement. No urgent action is required. Reviewers may want to verify that downstream tooling or tests do not rely on secp256k1 symbols being exported from libbitcoinkernel, and that the change does not break supported build configurations.
Security signals we found
Symbol visibility reduction for embedded cryptographic library
Prevents internal implementation-detail symbols from being exported from libbitcoinkernel
Build-system hardening, not a runtime bug fix
No CVE, advisory, or exploit evidence present in commit or references
Evidence from the diff
The commit modifies cmake/secp256k1.cmake to set CMAKE_C_VISIBILITY_PRESET hidden and SECP256K1_ENABLE_API_VISIBILITY_ATTRIBUTES OFF when configuring the embedded libsecp256k1 build. Because Bitcoin Core links libsecp256k1 statically into libbitcoinkernel, the secp256k1 API symbols were previously exported from libbitcoinkernel by default. This change hides those symbols so they are not part of the dynamic symbol table of the resulting library. It is a build-hardening measure that reduces the exported attack surface and prevents consumers from accidentally or intentionally depending on libsecp256k1 through libbitcoinkernel.
Changed components
cmake/secp256k1.cmakeEmbedded libsecp256k1 build configurationlibbitcoinkernel symbol exportsInspect captured patch +5 / −0
diff --git a/cmake/secp256k1.cmake b/cmake/secp256k1.cmake
index 5302f516..c82f361a 100644
--- a/cmake/secp256k1.cmake
+++ b/cmake/secp256k1.cmake
@@ -9,6 +9,11 @@ function(add_secp256k1 subdir)
message("Configuring secp256k1 subtree...")
set(BUILD_SHARED_LIBS OFF)
set(CMAKE_EXPORT_COMPILE_COMMANDS OFF)
+
+ # Unconditionally prevent secp's symbols from being exported by our libs
+ set(CMAKE_C_VISIBILITY_PRESET hidden)
+ set(SECP256K1_ENABLE_API_VISIBILITY_ATTRIBUTES OFF CACHE BOOL "" FORCE)
+
set(SECP256K1_ENABLE_MODULE_ECDH OFF CACHE BOOL "" FORCE)
set(SECP256K1_ENABLE_MODULE_RECOVERY ON CACHE BOOL "" FORCE)
set(SECP256K1_ENABLE_MODULE_MUSIG ON CACHE BOOL "" FORCE)
Why this scored 29/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.