feat(fips): FIPS 140-3 build variant (arc-fips)

[xe-nvdk]

Summary

Tier 2 defense-grade work, item 1 of 4: an optional arc-fips build for US defense/federal and other regulated environments requiring validated cryptography.

• FIPS is a build variant, not a version. Same source at the same version (26.06.2); built with -tags=duckdb_arrow,fips + GOFIPS140=v1.0.0 (the CMVP-certified Go Cryptographic Module snapshot), running GODEBUG=fips140=only (baked in). FIPS-ness lives in the artifact name (arc-fips-*, image :VERSION-fips), never the version string.
• Covers OSS + Enterprise — one arc-fips binary; Enterprise FIPS = arc-fips + license key.
• Standard build is unchanged (except the long-standing TLS 1.2 floor, now pinned explicitly).

What runs through the FIPS module

• Token hashing: bcrypt → PBKDF2-HMAC-SHA256 (stdlib crypto/pbkdf2). Legacy bcrypt/sha256 hashes verify in the default build; the fips build fails them closed with a "rotate this token" warning (bcrypt is not linked into the fips binary — CI enforces this via an import-graph check).
• HKDF: x/crypto/hkdf → stdlib crypto/hkdf (inside the FIPS boundary). Arg order preserved; a known-answer test pins the derived key byte-for-byte so a cluster split can't slip through.
• TLS: TLS 1.2 floor in both builds; fips build additionally restricts cipher suites + curves to the FIPS-approved set (drops X25519). Standard build keeps Go's defaults. MQTT refuses InsecureSkipVerify in the fips build. The fips API listener replaces Fiber's opaque ListenTLS so Arc owns the negotiated suites.
• Startup fail-closed: the fips binary refuses to start if not actually in FIPS mode; logs fips_mode in the banner.

Build & release

• make build-fips / test-fips / fips-check; Dockerfile FIPS=1 arg.
• release-build.yml: build-binaries matrix gains a variant dimension (standard/fips × amd64/arm64) → signed arc-fips-* binaries + bundles; SLSA provenance covers them; new docker-build-fips job pushes a cosign-signed :VERSION-fips image to GHCR + Docker Hub. CI verifies no x/crypto/bcrypt|hkdf in the fips build and that it boots with fips_mode=true.

CMVP framing (important)

The Go Cryptographic module is CMVP-certified (v1.0.0). Arc itself is not a CMVP-listed module — this is not a claim that "Arc is FIPS 140-3 validated." Docs and release notes state this precisely.

Operator cutover

Moving an existing deployment to arc-fips requires rotating API tokens once (existing bcrypt hashes fail closed; new tokens are PBKDF2). Documented in release notes + the FIPS guide.

Test plan

• go build + go test pass in both variants (-tags=duckdb_arrow and ...,fips)
• gofmt/go vet clean on changed files, both variants
• HKDF known-answer test confirms byte-identical key across the stdlib swap
• PBKDF2 round-trip + malformed-fails-closed + legacy fail-closed (fips) / legacy-verifies (default) tests
• make fips-check (import-graph) clean; standard build still pulls bcrypt (backward compat)
• Real arc-fips binary smoke-booted: fips_mode=true, reaches "Arc is ready!" (CGO + GOFIPS140 coexist)
• Internal review: config matrix + deep reviewer (3 findings fixed) + adversarial fix-check (caught & fixed a latent TLS-1.2-floor regression)
• Test release dry-run (workflow_dispatch test_mode=true) to verify arc-fips-* artifacts + :VERSION-fips image

Docs

Release notes (RELEASE_NOTES_2026.06.2.md), arc README.md, enterprise product-definition updated here. User-facing guide (configuration/fips.md) lands in the docs.basekick.net repo.

🤖 Generated with Claude Code

[xe-nvdk]

@gemini-code-assist please review

Focus areas for this FIPS 140-3 build-variant PR:

• Build-tag correctness: fips/!fips files in internal/fips/ and internal/auth/auth_hash_*.go — does the default build behave identically to before, and the fips build link no x/crypto/bcrypt?
• TLS posture: HardenTLSConfig applies a TLS 1.2 floor in both builds but FIPS ciphers/curves only in the fips build (standard build keeps Go defaults incl. X25519). Verify no behavior change for standard-build users beyond the pre-existing 1.2 floor.
• HKDF migration: stdlib crypto/hkdf.Key(hash, secret, salt, info, len) preserves the exact secret/salt order vs the old x/crypto/hkdf.New — a flip silently splits the cluster. KAT test pins the bytes.
• PBKDF2 token hashing: parser robustness (no panic/bypass on malformed $pbkdf2-sha256$ input), constant-time compare, and the legacy fail-closed semantics in the fips build.
• CI: the build-binaries variant matrix, docker-build-fips cosign signing, and the import-graph + runtime fips_mode verification steps.

[gemini-code-assist]

Code Review

