Skip to content

lint: add FIPS compliance tooling, linters, and deny.toml policy#35842

Draft
jasonhernandez wants to merge 7 commits intoMaterializeInc:mainfrom
jasonhernandez:jason/lint-openssl
Draft

lint: add FIPS compliance tooling, linters, and deny.toml policy#35842
jasonhernandez wants to merge 7 commits intoMaterializeInc:mainfrom
jasonhernandez:jason/lint-openssl

Conversation

@jasonhernandez
Copy link
Copy Markdown
Contributor

Summary

  • Add optional openssl usage linter (bin/lint-openssl)
  • Add container FIPS compliance auditor (bin/lint-fips-containers)
  • Ban non-FIPS crypto crates in deny.toml (sha2, hmac, subtle, ring, etc.)
  • Add openssl-to-rustls migration plan documentation
  • Add comprehensive FIPS 140-3 compliance report

Part 1/7 of the FIPS 140-3 compliance mode migration.

Test plan

  • cargo deny check licenses bans sources passes
  • ruff check + ruff format --check passes
  • Copyright headers present on all new files

🤖 Generated with Claude Code

jasonhernandez and others added 7 commits April 2, 2026 10:10
Add bin/lint-openssl to detect all openssl dependencies, feature flags,
and source imports across the workspace. This is the first step toward
migrating from openssl to rustls—it serves as a tracking tool for
migration progress and can later be promoted to a CI gate.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Add migration plan (doc/developer/openssl-to-rustls-migration.md) with
tiered breakdown of all 28 affected crates, dependency graph, replacement
crate mapping, and links to Linear issues (SEC-176 through SEC-200).

Include raw linter output snapshots (.txt and .json) as baseline for
tracking progress.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Replace all non-FIPS crypto crate recommendations (ring, sha2, hmac,
pbkdf2, subtle, rsa, ed25519-dalek, aes+cbc) with aws-lc-rs equivalents.
Add FIPS 140-3 strategy section, workspace fips feature flag (SEC-201),
and updated replacement crate mapping table.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Add [[bans.deny]] entries for crypto crates that are not FIPS 140-3
validated: sha2, hmac, subtle, ring, pbkdf2, ed25519-dalek, aes, cbc,
rsa. All new crypto code must use aws-lc-rs instead.

Existing workspace and third-party usage is allowed via wrappers, with
TODO comments to remove them as each crate is migrated to aws-lc-rs.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Add bin/lint-fips-containers to scan Dockerfiles for FIPS 140-3
compliance gaps: non-FIPS base images, crypto-relevant package
installations, and non-FIPS algorithms in cert generation scripts.

Distinguishes production images (must comply) from test/dev
(informational). Supports --strict and --json flags.

Current results: 8 production findings across 4 base images.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Covers all three compliance layers: Rust binaries (137 openssl findings
across 28 crates + sha2/hmac/subtle), container images (8 production
findings across 4 base images), and Kubernetes/Helm deployment (Ed25519,
image validation, external services, FIPS toggle).

Includes full issue inventory (SEC-176 through SEC-213), remediation
strategy, recommended execution order, and FIPS validation caveat.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 2, 2026

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

  • Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
  • Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
  • Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

  • The PR title is descriptive and will make sense in the git log.
  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant