Dependency Bump Review Process Improvements

[oxarbitrage]

Currently, the Zebra repository follows an informal process for reviewing dependency updates, which has led to recurring challenges. Here's a brief summary of how we got here:

Background

From the beginning, Zebra used the Dependabot plugin to automatically open pull requests whenever new dependency updates became available. However, since Zebra depends on many crates, this quickly became overwhelming, pull requests were being opened almost daily.

To reduce the noise, we:

• Switched Dependabot to check for updates weekly instead of daily.
• Grouped dependencies into hardcoded categories like prod, devops, etc.
• Eventually further reduced the update frequency to every two weeks, and most recently to once a month.
• Configured Dependabot to only update Cargo.lock for minor upgrades.

In parallel, we introduced cargo vet to help with dependency auditing and reviews. However, it hasn’t been fully adopted:

• We lack clear policies for dependency trust levels.
• In some cases, using cargo vet has been more cumbersome than reviewing updates manually.

While these adjustments have helped to some degree, they were intended as temporary fixes. We still lack a formalized, consistent process for reviewing and approving dependency updates.

Related Work

Some background on how we use cargo vet:

• build(deps): bump the prod group across 1 directory with 11 updates #8664

We could consider using the current Dependabot PR as a test case for process improvements:

• build(deps): bump the prod group across 1 directory with 11 updates #9611

Other related issues:

• Create a dependabot group of updates for cryptography dependencies #9181
• Add cargo vet to CI #8673

[conradoplg]

Some thoughts about this. I think these are the cases we need to handle:

1. There is a new major (breaking) release for a dependency. These require changing Cargo.toml. I'm not sure what dependabot is doing in this case, I have the impression that it tries to just update the lock file, but that won't work. First, we need to decide we if actually need to update or not (usually what happens is that libraries slowly adopt the new dependency, "bottom up", until the whole ecosystem updates, which is what usually happen for crates like rand and group). So since Zebra is fairly high-level it makes sense to wait until our dependencies that use that dependency update too.
2. There is a new non-breaking release for a dependency. The current approach of using dependabot to update the lockfile is fine
3. There is a new non-breaking release for a dependency, with a new functionality we need. Then we need to update the Cargo.toml file in the same PR that uses the new functionality.
4. There is a security advisory for the dependency. We need to update the Cargo.toml manually. GitHub warns us about those.
   Regardless of the above, we need to do the review of the dependencies, possibly with the help of cargo vet.

Note that in the release checklist we run cargo update (which applies all non-breaking updates to the lockfile) but we never review the dependencies in that case. Should we?

My suggestion:

• Disable dependabot altogether. Keep using cargo update to handle case 2, but incorporate cargo vet in the process. By delaying updating the dependencies, it will be more likely that some of them will be already vetted, and we could start vetting the rest as ECC does. The downside is that this may cause a big review workload before each release. @mpguerra suggested doing this after each release which seems fine since we do periodical releases anyway.
• Handle the other cases manually when required.

Also, there is a catch to case 3 above. We might introduce a requirement on a later version of a dependency without noticing, which might break crate users who are trying to use an older version of the dependency still allowed by Cargo.toml (recall that crates users aren't affected by the lockfile). To solve this we need to do something similar to what we did for FROST, but probably that is a separate issue.

[oxarbitrage]

Proposal: fix our dependency process

We stopped merging dependency updates: 13 consecutive prod-group PRs closed unmerged since Oct 2025 (#11139 now carries 42 updates), cargo-vet was disabled (#10930), and security response only works because yanked crates break CI. The root cause is PR size and ownership, not tooling — and dependabot only bumps manifest-declared deps anyway: a real cargo update today moves 179 crates, ~137 of them transitives dependabot will never propose.

Proposal — every Monday, three small automated PRs, each with an owner:

1. Train A — a cron runs cargo update (everything except consensus crates) and keeps one rolling PR open, amended weekly. 7-day cooling-off on fresh releases; a breaking crate gets pinned back while the rest merges; the PR body auto-lists deps held behind breaking lines (our majors dashboard). Opened via a minimal GitHub App token (required checks don't trigger on GITHUB_TOKEN pushes; same pattern as our integration-test trigger).
2. Train B — same cron, consensus crates only (zcash_*, orchard, halo2, rocksdb, secp256k1…), reviewed by the ZODL-lane owner. Compatible bumps only — breaking ZODL waves stay manual, as today.
3. Devops PR — dependabot's weekly actions group joins the routine; a broken action gets an ignore: entry so the rest merges.

Also: security fixes ship as same-day standalone PRs; the 11 pending majors become a tracked epic (1-2 per release); cargo-vet is formally retired (cargo-deny remains the gate); any of the three PRs older than 21 days → anyone may merge.

Ownership: I'll conduct for a 1-month pilot and report the real cost here (my guess: 15-30 min/week), then we decide together — keep, rotate, or adjust.

Validated: dry-run of the first train on current main — 179 crates, compiles clean, cargo-deny advisories pass; needs only a nix pin + 2 deny.toml skips. Setup is ~2-3 days (workflow, App, pre-work, docs, and the ECC→ZODL rename in our dep tooling) — I can prepare it all as ready-to-review PRs.

Questions: (a) objections to the train design? (b) objections to retiring cargo-vet? (c) OK with the 1-month pilot? (d) majors at 1-2 per release?

If no blocking objections in a week I'll start with the pre-work PR. Meanwhile: #11077 is mergeable today (blocked only on review — its red check is a non-required dependabot-secrets artifact); we could land that one right away.

[mpguerra]

We used to get weekly dependabot updates and that was too much. What are the trade-offs if we do this monthly instead of weekly?