[coderdan]

Summary

Two fuzz crates' lockfiles were out of date, and nothing noticed. This PR regenerates them and adds a CI check so it cannot happen silently again.

Problem

Each packages/*/fuzz/ crate is its own Cargo workspace with its own Cargo.lock. When stack-auth and stack-kms moved to vitaminc 0.8, the two fuzz lockfiles that depend on them were not updated. They recorded only vitaminc 0.5.1, not the 0.8 crates the fuzz builds now need.

cargo-fuzz has no --locked flag. Without it, Cargo quietly fills in whatever a lockfile is missing, choosing the newest compatible versions, and carries on. So the fuzz regression job resolved vitaminc 0.8.x afresh on every run, built against whatever was newest that day (0.8.1, while the workspace pins 0.8.0), and passed. The job was green, but it was not building the versions we review and commit.

Checked: on next, cargo metadata --locked fails for both crates with cannot update the lock file … because --locked was passed. On main both pass.

Changes

• packages/stack-auth/fuzz/Cargo.lock, packages/stack-kms/fuzz/Cargo.lock: regenerated. Every crate the workspace Cargo.lock also pins is at the workspace's version, so the whole vitaminc 0.8 family is at 0.8.0, not the newer 0.8.1 a fresh resolve picks.
• .github/workflows/fuzz.yml: a new fuzz-lockfiles job runs cargo metadata --locked on every packages/*/fuzz/Cargo.toml, and reports a stale lockfile as an error annotation on that file. It is a check rather than a flag on the builds, the same split protect-ffi uses (--locked on the check, not the build). It runs on pull requests, on the nightly schedule (so staleness on the default branch fails a run too), and on manual dispatch.

Verification

• cargo metadata --locked passes for all three fuzz crates (stack-auth, stack-kms, stack-encrypt).
• pnpm run test:scripts: 83 files, 1446 tests passed. That suite includes the workflow structure checks (mise cache image, setup and paths-filter parity).

Not changed

The root workspace still carries two vitaminc versions, 0.5.1 and 0.8.0. Our crates use 0.8.0. 0.5.1 comes from cts-common 0.43.0, which is published from cipherstash/cipherstash-suite, and from zerokms-protocol through it. One version across the board needs a cts-common release on vitaminc 0.8 first.

https://claude.ai/code/session_01MrxG73fnX1p7oiizh3GRG5

[changeset-bot]

⚠️ No Changeset found

Latest commit: 320b488

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI; Enforced overrides: Organization
• Review profile: CHILL
• Plan: Advanced
• Run ID: f4d0c7c9-cc2d-4a1b-98c4-137a763ec593

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-31T01:39:12.031912Z	320b488	PR opened
🔒 Security Review	✅ Completed 2026-10-31T01:40:12.332257Z	320b488	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[github-actions]

Mutation testing (cargo-mutants, --in-diff, stack-auth + stack-encrypt)

No mutants were generated for the changed lines.

[cipherstash-agent]

Review attestation for 320b488: automated /code-review medium, with the findings cross-checked against the PR head and the existing PR feedback (company-skills:cross-check-review-findings).

Critical / blocking issues: none.

Findings: none. The review raised five candidate findings. None was confirmed as a defect at head, so none is posted as an inline comment.

• The unlocked fuzz builds and the check-only design are the stated, intentional approach in the PR description.
• The packages/*/fuzz/Cargo.toml glob fails loudly if it matches nothing, so it cannot pass silently.
• The regenerated lockfiles carry two vitaminc lines (0.5.1 and 0.8.0). The PR description already documents this, and I found no evidence it breaks the build.

Non-blocking notes:

• A new fuzz crate outside stack-auth, stack-kms and stack-encrypt would not trigger this workflow on pull_request (see the paths filter), though the glob in the new job would pick it up on the schedule.
• The changeset-bot warning is expected for a CI-only change.

---

Generated by Claude Code