chore(supply-chain): trust dtolnay, whom the imported peers trust, and pre-exempt the rest (LAB-6649)

[27Bslash6]

cargo vet fails on every dependency update, because each update brings in versions that no imported audit or version-pinned exemption covers yet. This change lets releases by a publisher the imported peers already trust pass with no per-version entry. It also pre-exempts the remaining crates in the pending minor/patch update.

What changes

Trust David Tolnay (dtolnay) for his crates. For the failing serde, serde_core, serde_derive, syn, thiserror and thiserror-impl releases, cargo vet reports that the imported isrg, mozilla and bytecode-alliance feeds trust him, and suggests cargo vet trust --all dtolnay. That is trust in the publisher, not per crate. The peers' own per-crate entries for him have lapsed for some of these crates (thiserror, thiserror-impl, itoa, serde_bytes), while others, such as bytecode-alliance's for syn, run to 2027. The existing [[trusted]] entries follow the same rule for other publishers.

The command records safe-to-deploy trust for every crate in the graph that he alone publishes. That is the six above plus anyhow, itoa, prettyplease, serde_bytes, serde_json and unicode-ident, which until now passed only on version-pinned exemptions. The nine exemptions this makes redundant are removed. The new entries end 2027-05-30, the same date as the existing [[trusted]] entries, so all of them renew together.

Pre-exempt the rest of the pending update. These crates have no peer-trusted publisher and no imported audit for the new version:

Crate	Version	Why
xxhash-rust	0.8.18	new release
zeroize	1.9.0	new release
zeroize_derive	1.5.0	new release
cbindgen	0.29.4	new release
getrandom	0.3.4	already in the lock at safe-to-run as a dev dependency; cbindgen 0.29.4 moves tempfile, a build dependency, onto it
r-efi	5.3.0	same path as getrandom 0.3.4; the existing exemption is raised from safe-to-run to safe-to-deploy

cbindgen 0.29.4, xxhash-rust 0.8.18, zeroize 1.9.0 and zeroize_derive 1.5.0 are not in this lock yet, and this lock does not need the r-efi raise yet. So cargo vet warns about them, and cargo vet prune would remove the four and lower r-efi back to safe-to-run. Don't prune until the update lands.

getrandom 0.3.4 is already in this lock, and prune keeps its exemption. Together with the imported isrg and bytecode-alliance delta audits, it now also vets getrandom 0.4.2.

imports.lock is the store as cargo vet trust rewrote it: publisher records for the newly trusted versions and the peers' current audits.

Keep a human on serde_json updates (renovate.json). serde_json is a dev-dependency, and the inherited rust-dev-deps rule automerges dev-dependency updates once checks pass. Until now the vet check went red on every new serde_json version, which kept those updates from automerging. With dtolnay trusted, a serde_json release, and the serde_core it resolves (a runtime dependency), would otherwise reach main with no human review. The new rule sets automerge: false for serde_json. Renovate automerges a group only when every update in it automerges, so a rust-dev-deps group that carries a serde_json update waits for a human too. serde_json is the only direct dev-dependency among the trusted crates. The others arrive through the non-major group or lock-file maintenance, and neither automerges.

No criteria are relaxed, and the workflow is unchanged.

Verification

This was checked with cargo-vet 0.10.2, the version CI installs. It was run as plain cargo vet, not --locked, as CI runs it. The update was applied locally with cargo update -p <crate> --precise <ver> for thiserror 2.0.21, serde 1.0.229, xxhash-rust 0.8.18, zeroize 1.9.0 and cbindgen 0.29.4:

• This branch's store: Vetting Succeeded (75 fully audited, 5 partially audited, 84 exempted).
• main's store, same lock: Vetting Failed! with 12 unvetted (the six dtolnay crates plus the six in the table).
• cargo vet explain-audit on each of the 12 shows the intended path: a trusted entry (published by dtolnay) or the local exemption.
• The gate still fails on an unvetted version. The same lock with xxhash-rust 0.8.17 fails: xxhash-rust:0.8.17 missing ["safe-to-deploy"].
• On this branch's own lock, cargo vet and cargo vet --locked both pass (91 fully audited, 5 partially audited, 87 exempted).

What still needs a hand-written entry

A crate without a peer-trusted publisher still needs an entry on each new version, unless an imported feed audits the delta first. The pinned exemptions above give such a delta a base to chain from:

• xxhash-rust and cbindgen always do: no imported feed audits them at safe-to-deploy.
• zeroize, zeroize_derive, getrandom and r-efi do only when no feed has audited the delta yet.

The dtolnay entries need renewing before 2027-05-30, along with the existing trust entries. They also do not cover a release published through a trusted-publishing identity instead of his user account.

Closes LAB-6649

Summary

This PR adjusts supply-chain trust configuration for crates published by David Tolnay (dtolnay) and adds a Renovate safeguard for serde_json.

Changes

supply-chain/audits.toml

• Shortens the trust expiry for all dtolnay-published crates (user-id 3618) from 2027-09-30 to 2027-05-30, matching the end date already used by other trusted entries in the file.
• Affected [[trusted.*]] entries include serde, serde_bytes, serde_core, serde_derive, serde_json, syn, thiserror, thiserror-impl, unicode-ident, and several others earlier in the file.
• Criteria (safe-to-deploy) and start dates are unchanged.

renovate.json

• Adds a package rule for the cargo manager that sets automerge: false for serde_json.
• Rationale, as stated in the rule description: because the publisher is trusted in audits.toml, cargo vet accepts new serde_json releases without per-version review. serde_json also resolves serde_core, which is a runtime dependency. Every serde_json update therefore requires a manual merge.

Impact

• Trust for dtolnay crates expires four months earlier, so it must be renewed sooner.
• serde_json updates are no longer merged automatically. This keeps human oversight on a runtime-relevant dependency that cargo vet would otherwise pass unreviewed.
• No source code or public Rust APIs are modified.

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 36 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository: cachekit-io/cachekit-core/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: d17a3002-2498-4d68-9248-0d028aaad8fe

📥 Commits

Reviewing files that changed from the base of the PR and between f68ca10 and 12d0760.

⛔ Files ignored due to path filters (1)

• supply-chain/imports.lock is excluded by !**/*.lock

📒 Files selected for processing (3)

• renovate.json
• supply-chain/audits.toml
• supply-chain/config.toml

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[kodus-27b]

Code Review Completed! 🔥

The code review was successfully completed based on your current configurations.

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the `@kody start-review` command at the root of your PR.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Providing Context (Files & MCPs)

Add these hints in your PR description (or a comment) to unlock deeper checks:

• Ticket / Acceptance Criteria: `Refs: ABC-123` (Linear/Jira/Asana/ClickUp/Trello) or a direct ticket link.
• Bugfix Validation: a Sentry/Datadog/Bugsnag event link (or paste the stack trace/error message).
• Endpoint Risk: mention the route (e.g., `POST /api/payments`) or controller/action name.
• Attach a repo file as context: use an explicit marker like `@file:docs/guide.mdx#L10-L50` (replace with your real path).
• API Contract Docs: include `@file:openapi.yaml` or `@file:swagger.json` when changing routes/schemas.
• Definition of Done / Standards: include `@file:DOD.md` or `@file:CONTRIBUTING.md` if your repo has them.
• Design System Source of Truth: include `@file:ui/index.ts` (replace with your DS entrypoint path).
• Feature Flags: include the flag key/name and `@file:flags.ts` / `@file:config.json` (and optionally the PostHog flag name).
• Edge/CDN Rules: link the Cloudflare rule/zone or describe the intended redirect/header behavior.
• Attach an MCP tool output: use `@mcp<provider|tool>` (replace with an installed MCP provider + tool, e.g., `@mcp<sentry|events.search>`).

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

[kodus-27b]

Code Review Completed! 🔥

The code review was successfully completed based on your current configurations.

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the `@kody start-review` command at the root of your PR.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Providing Context (Files & MCPs)

Add these hints in your PR description (or a comment) to unlock deeper checks:

• Ticket / Acceptance Criteria: `Refs: ABC-123` (Linear/Jira/Asana/ClickUp/Trello) or a direct ticket link.
• Bugfix Validation: a Sentry/Datadog/Bugsnag event link (or paste the stack trace/error message).
• Endpoint Risk: mention the route (e.g., `POST /api/payments`) or controller/action name.
• Attach a repo file as context: use an explicit marker like `@file:docs/guide.mdx#L10-L50` (replace with your real path).
• API Contract Docs: include `@file:openapi.yaml` or `@file:swagger.json` when changing routes/schemas.
• Definition of Done / Standards: include `@file:DOD.md` or `@file:CONTRIBUTING.md` if your repo has them.
• Design System Source of Truth: include `@file:ui/index.ts` (replace with your DS entrypoint path).
• Feature Flags: include the flag key/name and `@file:flags.ts` / `@file:config.json` (and optionally the PostHog flag name).
• Edge/CDN Rules: link the Cloudflare rule/zone or describe the intended redirect/header behavior.
• Attach an MCP tool output: use `@mcp<provider|tool>` (replace with an installed MCP provider + tool, e.g., `@mcp<sentry|events.search>`).

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.