Skip to content

Generated options.h advertises WOLFSSL_TLS13_MIDDLEBOX_COMPAT, but libwolfssl is built without it #11014

Description

@LiD0209

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.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions