Fluxheim 1.3.6

[eldryoth]

Fluxheim 1.3.6 Release Notes

Fluxheim 1.3.6 is the FIPS/ISO internal-crypto closure and compliance evidence
package release for the 1.3 line. It does not claim that Fluxheim is FIPS
certified, ISO/IEC 19790 certified, or Common Criteria certified. It tightens
what a FIPS/ISO-required config can enable so non-TLS cryptography is either
outside the boundary, externally evidenced, documented as non-secret, or
rejected, and it gives operators a repeatable evidence template for regulated
reviews.

Highlights

• FIPS/ISO-required configs now reject managed ACME. Use externally issued
  static certificates or an external renewal workflow until ACME account
  key generation, JWS account signing, EAB, outbound ACME HTTPS transport, and
  challenge certificate generation are provider-routed or separately evidenced.
• FIPS/ISO-required configs now allow the admin API in tls-openssl-fips and
  tls-rustls-fips builds because bearer-token HMAC is routed through OpenSSL
  FIPS or AWS-LC FIPS respectively. Non-FIPS builds still reject admin in
  FIPS/ISO-required configs.
• FIPS/ISO-required configs now reject local disk-cache encryption because the
  local path currently uses ring AES-GCM.
• FIPS/ISO-required configs warn when disk cache is enabled without
  encryption. This is allowed for operator-controlled policies, but cached
  response bodies are written at rest without a Fluxheim-managed encryption
  boundary. Operators can set require_disk_cache_encryption = true under
  [tls.fips] or [tls.iso19790] to make this a hard config error.
• OpenBao Transit cache encryption remains allowed as an external evidence
  boundary only through local numeric loopback HTTP. Operators must provide
  OpenBao module, platform, and deployment evidence. Remote or HTTPS OpenBao
  transport remains blocked until outbound TLS evidence is added.
• OTLP metrics/traces export is allowed only to numeric local http://
  loopback collectors in FIPS/ISO-required configs. localhost, remote OTLP,
  and HTTPS OTLP remain blocked until outbound TLS can be routed through the
  selected validated backend or separately evidenced.
• Request IDs and temporary object names are documented as non-secret
  operational identifiers rather than authentication tokens, key material, or
  SSPs.
• Added docs/compliance-evidence-template.md with release metadata, candidate
  TOE boundary, Security Target-style draft fields, operational-environment
  assumptions, cryptographic module evidence, validation-script identifiers,
  scanner output checklist, and vulnerability-analysis records.
• scripts/release_evidence.sh now emits a compliance evidence package section
  that points to the template and records the required follow-up fields.
• Runtime Pingora cache storage, tiered storage, cache locks, and cache
  predictors are reused for identical cache plans across authenticated reloads,
  reducing process-lifetime allocations required by Pingora's 'static cache
  API.
• Dynamic admin API JSON responses now serialize through serde_json::to_vec
  instead of hand-written format! response bodies, preserving existing schemas
  while reducing future JSON escaping risk.
• Admin bearer-token authorization avoids length-check short-circuiting,
  zeroizes the temporary candidate copy used for comparison, and aborts on
  impossible system-clock failures instead of falling back to epoch timestamps.
• Snapshot ID generation now aborts on system-clock failure rather than
  generating s0-... identifiers.
• Admin runtime/auth-throttle mutex poisoning now aborts instead of recovering
  potentially inconsistent state in debug/test builds, matching the production
  fail-closed model.
• Peer-fill concurrency counters now use checked arithmetic and refuse permits
  if a counter saturates.
• The RUSTSEC-2024-0437 suppression now has release-metadata enforcement so
  it must be reviewed when Pingora moves off Prometheus 0.13.4 or when the
  scheduled review date is reached.

Validation

The release adds config-validation tests that prove FIPS/ISO-required mode
accepts provider-backed admin auth, fails closed for managed ACME and local
cache encryption, and accepts OpenBao Transit cache encryption only through
local numeric loopback HTTP as an external cryptographic service boundary. The
OpenSSL and rustls FIPS validation scripts include matching provider-backed and
fail-closed fixtures for those internal-crypto gates, and the managed ACME
fixtures assert the specific ACME rejection reason instead of accepting any
non-zero config-tester exit.

Recommended local checks:

cargo test --locked --no-default-features --features profile-fips-openssl fips_required_
cargo test --locked --no-default-features --features profile-fips-rustls fips_required_
cargo test --locked fips_otlp_local_collector_exception_accepts_loopback_http_only

Operator Notes

This release makes strict FIPS/ISO-required configs more conservative. Builds
can still compile ACME, admin, cache, PHP-FPM, and telemetry features for normal
operation, but enabling [tls.fips] required = true or
[tls.iso19790] required = true rejects the incompatible runtime paths listed
above.

For regulated deployments, prefer static certificate files generated by an
approved external process, enable the admin API only in a provider-backed
OpenSSL FIPS or rustls/AWS-LC FIPS build, use no cache encryption or OpenBao
Transit with evidence, and send OTLP only to a numeric local collector until
outbound TLS evidence is added.

Use docs/compliance-evidence-template.md with scripts/release_evidence.sh
for the release evidence package. The Common Criteria-aligned sections are
evidence organization only; they are not a Protection Profile, evaluated
Security Target, EAL, or certification claim.

