build(l1,l2): resolve Cargo.lock updates under a 14-day publish-age cooldown

[pablodeymo]

Motivation

Ports Commit-Boost/commit-boost-client#492 (also done for ethlambda in lambdaclass/ethlambda#607). Cargo's unstable min-publish-age (rust-lang/cargo#17009) lets the resolver skip crate versions published less than N days ago, a cooldown against freshly compromised releases. This enables it at 14 days, routes make update-cargo-lock through a pinned nightly so every lockfile in the repo is resolved under the policy, and adds a CI check that fails when a lockfile pins a crate younger than the window.

Description

• .cargo/config.toml: [unstable] min-publish-age = true, [registry] global-min-publish-age = "14 days". Stable 1.93 ignores both tables silently, so locked builds and make check-cargo-lock are unaffected. Run from the repo root, the same file governs the 12 nested workspaces.
• Makefile: update-cargo-lock runs cargo +nightly-2026-06-21 -Z min-publish-age tree for each manifest via a CARGO_RESOLVE variable; the target installs the toolchain on first use. New cooldown-check re-resolves each committed lockfile under the cooldown with cargo update --dry-run and fails if any pin is younger than the window. Only downgrades annotated with a publish date count: downgrades for other reasons (MSRV, tightened requirements) carry no such note and would otherwise be false positives.
• .github/workflows/pr-main_l1.yaml: new cooldown-check job running make cooldown-check, gated like check-cargo-locks and folded into the required Integration Test aggregate.
• CONTRIBUTING.md: tells contributors to refresh lockfiles with make update-cargo-lock rather than a plain cargo update, which resolves on stable and bypasses the cooldown.

Root workspace limitation. A full cargo update of the root workspace fails independently of this change (openvm git deps pin p3-baby-bear =0.4.1 and =0.4.3), which is why lockfiles are refreshed with cargo tree. The check therefore only warns for the root lockfile and gates the eleven nested workspaces. Git dependencies have no publish age and are not covered.

Lockfile changes. The four stateless-validator lockfiles pinned crc32fast 1.5.1, log 0.4.34, rand 0.8.8, syn 3.0.4 and uuid 1.25.0, all published less than 14 days before the ERE v0.16.2 upgrade locked them, so the new job failed on each. They are moved to the highest version the cooldown allows (1.5.0, 0.4.33, 0.8.7, 3.0.3, 1.24.1) with a targeted cargo update -p on the pinned nightly; nothing else in those lockfiles changes, and all five are transitive patch-level dependencies of the guest programs. Guest lockfiles pin the published ELF/VK bytes, so this changes them for the next stateless-validator release.

How to test

make cooldown-check         # root warns (see above), the 11 nested workspaces pass
make update-cargo-lock      # all 13 manifests resolve; git status shows no Cargo.lock change
make check-cargo-lock       # stable, passes

Verified in a scratch crate depending on smallvec = "1": the nightly resolver picks 1.15.2 and prints available: v1.16.0, published 3 days ago; stable picks 1.16.0; a --precise 1.16.0 is refused.

[github-actions]

⚠️ Known Issues — intentionally skipped tests

Source: docs/known_issues.md

rpc-compat log-bearing cases excluded

Where: KNOWN_EXCLUDED_TESTS in .github/scripts/check-hive-results.sh counts out
eight hive rpc-compat cases — the four eth_getLogs cases, eth_getBlockReceipts/get-block-receipts-latest,
and three eth_getTransactionReceipt cases. They are exactly the cases whose recorded
response contains at least one log object; every case with an empty log array still runs.
Note this leaves eth_getLogs with no rpc-compat coverage at all, since all four of its
cases are in the set.

Why: ethrex populates blockTimestamp on log objects, as geth, besu, nethermind, reth
and erigon all do. hive's rpc-compat compares responses byte-exactly (jsondiff.FullMatch;
the lenient checkJSONStructure path applies only to cases upstream marks speconly), and
the corpus is pinned to execution-apis d08382ae (2025-02-10), whose recordings predate the
field — it entered the schema in execution-apis#639 and the fixtures in #846 (2026-07-22).
So the extra key cannot match, and this is a property of the pin rather than of the response.

