TEE Build Failure: SSL Symbol Conflict with rdkafka-sys in StageX Environment

[Ashwin-3cS]

TEE Build Failure: SSL Symbol Conflict with rdkafka-sys in StageX Environment

Problem

rdkafka-sys build fails in TEE enclave environment with:

Error relocating /usr/bin/cmake: SSL_get0_group_name: symbol not found
Caused by:
  process didn't exit successfully: /src/attestation_server/target/release/build/rdkafka-sys-596dbdbe14e84fbe/build-script-build (exit status: 101)
  
thread 'main' panicked at /root/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rdkafka-sys-4.9.0+2.10.0/build.rs:36:33:
Command failed with error code 127

Reproduction Steps

# In StageX-based container with musl target:
WORKDIR /src/_rs_file_
cargo build --target x86_64-unknown-linux-musl
# Fails when rdkafka-sys invokes cmake to build librdkafka from source

Environment

• Platform: AWS Nitro Enclaves TEE
• Base Images: StageX (stagex.tools) deterministic build toolchain
• Target: x86_64-unknown-linux-musl
• Dependency: rdkafka = { version = "0.36", features = ["cmake-build"] }
• Timeline: Previously worked 2-3 months ago, now fails due to dependency ecosystem drift

Root Cause Analysis

The cmake binary in StageX environment is dynamically linked to OpenSSL 3.0+ (which exports SSL_get0_group_name symbol) while the musl runtime environment has an older/incompatible OpenSSL version that lacks this symbol. This creates a runtime linking failure when cmake attempts to execute during the rdkafka-sys build process.

Request for StageX Team Consultation

The core issue is that StageX's cmake binary has SSL symbol dependencies that conflict with the musl runtime environment. This affects the deterministic build guarantee that StageX is designed to provide.

Impact

• Blocks TEE attestation server builds - Cannot compile critical infrastructure components
• Affects dependency reproducibility - Builds that worked months ago now fail unpredictably
• Forces migration to alternatives - Must use less battle-tested pure Rust Kafka implementations
• Breaks StageX determinism promise - Hermetic builds are no longer guaranteed reproducible

Workaround Currently Used

Migrated to rskafka (pure Rust Kafka client) which builds successfully but exhibits runtime stability issues (consumer stops polling after extended operation).

Request

We'd appreciate collaboration with the StageX team to determine the best long-term solution that maintains StageX's deterministic build guarantees while supporting common C library dependencies like librdkafka that are widely used in the ecosystem.