Checksums And Signatures

• Commit: 67a32c9dbb4e77380a8d46b07e7bc827bdc952e3
• 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:
  • 1e1d7cede7b147d9f2a30d9c992eaec07ef202302eac2f52917e9892c5f7f8f7 fluxheim-1.3.6.tar.gz
  • ef31837452bb1c67bdaf440ccc57bad08893393de00712b259442181cd0bf60a fluxheim-1.3.6.zip
• Binary checksums:
  • 251e5b947f96a746fc8711076978391062428ae22d48cb927fa6f080eece37b7 fluxheim-1.3.6-full-x86_64-linux.tar.gz
  • 24e5f10f0dca23ec5ecdfcf2e40914721e3e9a5df1dae7a9e5679adae6d61981 fluxheim-1.3.6-cache-x86_64-linux.tar.gz
  • 280029ee9371332c696c8f5e7a49d44ba2ff77eab5106aea628fb1c7357bd0cd fluxheim-1.3.6-proxy-x86_64-linux.tar.gz
  • 80f5807121cc86f7f92f27e25b9a94f10a7324822945e5b572de0bb5b83b1ce9 fluxheim-1.3.6-php-x86_64-linux.tar.gz
  • 36d35174f5d6967cd35e837370628bb57f22fa42dc581be875492df9fa0af654 fluxheim-1.3.6-config-tester-x86_64-linux.tar.gz
• SBOM checksums:
  • bc18778b81e4a5c2d9524d6bf6c373d0e8b0d244d0fd3695b724c7a8b067c92e fluxheim.spdx.json
  • b10c4218a25d88c44af26854aa5f9633698b78e15e225b8f8e06b55489cf8984 fluxheim.cyclonedx.json
• Reproducible build:
  • e61d8e7d7421bd579e9579bf0872a7dab031037fd8cfccfa89a60a7b488f4718
• Full Build Container digests:
  • Wolfi: ghcr.io/valkyoth/fluxheim@sha256:e523369054b4dd51cfda29a581d5da73885b40990588d01c1c46840f85867f63
  • Alpine: ghcr.io/valkyoth/fluxheim@sha256:950a56c705e10e2abca15348f2ee2bc0db957a1c1089659e5dff7f2745005a8f
  • SUSE Micro: ghcr.io/valkyoth/fluxheim@sha256:47474159d797afb13031dcbfb530aed21f825526b0277c8b1f92a1dc462e51bd
  • Debian: ghcr.io/valkyoth/fluxheim@sha256:8c4fdb75e2b9e3bc4a829d06c27919d16b29617443e522a90462313f86a103ae
• Cache Build Container digests:
  • Wolfi: ghcr.io/valkyoth/fluxheim@sha256:1499eca2a3758209b9c421eca629b18c09e094fa04bcbdff11574e78419304be
  • Alpine: ghcr.io/valkyoth/fluxheim@sha256:1d898eb8147642254b764292701ea6e508fb1318fd697a02a9a74c2826644f0a
  • SUSE Micro: ghcr.io/valkyoth/fluxheim@sha256:4c58bc7063271103b0abd3678a25ddb56b49290420f2cc98fb279a4b4831789a
  • Debian: ghcr.io/valkyoth/fluxheim@sha256:a2e3da8f46641bf890e728620238c421b9117234a1a769f7ae0de671cd408006
• Proxy Build Container digests:
  • Wolfi: ghcr.io/valkyoth/fluxheim@sha256:4a445a2a26b1a243bb45c7a181dba733561bdf95a1cad69f8fd8e623b125f36f
  • Alpine: ghcr.io/valkyoth/fluxheim@sha256:9190441122fc3b0129f055f0cf4defac1c34d9e0fb7620412b1ee626e5b4380d
  • SUSE Micro: ghcr.io/valkyoth/fluxheim@sha256:0607e9e610adacfa2fe2f13f3a36d3813cd793e8dee3d44190053a4d5dd01e22
  • Debian: ghcr.io/valkyoth/fluxheim@sha256:16c4816471eb3af9041e54ea362059d8e1ac63ddec19c27736b4c015ed4de881
• PHP Build Container digests:
  • Wolfi: ghcr.io/valkyoth/fluxheim@sha256:1e0362c733dde9a09aee310dc5a1d01a4db67d7740e5dd56c925945c7b33b4fd
  • Alpine: ghcr.io/valkyoth/fluxheim@sha256:93f65603b1a1daebbd53e62e90573e33be84b5dac53f268e4ae8ea7e184a0dd7
  • SUSE Micro: ghcr.io/valkyoth/fluxheim@sha256:18788f37761fd2563f3021ddae930301b19124e5597a55a1b13607a470d797e6
  • Debian: ghcr.io/valkyoth/fluxheim@sha256:70722053a200d0220107a5e6db0f33e82d71a1f655b5ab2f0faf350a4544238b
• Tag signature:
  • Good "git" signature for 1921261+eldryoth@users.noreply.github.com with ED25519 key SHA256:EoLRQ5k4J5pYz3UMFmkrV798gYFNkToGS2xEPvebqB4

---

This discussion was created from the release Fluxheim 1.3.6.