Generated options.h advertises WOLFSSL_TLS13_MIDDLEBOX_COMPAT, but libwolfssl is built without it
Problem Description
The CMake build can generate a public wolfssl/options.h that defines WOLFSSL_TLS13_MIDDLEBOX_COMPAT, while the actual libwolfssl source files are compiled without that macro in their compile definitions. As a result, the publicly advertised configuration and the library's real compiled behavior diverge.
Build-System Evidence
The cache accepts the variable
In the produced mbox build cache (CMakeCache.txt, line 1):
WOLFSSL_JNI:BOOL=no
WOLFSSL_TLS13_MIDDLEBOX_COMPAT:UNINITIALIZED=yes
So the cache contains a value for WOLFSSL_TLS13_MIDDLEBOX_COMPAT, but it is not a normal declared option.
CMakeLists does not declare an independent option
The only place where WOLFSSL_TLS13_MIDDLEBOX_COMPAT is appended to WOLFSSL_DEFINITIONS is inside the JNI bundle branch in CMakeLists.txt:390:
if(WOLFSSL_JNI)
...
list(APPEND WOLFSSL_DEFINITIONS
...
"-DWOLFSSL_TLS13_MIDDLEBOX_COMPAT")
endif()
There is no standalone add_option("WOLFSSL_TLS13_MIDDLEBOX_COMPAT" ...) declaration.
Generated public header says the macro is enabled
The generated public header wolfssl/options.h:782 contains:
#undef WOLFSSL_TLS13_MIDDLEBOX_COMPAT
#define WOLFSSL_TLS13_MIDDLEBOX_COMPAT
That means downstream code including wolfssl/options.h sees the feature as enabled.
The actual library compile flags do not contain the macro
The real compile definitions for libwolfssl in CMakeFiles/wolfssl.dir/flags.make:5 do not include -DWOLFSSL_TLS13_MIDDLEBOX_COMPAT.
The same omission is visible in the separate audit build's CMakeFiles/wolfssl.dir/flags.make:5.
Source-Inclusion Evidence
wolfSSL library sources enter through libwolfssl_sources.h:36, which pulls in config.h when HAVE_CONFIG_H is set:
#if defined(HAVE_CONFIG_H) && !defined(WC_CONFIG_H_INCLUDED)
#include <config.h>
#define WC_CONFIG_H_INCLUDED
#endif
The library sources therefore follow config.h plus compile definitions during their build, not the generated public wolfssl/options.h.
In the audit build's config.h:1, WOLFSSL_TLS13_MIDDLEBOX_COMPAT is absent.
Preprocessor Cross-Check
I verified the mismatch directly:
- Preprocessing with
#include <wolfssl/options.h> shows
#define WOLFSSL_TLS13_MIDDLEBOX_COMPAT.
- Preprocessing with
#include <wolfssl/wolfcrypt/libwolfssl_sources.h> in the same build environment does not show that macro.
So the generated public header and the library-source build view disagree.
Inconsistency Reason
The build system propagates WOLFSSL_TLS13_MIDDLEBOX_COMPAT into the generated public header, but not into the compile definitions that build libwolfssl.
Decision Reason
This is a real build/configuration bug. It creates a configuration mismatch between what the build artifacts advertise and what the compiled library actually implements. That mismatch directly explains why the produced mbox artifact does not exhibit compatibility-mode wire behavior.
Generated options.h advertises WOLFSSL_TLS13_MIDDLEBOX_COMPAT, but libwolfssl is built without it
Problem Description
The CMake build can generate a public
wolfssl/options.hthat definesWOLFSSL_TLS13_MIDDLEBOX_COMPAT, while the actuallibwolfsslsource files are compiled without that macro in their compile definitions. As a result, the publicly advertised configuration and the library's real compiled behavior diverge.Build-System Evidence
The cache accepts the variable
In the produced
mboxbuild cache (CMakeCache.txt, line 1):So the cache contains a value for
WOLFSSL_TLS13_MIDDLEBOX_COMPAT, but it is not a normal declared option.CMakeLists does not declare an independent option
The only place where
WOLFSSL_TLS13_MIDDLEBOX_COMPATis appended toWOLFSSL_DEFINITIONSis inside the JNI bundle branch inCMakeLists.txt:390:There is no standalone
add_option("WOLFSSL_TLS13_MIDDLEBOX_COMPAT" ...)declaration.Generated public header says the macro is enabled
The generated public header
wolfssl/options.h:782contains:That means downstream code including
wolfssl/options.hsees the feature as enabled.The actual library compile flags do not contain the macro
The real compile definitions for
libwolfsslinCMakeFiles/wolfssl.dir/flags.make:5do not include-DWOLFSSL_TLS13_MIDDLEBOX_COMPAT.The same omission is visible in the separate audit build's
CMakeFiles/wolfssl.dir/flags.make:5.Source-Inclusion Evidence
wolfSSL library sources enter through
libwolfssl_sources.h:36, which pulls inconfig.hwhenHAVE_CONFIG_His set:The library sources therefore follow
config.hplus compile definitions during their build, not the generated publicwolfssl/options.h.In the audit build's
config.h:1,WOLFSSL_TLS13_MIDDLEBOX_COMPATis absent.Preprocessor Cross-Check
I verified the mismatch directly:
#include <wolfssl/options.h>shows#define WOLFSSL_TLS13_MIDDLEBOX_COMPAT.#include <wolfssl/wolfcrypt/libwolfssl_sources.h>in the same build environment does not show that macro.So the generated public header and the library-source build view disagree.
Inconsistency Reason
The build system propagates
WOLFSSL_TLS13_MIDDLEBOX_COMPATinto the generated public header, but not into the compile definitions that buildlibwolfssl.Decision Reason
This is a real build/configuration bug. It creates a configuration mismatch between what the build artifacts advertise and what the compiled library actually implements. That mismatch directly explains why the produced
mboxartifact does not exhibit compatibility-mode wire behavior.