The pin cannot move, and this is not temporary. The pin sits one commit before
execution-apis#627, which moved the test chain to a pre-merge genesis: the current corpus has
~36 proof-of-work blocks before its terminal total difficulty. ethrex does not support
pre-merge chains and will not, so importing that chain.rlp fails at block 1 —
validate_block_header has no pre-London base-fee path. Every revision carrying
blockTimestamp in its fixtures also carries that chain, so there is no revision that
satisfies both. Nor can the corpus be patched locally: rpc-compat's Dockerfile clones
ethereum/execution-apis by hard-coded URL, so the branch buildarg cannot point at a fork.

Coverage: the field itself is pinned by
block_timestamp_is_on_the_log_and_not_on_the_receipt in
crates/networking/rpc/types/receipt.rs, which asserts it is present on each log and absent
from the receipt level.

Removal: delete the entries if ethrex ever gains pre-merge chain import, or if upstream
marks these cases speconly so they are type-checked instead of compared byte-for-byte.

---

The stateless schema id does not identify the encoding

Where: STATELESS_INPUT_SCHEMA_ID in crates/common/types/stateless_ssz.rs.

Upstream keeps the stateless input schema id at 0x1501
(fork_index 0x15 << 8 | revision 0x01) across incompatible body changes. Three
encodings have now shipped under it: tests-zkevm@v0.6.2, then #3248 + #3278,
then #3356, which moved state, codes and public_keys from SszList to
ProgressiveList. ethrex speaks the last one.

The consequence is that the 2-byte prefix cannot be used to detect a stale or
mismatched bundle. A wrong-dialect input is accepted by the id check and then
fails later — in SSZ decode, or on a root that does not match — rather than being
rejected up front for what it is. only_amsterdam_schema_id_decodes therefore
proves less than its name suggests.

Worth raising upstream: a revision field that does not move across a body change
provides no version negotiation at all.

---

ZisK guest program hash changes with the unsync_cell gate

Where: crates/common/types/block.rs, transaction.rs.

The gate on the single-threaded unsync_cell::OnceCell moved from
all(feature = "eip-8025", target_arch = "riscv64") to
all(feature = "zisk", target_arch = "riscv64") when the eip-8025 feature was removed.

The guest ELFs were previously built --features "<zkvm>-build-elf,ci", which never enabled
eip-8025, so they compiled the atomic once_cell variant. bin/zisk/Cargo.toml does enable
ethrex-common/zisk, so the ZisK guest now compiles the unsafe impl Sync cell instead.
That changes the ELF bytes and therefore the program hash and verification key.

This is intended (the guest is single-threaded, so the unsync cell is sound and cheaper), but it
is a VK change rather than a no-op refactor, and the diffstat presents it as a file rename
(eip8025_cell.rs → unsync_cell.rs). Anyone pinning a ZisK VK across this change must
re-register it. The stateless-validator crate now forwards ethrex-common/zisk from its own
zisk feature so the two ZisK guests do not disagree on the cell type.

---

Release signing key is an unprotected repository secret

Where: .github/workflows/tag_release.yaml.

MINISIGN_SECRET_KEY is a plain repository secret. There is no environment: on
finalize-release or dry-run-release-assets, and gh api repos/lambdaclass/ethrex/rulesets
shows only branch-targeted rulesets, so the github.ref_type == 'tag' condition is a workflow
check rather than an enforced boundary: anyone who can push a tag can reach the signing key.

This is a repository-settings change, not a code change, so it is recorded here rather than
fixed in the tree. Recommended:

1. Move MINISIGN_SECRET_KEY / MINISIGN_PASSWORD into a GitHub Environment with required
   reviewers, and add environment: to the two jobs that sign.
2. Add a ruleset targeting refs/tags/v* restricting who may create release tags.

Until then, the compromise of that key is silent and durable: signatures would still verify
against the committed .github/minisign.pub.

[github-actions]

🤖 Kimi Code Review

I'll review this PR which implements a supply-chain security measure using Cargo's unstable min-publish-age feature.

Overall Assessment

This is a well-constructed supply-chain hardening PR. The core idea—using Cargo's nightly resolver to exclude freshly-published crate versions—is sound. However, there are several issues with the implementation that need addressing.

---

Issues Found

1. Nightly toolchain date is in the future — Makefile:270

RESOLVER_TOOLCHAIN := nightly-2026-06-21

Critical: This date is in the future (June 21, 2026). rustup toolchain install will fail or behave unpredictably when run today. The > /dev/null 2>&1 suppression on line 273 hides this failure.

Fix: Use a current or past nightly that actually exists, e.g., nightly-2025-01-15 or similar. Verify the exact date against rustup components history.

---

