Harden release registration and binary hash policy

[anupsv]

Summary

This PR hardens the pre-existing release/binary-hash trust path before the verifier work:

• fail closed when a known-good binary hash policy is configured but provider registration/challenge omits a usable attested binary hash
• normalize and validate release metadata before storing it
• verify release artifacts by downloading the configured R2 bundle, checking bundle hash, and checking the bundled bin/darkbloom hash
• use constant-time release-key comparison and reject malformed release payloads
• add regression coverage for release registration and provider binary-hash policy behavior

Validation

• go test ./internal/api

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
d-inference	Ready	Preview	Apr 30, 2026 1:26pm
d-inference-console-ui-dev	Ready	Preview	Apr 30, 2026 1:26pm
d-inference-landing	Ready	Preview	Apr 30, 2026 1:26pm

[hankbobtheresearchoor]

Hermes Agent Review

Verdict: Minor suggestions (solid security hardening, a few gaps to address)

✅ Looks Good

• Fail-closed binary hash policy — providers now rejected when policy is configured but hash is missing or unsigned. This is the right call. Previously resp.BinaryHash != "" && len(s.knownBinaryHashes) > 0 was open-mode-adjacent.
• Constant-time release key comparison via subtle.ConstantTimeCompare — fixes the timing leak in the old token != s.releaseKey string comparison.
• Release artifact verification — downloading the R2 bundle, verifying bundle_hash, extracting bin/darkbloom, and verifying binary_hash before storing is excellent trust-on-first-use hardening. Prevents a compromised release key alone from whitelisting arbitrary binaries.
• URL origin validation — off-origin URLs, HTTP origins, credentialed URLs all rejected. Redirect following disabled via CheckRedirect: return ErrUseLastResponse. Solid.
• Path traversal protection in cleanReleaseTarPath — .. components and absolute paths rejected.
• Non-regular file rejection — symlinks for bin/darkbloom rejected. TypeRegA accepted for legacy compat.
• Strict JSON decoding — DisallowUnknownFields() prevents store-only fields like active/created_at from being injected.
• Hash normalization — normalizeSHA256Hex ensures lowercase, validates length and hex encoding before comparison.
• MaxBytesReader on request body, bundle size limits (2GiB), binary size limits (512MiB).
• Attestation cross-check — challenge binary hash must match registration attestation hash. Prevents hash rotation after registration.
• Good test coverage — 10+ new tests covering hash mismatches, oversized binaries, redirects, unsafe paths, symlinks, off-origin URLs, credentialed URLs, missing hashes, unsigned hashes.

⚠️ Warnings

1. verifyReleaseArtifact writes to disk — os.CreateTemp("", "darkbloom-release-*.tar.gz") writes the entire bundle to a temp file before verifying. For a 2GiB max bundle, this could fill /tmp under concurrent release registrations. Consider streaming verification: hash while downloading, then stream the gzip/tar without materializing to disk (you already hash while writing via MultiWriter, so the temp file is only needed for the Seek(0) to re-read for tar extraction — could use io.TeeReader + bytes.Buffer for the hash portion, or restructure to avoid the seek).

2. Bundle download has no TLS pinning — the coordinator trusts the system CA pool when downloading from R2. If R2 CDN is compromised or MITM'd at the CA level, a malicious bundle could be served. Consider pinning the expected R2 certificate or at least validating the TLS certificate hostname matches the configured CDN URL. (Low priority given R2's CDN architecture, but worth noting for defense-in-depth.)

3. SyncBinaryHashes marks policy as configured when any active release exists — even a release with an empty/invalid BinaryHash (which gets logged and skipped) will set releaseBinaryHashPolicyConfigured = true. This means adding a single bad release record could lock out all providers. Consider only setting policyConfigured = true when at least one valid hash is actually added to the set.

💡 Suggestions

1. maxReleaseArtifactBytes = 2 << 30 — this is 2 * (1 << 30) = 2GiB, which is correct, but 2 << 30 is an unusual way to write it. 2 * 1024 * 1024 * 1024 or 2 << 30 are both fine, but a comment clarifying the intent would help future readers.

2. releaseVersionPattern allows prerelease suffixes — ^[0-9]+\.[0-9]+\.[0-9]+(?:[-+][0-9A-Za-z.-]+)?$ accepts 1.0.0-+foo..bar--. Consider tightening to a proper semver pattern if that's the intent.

3. eigeninference-bundle-macos-arm64.tar.gz in expectedReleaseArtifactURL — hardcoded the old name. If PR fix: Rename all EigenInference references to Darkbloom #98 (rename to Darkbloom) merges, this path will need updating. Consider making the bundle name prefix configurable or derived from a constant.

4. Missing test: concurrent release registrations — the temp file + disk I/O path could race under concurrent POST /v1/releases. Worth a stress test.

---

Reviewed by Hermes Agent (hankbob)

[Gajesh2007]

@codex go ahead review the code my boy