Skip to content

Fluxheim 1.3.4

Choose a tag to compare

View all tags
@eldryoth eldryoth released this 22 May 08:48
· 1006 commits to main since this release
Immutable release. Only release title and notes can be modified.
v1.3.4
This tag was signed with the committer’s verified signature.
eldryoth
SSH Key Fingerprint: EoLRQ5k4J5pYz3UMFmkrV798gYFNkToGS2xEPvebqB4
Verified
Learn about vigilant mode.
bc5b3a6
This commit was signed with the committer’s verified signature.
eldryoth
SSH Key Fingerprint: EoLRQ5k4J5pYz3UMFmkrV798gYFNkToGS2xEPvebqB4
Verified
Learn about vigilant mode.

Fluxheim 1.3.4 Release Notes

Summary

Fluxheim 1.3.4 is the OpenSSL FIPS/ISO-capable TLS release for the 1.3 line.
It adds strict terminology, OpenSSL-provider diagnostics, OpenSSL
default-property enforcement for FIPS/ISO-required TLS startup, fail-closed
configuration validation, and release evidence plumbing.

This release does not claim that Fluxheim is FIPS certified, ISO/IEC 19790
certified, or that enabling a Cargo feature makes a deployment compliant.
Validation belongs to the selected cryptographic module and its tested
operating environment. Fluxheim's role is to enforce configuration boundaries,
verify provider status where the backend exposes it, and produce useful
evidence for operators.

  • Release type: OpenSSL FIPS/ISO-capable TLS validation and release tooling
  • Compatibility: no broad config break intended
  • Primary area: OpenSSL FIPS provider diagnostics, OpenSSL default FIPS
    properties, tls.fips.required, tls.iso19790.required, release evidence,
    and FIPS/ISO documentation

Highlights

  • Added docs/fips.md, a standalone FIPS-capable deployment guide covering
    NIST/CMVP references, compliance boundaries, OpenSSL and rustls/AWS-LC paths,
    internal cryptography blockers, and post-1.3.4 roadmap work.
  • Added [tls.fips] required = true as a fail-closed guard for FIPS-required
    configuration. Default builds reject it because they cannot prove a
    validated provider path.
  • Added [tls.iso19790] required = true, tls-openssl-iso19790,
    profile-iso19790-openssl, examples/iso19790-openssl.toml, and the
    iso19790-openssl config-tester profile as ISO/IEC 19790 terminology
    aliases over the same validated-provider enforcement path.
  • Added tls-openssl-fips, an opt-in OpenSSL 3 provider proof path that
    checks that the OpenSSL FIPS provider can be loaded and that an approved
    cipher can be fetched with the fips=yes property query.
  • FIPS-required OpenSSL startup now enables and verifies OpenSSL default FIPS
    properties through EVP_default_properties_enable_fips and
    EVP_default_properties_is_fips_enabled before Pingora TLS services are
    built.
  • The OpenSSL FIPS-capable runtime check verifies that approved AES-GCM can be
    fetched through the default property path and that a non-FIPS cipher is
    rejected there.
  • Patched the vendored pingora-openssl compatibility crate to stop forcing
    openssl/vendored, so FIPS-capable OpenSSL builds can link against the
    operator-selected system OpenSSL provider.
  • Added profile-fips-openssl as a narrow proxy/security/OpenSSL-FIPS feature
    alias for local and release validation.
  • Added profile-iso19790-openssl as the matching ISO/IEC 19790 terminology
    alias.
  • Added fluxheim crypto and fluxheim-config-tester --crypto diagnostics
    showing compiled TLS backends, OpenSSL FIPS provider availability, OpenSSL
    version, and visible OPENSSL_CONF / OPENSSL_MODULES environment.
  • Added examples/fips-openssl.toml and
    fluxheim-config-tester --profile fips-openssl so operators and CI can
    validate the expected OpenSSL FIPS configuration shape.
  • Added examples/iso19790-openssl.toml and
    fluxheim-config-tester --profile iso19790-openssl for the same validation
    path using ISO/IEC 19790 terminology.
  • Added scripts/validate-fips-openssl.sh for local and release checks. It
    builds the FIPS-capable profile, captures provider diagnostics, validates the
    FIPS fixture, and optionally fails if no provider is available with
    FLUXHEIM_REQUIRE_FIPS_PROVIDER=1.
  • The OpenSSL FIPS-capable validation script now also proves fail-closed
    behavior for backend mismatch and non-FIPS TLS policy fixtures.
  • Wired OpenSSL FIPS-capable validation into CI, scripts/checks.sh, the
    optional stable release gate, the deep release gate, and release evidence
    capture.
  • Added an OWASP Top 10 2025 baseline document and validation script mapping
    Fluxheim-owned controls to A01-A10, with a quick CI mode and deeper local
    representative-test mode. The baseline is wired into CI, local checks, stable
    release gates, and release evidence capture.
  • Hardened self-healing rollback state handling so manual and watchdog
    rollbacks atomically consume pending validation before applying a snapshot.
  • Hardened OTLP private-CA loading with symlink-safe, bounded regular-file
    reads.
  • Snapshot stores now normalize Unix directory modes to 0700 and snapshot
    pointer/config/metadata files to 0600.
  • Updated build, feature, config-reference, release-runbook, readiness, and
    roadmap documentation to use "FIPS-capable" language and avoid compliance
    overclaims.