2. Silent failure on toolchain install — Makefile:273

rustup toolchain install $(RESOLVER_TOOLCHAIN) --profile minimal > /dev/null 2>&1

Problem: Output suppression with 2>&1 means if the install fails (e.g., bad date, network issue, rustup not present), the Makefile continues and subsequent cargo +$(RESOLVER_TOOLCHAIN) invocations will fail with potentially confusing errors.

Fix: Remove suppression or use set -e semantics properly. At minimum:

rustup toolchain install $(RESOLVER_TOOLCHAIN) --profile minimal || { echo "Failed to install $(RESOLVER_TOOLCHAIN)"; exit 1; }

---

3. cargo tree doesn't update lockfiles — Makefile:275-289

Critical functional issue: cargo tree with --manifest-path does not update Cargo.lock files. From Cargo docs:

cargo tree — Display a tree visualization of a dependency graph

The previous implementation used cargo tree (likely relying on side effects from Cargo's internal resolution), but this is fragile and not guaranteed to write lockfiles. The -Z min-publish-age flag affects resolver behavior, but cargo tree alone doesn't persist results.

Verification needed: Does this actually write Cargo.lock changes? If the intent is to update lockfiles, cargo update or cargo generate-lockfile should be used instead, possibly with --workspace or explicit manifest paths.

---

4. Inconsistent manifest path handling for workspace roots — Makefile:285-289

$(CARGO_RESOLVE) --manifest-path tooling/zkevm_bench/Cargo.toml
$(CARGO_RESOLVE) --manifest-path tooling/Cargo.toml
$(CARGO_RESOLVE) --manifest-path tooling/ef_tests/state/Cargo.toml

Problem: tooling/Cargo.toml is a workspace root. Running cargo tree --manifest-path on a workspace root without -p <package> or --workspace may not resolve all member lockfiles. If members have their own Cargo.lock (which they appear to, based on the previous target's extensive list), this may miss them.

Suggestion: Verify whether tooling/Cargo.toml's workspace members have separate lockfiles that need individual updates.

---

5. Missing cargo update or lockfile generation step — Makefile:275-289

The target is named update-cargo-lock but uses cargo tree. If the goal is to refresh lockfiles under the new resolver policy, the implementation should likely be:

$(CARGO_RESOLVE) --manifest-path <path> -- -Z unstable-options generate-lockfile  # or similar

Or explicitly:

cargo +$(RESOLVER_TOOLCHAIN) -Z min-publish-age update --manifest-path <path>

---

6. Environment variable escape hatch documentation mismatch — CONTRIBUTING.md:13 / Makefile:269

CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow

vs. Makefile comment:

# CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow make update-cargo-lock

Issue: The env var name doesn't match Cargo's documented unstable feature. The actual Cargo env var for this would likely be CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSION (for a different feature) or similar. For min-publish-age, the override mechanism needs verification.

Looking at Cargo's source, the actual env var to bypass might differ. The PR should cite the exact Cargo documentation or source reference for this env var name.

---

7. [unstable] table placement in .cargo/config.toml — .cargo/config.toml:11-12

[unstable]
min-publish-age = true

Note: This is correct per Cargo's config format. However, this makes the entire .cargo/config.toml require nightly Cargo to parse without warnings for any operation that reads this config. The [build] section above is stable, but the [unstable] table may cause stable Cargo to emit warnings or errors in some contexts.

Verification: Test that cargo +stable build works without issues when this config is present. Stable Cargo should ignore [unstable] silently, but this is worth confirming.

---

8. Missing lockfile verification in check-cargo-lock — Makefile:291-292

check-cargo-lock: ## 🔍 Check Cargo.lock files are up to date
	cargo metadata --locked > /dev/null

Problem: This only checks the workspace root Cargo.lock. The update-cargo-lock target updates ~13 separate manifest paths. The check target doesn't verify those sub-manifest lockfiles are up to date.

Fix: Add --manifest-path checks for all the same paths, or use a loop:

check-cargo-lock: ## 🔍 Check Cargo.lock files are up to date
	cargo metadata --locked > /dev/null
	@for manifest in $(MANIFESTS); do \
		cargo metadata --manifest-path $$manifest --locked > /dev/null || exit 1; \
	done

---

Minor Issues

9. Comment typo / unclear phrasing — Makefile:264

# Stable cargo ignores these tables silently, so builds from the committed
# Cargo.lock files are unaffected; `make update-cargo-lock` resolves under the
# policy.

The .cargo/config.toml comment says "Stable cargo ignores these tables silently" — this is accurate for [unstable] and [registry] with global-min-publish-age.

---

10. Date format in toolchain specification

nightly-YYYY-MM-DD format is correct. However, the specific date should be pinned to a known-good nightly where min-publish-age is functional. Without verification, this is a maintenance risk.

---

Recommendations

Priority	Item	Action
Critical	1	Fix future toolchain date
Critical	3	Verify cargo tree actually updates lockfiles; switch to cargo update if not
High	2	Remove silent failure on rustup install
High	8	Extend check-cargo-lock to cover all manifests
Medium	6	Verify env var name for bypass
Medium	4	Verify workspace root resolution behavior

---

Correctness of Core Mechanism

The min-publish-age feature itself (.cargo/config.toml:11-15) is correctly configured per the tracking issue:

[unstable]
min-publish-age = true

[registry]
global-min-publish-age = "14 days"

The "14 days" format matches Cargo's expected duration parsing. This part is correct, assuming the nightly toolchain exists and the feature is implemented in that nightly.

---

Summary

The PR's security intent is valid and well-documented, but the toolchain date is in the future (Item 1), which is a blocking issue. The use of cargo tree for lockfile updates (Item 3) needs verification as it may not achieve the stated goal. The silent failure mode (Item 2) and incomplete lockfile checking (Item 8) are additional concerns that should be addressed before merge.

---

Automated review by Kimi (Moonshot AI) · kimi-k2.6 · custom prompt

[github-actions]

🤖 Codex Code Review

Findings

1. The new 14-day dependency cooldown is bypassable because it is not enforced anywhere in CI; it is only applied if a contributor voluntarily uses make update-cargo-lock. Makefile explicitly says stable resolution paths are “NOT covered”, and the required CI check still only runs make check-cargo-lock on stable via cargo metadata --locked in .github/workflows/pr-main_l1.yaml. That means a lockfile produced by plain cargo update or with CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow will still pass CI as long as it is internally consistent. For a supply-chain control, this is a real gap; I would add a CI validation step that enforces the cooldown policy rather than documenting it.

2. Makefile hides all output from rustup toolchain install $(RESOLVER_TOOLCHAIN). If the pinned nightly is unavailable or installation fails, the target now fails with poor diagnostics even though this is the documented recovery path for lockfile drift. Keeping stderr visible would make this much easier to debug.

No EVM, consensus, trie, gas-accounting, or RLP logic is touched here; the review concern is the effectiveness of the new supply-chain policy rather than runtime blockchain behavior.

---

Automated review by OpenAI Codex · gpt-5.4 · custom prompt

[github-actions]

🤖 Claude Code Review

Review: Supply-chain cooldown for Cargo dependency resolution (PR 7258)

This is a build-tooling / CI-adjacent change (.cargo/config.toml, Makefile, CONTRIBUTING.md) with no impact on consensus logic, EVM execution, RLP, or state trie code — so most of the Ethereum-specific review checklist doesn't apply here. The design (nightly-gated -Z min-publish-age, stable cargo unaffected, no lockfile churn) is sound and the PR description shows it was manually verified. A few concerns worth addressing:

1. The cooldown is not enforced by CI — only by convention

check-cargo-lock (Makefile, unchanged) verifies the lockfile is internally consistent with the manifests via cargo metadata --locked; it has no way to verify that the currently-locked versions actually satisfy the 14-day cooldown. Nothing stops a contributor (or a future automated dependency-bump PR/bot) from running a plain cargo update/cargo add on stable — which silently bypasses the cooldown — and committing the result; check-cargo-lock would still pass. Since the entire point of this feature is supply-chain protection, this means the guarantee is purely social/documentation-based (CONTRIBUTING.md), not verifiable in CI. Worth calling out explicitly as a known limitation (it is implicitly acknowledged in the PR description's "No CI changes" note, but not really in the code/docs), since reviewers of future dependency-bump PRs need to know they can't rely on CI to catch this.

2. Silencing stderr on toolchain install can hide real failures

Makefile line (in update-cargo-lock):

rustup toolchain install $(RESOLVER_TOOLCHAIN) --profile minimal > /dev/null 2>&1

If this install fails (network issue, disk space, rustup misconfiguration, or the pinned nightly being pruned/unavailable), the failure is swallowed entirely. The next line ($(CARGO_RESOLVE)) will then fail with a generic "toolchain not found" style error that gives the contributor no indication the actual root cause was a failed install. Suggest dropping 2>&1 > /dev/null (or at least keeping stderr visible) so install failures are diagnosable.

3. Pinned nightly will need periodic manual maintenance

RESOLVER_TOOLCHAIN := nightly-2026-06-21 freezes the resolver to a specific nightly snapshot indefinitely. Since -Z min-publish-age is an actively evolving unstable feature (per rust-lang/cargo#17009), the flag's behavior/name could change in later nightlies, but that's fine as long as this pin isn't bumped carelessly. Consider a short note (in the Makefile comment or CONTRIBUTING.md) on how/when to bump this pin, so it doesn't silently rot or get bumped to a nightly with a renamed/incompatible flag without someone re-verifying behavior.

4. Unstable config key names are worth double-checking for typos

.cargo/config.toml's [registry] global-min-publish-age = "14 days" and the CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE escape-hatch env var name are exact strings tied to an unstable, still-changing cargo feature. A typo in either would likely fail silently (config key simply ignored) rather than erroring loudly, which would quietly defeat the whole cooldown while make update-cargo-lock appears to succeed. The PR description says this was manually verified against a scratch crate, which is good — just flagging this as the kind of thing that's easy to silently regress if the nightly pin is ever bumped without re-verifying the exact flag/key names still apply.

Minor

• The .cargo/config.toml comment claims stable cargo "ignores these tables silently" — this matches cargo's documented behavior for [unstable]-gated config, so should be safe, but since .cargo/config.toml applies to every cargo invocation from the repo root (including CI's check-cargo-lock on stable), it's the one place where being wrong about this would have wide blast radius (breaking all CI cargo invocations at once). Given the PR author says they tested make check-cargo-lock passes on stable, this seems fine — just noting it's the highest-blast-radius assumption in the diff.

Overall: reasonable, low-risk, well-documented change. The main gap is that the cooldown is easy to bypass unintentionally (plain cargo update) with no CI backstop — acceptable as a first step per the PR's stated scope, but worth tracking as follow-up if the project wants this to be a hard guarantee rather than a convention.

---

Automated review by Claude (Anthropic) · sonnet · custom prompt

[Copilot]

🟡 Changes recommended

The Makefile currently suppresses rustup install error output (stderr), which can make failures non-actionable and should be adjusted before merging.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR introduces a repo-wide dependency-resolution “cooldown” for Rust crates by enabling Cargo’s unstable min-publish-age feature (14 days) and ensuring lockfile refreshes are resolved with a pinned nightly toolchain, while leaving stable locked builds unaffected.

Changes:

• Enable Cargo’s unstable publish-age policy in .cargo/config.toml (14-day minimum publish age).
• Route make update-cargo-lock through a pinned nightly + -Z min-publish-age resolver invocation across all workspace manifests.
• Document the intended lockfile-refresh workflow (and the emergency escape hatch) in CONTRIBUTING.md.

File summaries

File	Description
Makefile	Pins a nightly resolver and updates the lockfile refresh target to resolve under the min-publish-age policy across manifests.
CONTRIBUTING.md	Instructs contributors to use make update-cargo-lock (and documents the escape hatch) when changing Rust dependencies.
.cargo/config.toml	Enables unstable min-publish-age config and sets a global 14-day cooldown for crate resolution on nightly.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[MegaRedHand]

This is missing the CI check

[pablodeymo]

Added: make cooldown-check plus a gated cooldown-check job folded into the Integration Test aggregate. It flags lockfile pins younger than the window (downgrades annotated with a publish date; bare downgrades for MSRV or tightened requirements are ignored). The root workspace can only warn since its full re-resolution fails on the openvm p3-baby-bear pins, so the gate covers the 11 nested workspaces. Heads-up: it is red right now because the stateless-validator lockfiles pin crc32fast, log, rand, syn and uuid from the ERE v0.16.2 bump; they all age out by 2026-09-09. I'd rather wait than touch the guest lockfiles (ELF/VK bytes), but happy to downgrade them if you prefer.

[pablodeymo]

Downgraded the five stateless-validator pins to the highest version the cooldown allows (crc32fast 1.5.0, log 0.4.33, rand 0.8.7, syn 3.0.3, uuid 1.24.1) with a targeted cargo update -p on the nightly; nothing else in those lockfiles moved. make cooldown-check is green locally. Note this changes the guest ELF/VK bytes for the next stateless-validator release.