1
0
mirror of https://github.com/wolfSSL/wolfssl.git synced 2026-10-24 04:09:07 +03:00
Files
wolfssl/cmake
Tobias Frauenschläger 70090dcb38 Make the deprecated wolfSSL_get_session() cache reference opt-in
Without NO_SESSION_CACHE_REF, wolfSSL_get_session() returns a reference into
the process-global client cache rather than a session object. That reference
is valid only while the slot it names still holds the session it was issued
for, which the caller cannot observe, so the safe use of the API is the one
the macro selects. Only the integration recipes defined it, and none of them
for that reason: --enable-opensslextra and --enable-opensslall, which is what
an application written against SSL_get_session() reaches for, left it unset.

settings.h now defines NO_SESSION_CACHE_REF unless WOLFSSL_SESSION_CACHE_REF
is defined, so every build selects it, including the user_settings.h, IDE and
bare-metal builds that have no configure step. Putting the rule in the header
rather than only in configure and CMake means no project has to add a macro to
keep the safe behaviour, and the ones that want the deprecated reference ask
for it instead. --enable-session-cache-ref and -DWOLFSSL_SESSION_CACHE_REF=yes
define that opt-in macro, and options.h records it alongside the negative one
so an application cannot disagree with the library it links.

A build that opts in warns at compile time and the warning names
WOLFSSL_SESSION_CACHE_REF_WARNED, which silences it while keeping the path. It
sits inside the NO_SESSION_CACHE region, so a build without a session cache
and a wolfCrypt-only build stay quiet, and it takes the #warning / #pragma
message form already used for WOLFSSL_KEYLOG_EXPORT_WARNED.

The recipes that define NO_SESSION_CACHE_REF on their own keep doing so and
still win over the option. Both build systems say so rather than leaving a
reported option disagreeing with the build: configure warns and clears its
summary line, CMake warns and syncs the cached option. configure also treats
TITAN_SESSION_CACHE as a conflict, because settings.h derives the macro from
it and that never reaches the compile line for a flag scan to find.

The os-check session-cache-ref entry existed because --enable-opensslextra
left the macro unset. It now asks for the reference path explicitly, or
test_wolfSSL_client_cache_id_overwrite would skip and the generation check
added with it would be covered nowhere.

Anything migrating has one lifetime difference to mind: the deprecated
reference stayed valid after wolfSSL_free(), the session object does not, so
code holding the result of wolfSSL_get_session() past the WOLFSSL it came from
has to move to wolfSSL_get1_session() and wolfSSL_SESSION_free().
2026-09-30 08:33:30 +02:00
..
2026-02-02 10:26:58 +01:00
2026-07-22 09:52:26 +02:00
2026-02-02 10:26:58 +01:00
2026-07-22 09:52:26 +02:00
2026-02-02 10:26:58 +01:00

wolfSSL CMake

This directory contains some supplementary functions for the CMakeLists.txt in the root.

See also cmake notes in the INSTALL documentation file. When building with autoconf/automake, CMake package files are installed by default under $(libdir)/cmake/wolfssl to support find_package(wolfssl). Disable with ./configure --disable-cmake-install.

If new CMake build options are added cmake/options.h.in must also be updated.

For more information on building wolfSSL, see the wolfSSL Manual.

In summary for cmake:

# From the root of the wolfSSL repo:

mkdir -p out
pushd out
cmake ..
cmake --build .

# View the available ciphers with:
./examples/client/client -e
popd

CMake Presets

The CMakePresets.json; see [cmake-presets(https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html)

  • Cross-platform and cross-IDE.

  • Standardized CMake feature (since CMake 3.19+, recommended after 3.21).

  • Works in Visual Studio, VS Code, CLI, CI systems, etc..

Visual Studio Settings

There's also a Visual Studio specific file: CMakeSettings.json. This the file that supports the GUI CMake settings.

See the Microsoft CMakeSettings.json schema reference

Visual Studio (2022 v17.1 and later):

  • Prefers CMakePresets.json if it exists.

  • Falls back to CMakeSettings.json if no presets are found.

  • Lets you override or extend presets via CMakeSettings.json.

Recommendations:

  • Use CMakePresets.json to define shared, cross-platform presets.

  • Use CMakeSettings.json to define Visual Studio-specific overrides, like:

    • Custom output directories
    • Specific environment variables
    • *UI-related tweaks