Repository navigation
Conversation
The autotools build compiles with -fvisibility=hidden and gets HAVE_VISIBILITY from gl_VISIBILITY, so WP11_LOCAL functions stay out of the dynamic symbol table. The CMake build set neither, so libwolfpkcs11.so exported about 200 internal functions next to the PKCS#11 API. Build the library with hidden visibility on GCC and Clang and define HAVE_VISIBILITY. The PKCS#11 v3.0 and v3.2 functions were declared without WP11_API, so hidden visibility would drop them, and the autotools build did not export them either. Declare them with WP11_API so both builds export the whole C_* API and nothing else. Also register debug_test with skip code 77. It exits 77 when DEBUG_WOLFPKCS11 is not defined, and CTest counted that as a failure, so ctest failed on every non-debug CMake build.
The test never called wolfCrypt_Init() itself. It only worked because the module, linked against the same libwolfcrypt, called wolfCrypt_Init() in C_Initialize and so set up the crypto callback table on the test's behalf. Against a module with its own wolfSSL, wc_CryptoCb_RegisterDevice() fails with BUFFER_E. Initialize and clean up wolfCrypt in main(). The test binary no longer links the module, which it only loads through wc_Pkcs11_Initialize(), and WOLFPKCS11_MODULE selects the module to test, defaulting to the one the Makefile builds. The debug probe now keeps its handle open until cleanup. Closing it right away unloaded the module whenever nothing else held it, which reset the debug flag before wc_Pkcs11_Initialize() loaded the module again, so the debug build of the module never logged. The test and debug targets refuse a module that depends on libwolfssl. Its wolfSSL calls would bind to the test's own wolfCrypt build, which has a different configuration, and crash.
--with-static-wolfssl=FILE (autotools) and WOLFPKCS11_STATIC_WOLFSSL (CMake) link a static, position independent libwolfssl into the shared library, so it has no run time dependency on libwolfssl. Both need an ELF linker, accept only a static wolfSSL and build only the shared library. The wolfSSL symbols are hidden with --exclude-libs,ALL. Without that the embedded wolfSSL exports its whole API, and in a process that already has a libwolfssl.so, such as a wolfSSL application loading the module through wc_Pkcs11_Initialize(), the module's calls bind to the application's copy even though it is loaded with RTLD_LOCAL. With a different wolfSSL configuration that crashes. -Bsymbolic also binds the module's own C_* functions to itself, and -z text turns text relocations from an archive built without PIC into a link error. -z defs does the same for a wolfSSL function missing from the archive, which the loader would otherwise resolve against the application's libwolfssl. It also rules out sanitizer builds whose runtime is not linked into shared objects, such as clang's AddressSanitizer. The archive comes first in LIBS, so libraries it needs can follow it, and the library is relinked when the archive changes. The installed CMake package and the wolfpkcs11-config script no longer refer to wolfssl in this mode. wolfTPM support is rejected in this mode, because libwolftpm links its own wolfSSL and the TPM crypto callback would be registered there rather than in the copy the module uses. Eleven tests set allocators with wolfSSL_SetAllocators() to inject allocation failures, track allocations or inspect freed memory. In this mode that call configures the test's own wolfSSL rather than the module's, so these tests are not run. The default build still runs them. A new workflow builds both variants against a static wolfSSL, checks that the library has no libwolfssl dependency or text relocations and exports only C_* functions, including the v3.0 ones, then runs the tests and the wolfSSL interop test against it.
configure expands libdir and includedir into WOLFPKCS11_LIBDIR_ABS and WOLFPKCS11_INCLUDEDIR_ABS for the installed wolfpkcs11Targets.cmake. It did so while prefix and exec_prefix still held NONE, because autoconf only applies the default prefix when it writes config.status. Without --prefix the package therefore pointed at NONE/lib and NONE/include, and find_package(wolfpkcs11) failed on the missing include directory. Expand them with the default prefix in place and restore both variables afterwards.
Nothing in CI installed wolfPKCS11 or used the installed package, so the static-mode changes to the CMake package files and wolfpkcs11-config, and the expanded install paths, were never exercised. Both jobs now install the library and build a small find_package(wolfpkcs11) project from cmake/consumer with no wolfSSL on the search path, then run it. The autotools job installs to the default prefix, which covers the install paths written into the package, and checks that wolfpkcs11-config --libs no longer names wolfssl.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds an opt-in build of libwolfpkcs11.so with a static, hidden wolfSSL inside. The module then has no run time dependency on libwolfssl and can be loaded by an application that uses its own, differently configured wolfSSL.
--with-static-wolfssl=FILE(autotools) andWOLFPKCS11_STATIC_WOLFSSL(CMake) link a PIClibwolfssl.awith--exclude-libs,ALL -Bsymbolic -z text -z defs, so only theC_*API is exported.WP11_API, so both build systems export the fullC_*API and nothing else.WOLFPKCS11_MODULE.NONE/libandNONE/includeinto the installed CMake package when run without--prefix.debug_testcounts as skipped in non-debug CMake builds.Testing
static-wolfssl.ymlworkflow. Its autotools and CMake jobs each build against a static wolfSSL and check that the library has no libwolfssl dependency or text relocations and exports onlyC_*. They then runmake check/ctestand the interop test, install the library, and build afind_package(wolfpkcs11)consumer with no wolfSSL present.Generated by Claude Code