Operator Notes

For local OpenSSL FIPS-provider validation:

scripts/validate-fips-openssl.sh check

For strict validation on a builder that is expected to have a working provider:

FLUXHEIM_REQUIRE_FIPS_PROVIDER=1 scripts/validate-fips-openssl.sh check

Fluxheim does not hardcode provider module directories. Provider discovery uses
OpenSSL's normal configuration and environment model, including OPENSSL_CONF,
OPENSSL_MODULES, distro crypto policies, and compiled-in defaults.

The 1.3.4 OpenSSL path loads the fips provider, fetches an approved cipher
with fips=yes, enables OpenSSL default FIPS properties for the process-default
library context, verifies that those default properties are active, and checks
that the default fetch path rejects a non-FIPS cipher. Operators still need to
install and configure a validated OpenSSL provider according to the selected
module Security Policy; Fluxheim is not itself a validated cryptographic
module.

Build

Build the OpenSSL FIPS/ISO-capable profile explicitly:

cargo build --release --locked --no-default-features \
  --features profile-fips-openssl \
  --bin fluxheim --bin fluxheim-config-tester

cargo build --release --locked --no-default-features \
  --features profile-iso19790-openssl \
  --bin fluxheim --bin fluxheim-config-tester

The profile aliases above are narrow proof builds. FIPS/ISO-capable TLS can
also be combined with cache or PHP-FPM by selecting raw modules and avoiding
profiles that already enable tls-rustls:

# FIPS/ISO-capable cache edge
cargo build --release --locked --no-default-features \
  --features proxy,cache,security,tls-openssl-fips \
  --bin fluxheim

# FIPS/ISO-capable PHP-FPM web build
cargo build --release --locked --no-default-features \
  --features php-fpm,security,tls-openssl-fips \
  --bin fluxheim

These combinations put Fluxheim's TLS listener on the OpenSSL FIPS proof path.
They do not make a blanket FIPS-compliance claim for the entire deployment.
PHP application cryptography, managed ACME account operations, local cache
encryption, OTLP export, and other non-TLS crypto paths still need separate
validated-module evidence, external handling, or disabling for strict
FIPS-required deployments.

The examples intentionally omit acme-client. For a cleaner FIPS/ISO evidence
boundary, use local/static certificates issued and renewed by an approved
external process. If acme-client is added to a FIPS-capable TLS build, ACME
account keys, ACME JWS signing, HTTP client behavior, and CA issuance workflow
must be documented as separate evidence rather than being implied by the TLS
provider proof.

