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

Assignees

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