This pull request introduces an optional FIPS 140-3 build variant (arc-fips) compiled against the CMVP-certified Go Cryptographic Module. Key changes include migrating API token hashing from bcrypt to PBKDF2-HMAC-SHA256, transitioning cluster replication key derivation to the standard library's crypto/hkdf, and enforcing FIPS-approved TLS configurations (cipher suites and curves) for the API, cluster, and MQTT paths. Feedback on the changes highlights a missing NextProtos configuration in the custom FIPS TLS listener, which disables HTTP/2 negotiation and could lead to performance regressions.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Code Review

This pull request introduces a FIPS 140-3 build variant (arc-fips) for Arc, migrating token hashing to PBKDF2, restricting TLS configurations to FIPS-approved primitives, and utilizing the standard library's crypto/hkdf. Feedback on these changes highlights a critical security issue where the deprecated CurvePreferences field is ignored in Go 1.23+, allowing non-approved curves like X25519 to persist; this must be updated to CurveIDs along with its associated tests. Additionally, the PBKDF2 verification logic should enforce upper bounds on iteration counts and salt/hash lengths to prevent potential CPU and memory denial-of-service attacks, and the fips-check Makefile target should be hardened to prevent silent success if the underlying go list command fails.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[xe-nvdk]

Addressed review round 2 (Gemini + CodeQL) in 14545a5. Two findings accepted and hardened, three declined with evidence.

✅ Accepted

PBKDF2 verify DoS (security-high) — internal/auth/auth.go + internal/cluster/raft/fsm.go

• Added an upfront pbkdf2MaxEncodedLen (128) length guard before any Atoi/base64.Decode. An adversarial check on the first fix showed the bounds validated semantic length only after decoding — a 100 MB base64 field decodes to ~78 MB before the len != expected check rejects it, and since verify is lazy on the persisted SQLite row it re-triggers on every matching auth. Now: bound input size first, then parse.
• iter ceiling (pbkdf2MaxIterations = 10_000_000) + salt/key length pins.
• validateTokenEntry now caps TokenHash (≤512) and TokenPrefix (≤256) so a rogue cluster-proposed entry never persists into the FSM/SQLite in the first place.
• Tests added: abusive iter, wrong-length salt, multi-MB hash all fail closed; FSM rejects an oversized hash.

Makefile fips-check masks go list failure (medium) — now captures stdout+stderr and checks the exit status; a compile/list failure fails the target instead of silently printing OK.

API listener ALPN (medium) — set NextProtos: ["http/1.1"].

❌ Declined (verified)

CurveIDs instead of CurvePreferences (security-high, ×3) — respectfully, this is incorrect for our toolchain. tls.Config.CurveIDs does not exist in Go 1.26 (unknown field CurveIDs in struct literal of type tls.Config — confirmed by compiling it). CurvePreferences is not deprecated/ignored: the Go 1.26 stdlib doc states "If empty, the default will be used... To disable it, set CurvePreferences explicitly." So the existing code correctly restricts curves (drops X25519) in the FIPS build. Adopting the suggestion would break the build.

NextProtos: ["h2", "http/1.1"] — declined the h2 part. Fiber's engine (fasthttp) is HTTP/1.1-only and Fiber's own ListenTLS sets no h2 ALPN, so advertising h2 would let a client negotiate a protocol the server can't speak. Set ["http/1.1"] instead.

CodeQL #235 (weak SHA256, auth_hash_legacy.go:29) — dismissed won't-fix. This is a pre-existing verify-only backward-compat path (was in auth.go before this PR, relocated unchanged into the !fips file); new tokens are PBKDF2 and the fips build removes the path entirely.

@gemini-code-assist please review

[gemini-code-assist]

Code Review

This pull request introduces an optional FIPS 140-3 build variant (arc-fips) compiled against the CMVP-certified Go Cryptographic Module. It updates the build system, centralizes FIPS posture and TLS hardening, migrates token hashing from bcrypt to standard library PBKDF2, and transitions replication key derivation to standard library HKDF. Feedback on the changes identifies two critical compilation errors in internal/auth/auth.go where the token string is passed directly to pbkdf2.Key instead of being converted to a byte slice.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[xe-nvdk]

Round 3 — both "critical compilation error" findings on pbkdf2.Key are declined: they're incorrect for our toolchain, and the suggested change would actually break the build.

This PR uses the stdlib crypto/pbkdf2 (Go 1.24+), whose signature is:

func Key(h func() hash.Hash, password string, salt []byte, iter, keyLength int) ([]byte, error)

The password argument is a string, so passing token directly is correct. This differs from the older golang.org/x/crypto/pbkdf2.Key, which took []byte — that appears to be the signature the suggestion is based on.

Compiler evidence (Go 1.26):

• Current code (pbkdf2.Key(sha256.New, token, salt, ...)) — compiles; the whole tree builds in both variants (go build ./cmd/... ./internal/... and -tags=fips).
• The suggested []byte(token) form — does not compile: cannot use []byte(token) (value of type []byte) as string value in argument to pbkdf2.Key.

CI on this PR builds arc and arc-fips for amd64+arm64 and runs the test suite, so a real compile error here would fail the run.

No change made for these two. (This is the same shape as the round-2 CurveIDs finding — a confident claim about a stdlib API signature that doesn't match Go 1.24+/1.26.) Everything from round 2 (PBKDF2 DoS bounds, ALPN, fips-check) remains as committed in 14545a5.