Checksums And Signatures

  • Commit: bc5b3a667a3884a552d8b38dbaa14c569d7eacad
  • Local gate: GitHub CI green before tag; local release metadata checks passed
  • CodeQL/code scanning: no open release-blocking alerts before tag
  • Source archive checksums:
    • 89f56aaf2c756b224eb24cef9eb7b32caa53687a03381d8ad56f1f574bb26428 fluxheim-1.3.4.tar.gz
    • 8aeaac7bb5f83b63c3e3036c77e8f00e954781743b97fa9b753b5681f43666ab fluxheim-1.3.4.zip
  • Binary checksums:
    • c696117886bf9a0fba3c38bcedcbe3a436341a12c9f564d8e6fa6711dbe601bc fluxheim-1.3.4-full-x86_64-linux.tar.gz
    • 2df684b59bc151469a220ac23358912c552ad97aebdf2dd1cf58f38a99a597a0 fluxheim-1.3.4-cache-x86_64-linux.tar.gz
    • 243d4376cd99d3bcaf6c1373baed5851fedff9f22a7ebf1a4adcad4e615351d2 fluxheim-1.3.4-proxy-x86_64-linux.tar.gz
    • fb44f347f49e5a2f32322dfb2fda555c46ad03523579abbb6c2bf06c480b97d7 fluxheim-1.3.4-php-x86_64-linux.tar.gz
    • f2ee4151022ff3219acb3498518bc3974c7970301527c2c2286478e8607f8281 fluxheim-1.3.4-config-tester-x86_64-linux.tar.gz
  • SBOM checksums:
    • 03195476581a6853c45ebc0793d293313e1851604e428564dba3f5ee6014f344 fluxheim.spdx.json
    • 9b083173c102222252dddec9d43ac2128829fa4371977285d92d77d4b030a0a8 fluxheim.cyclonedx.json
  • Reproducible build:
    • 256ca588ad401e324ae731532a04551f60ab6471f64e597ce90fda562158e0b5
  • Full Build Container digests:
    • Wolfi: ghcr.io/valkyoth/fluxheim@sha256:40a541425ff37009073370f891037dc962865745f3565526697eb061ca4f1400
    • Alpine: ghcr.io/valkyoth/fluxheim@sha256:213ab2b5aff3cdb1e19d471bc39e657d5152c6d993da56ae4b651c2d0d2b3ce8
    • SUSE Micro: ghcr.io/valkyoth/fluxheim@sha256:03dc6dc3466b130e69f8985fbb5654417655d3cad73aaf71de1fbda7ea3a68d8
    • Debian: ghcr.io/valkyoth/fluxheim@sha256:412e24d97e00f9b0f8231819529f723588867d87aaac93dc209a56d7ccd774c8
  • Cache Build Container digests:
    • Wolfi: ghcr.io/valkyoth/fluxheim@sha256:b7c245afb163558708b9cd71aa5d792be7054dfc2e8f04c65139c44b01805c1e
    • Alpine: ghcr.io/valkyoth/fluxheim@sha256:853ce5a41f8b165e916a2b33e71a1b1f8f1653dffe5a6958ab13064c9b36038c
    • SUSE Micro: ghcr.io/valkyoth/fluxheim@sha256:44b1d3fe73448fae5a9108ea1eb8e70c8a68928127037fb2d15ffdafbfdeba9f
    • Debian: ghcr.io/valkyoth/fluxheim@sha256:5bdfb801028c0a6b822c7c0cccc3acecd31fb672e2b367f79ac993bb724f81b2
  • Proxy Build Container digests:
    • Wolfi: ghcr.io/valkyoth/fluxheim@sha256:175c733e57a5c20eadacc623cb9d94d1a4ae842edc8e3b874fddadc2f3c3cf55
    • Alpine: ghcr.io/valkyoth/fluxheim@sha256:05373051312e4be9612fa5ba0d448e698a05e4ecd075c5c494fecaca6dd09d74
    • SUSE Micro: ghcr.io/valkyoth/fluxheim@sha256:06ee4a0dcfbc88416cb6d23efab473e3b69e31c5c4dfe215149e9ba943830fc6
    • Debian: ghcr.io/valkyoth/fluxheim@sha256:a2e24457f72561fcf42598ef3297109202a167be2bd451148cb81a39ec4d2a35
  • PHP Build Container digests:
    • Wolfi: ghcr.io/valkyoth/fluxheim@sha256:1fdbc8f836d0636009bbe504916e313b956b855ba1031405677a90119421b64f
    • Alpine: ghcr.io/valkyoth/fluxheim@sha256:816ce07c40b106ac8da7a0a4447c4c45c93f2bf5d618960bbf17e84e26020b9d
    • SUSE Micro: ghcr.io/valkyoth/fluxheim@sha256:2b7cf15135ca6d660aaaec20f3ba657e98bb18f1a07095c3deb15dec797ea0fc
    • Debian: ghcr.io/valkyoth/fluxheim@sha256:0fa0e263f88fe8e5f750e90e1fa47f70b9a81446dba2666c95e6453281d6779f
  • Tag signature:
    • Good "git" signature for 1921261+eldryoth@users.noreply.github.com with ED25519 key SHA256:EoLRQ5k4J5pYz3UMFmkrV798gYFNkToGS2xEPvebqB4
Assets 8
Loading
0 Join discussion