fix(deps): widen state-history-forensic to 0.2 - #17
Merged
Conversation
Completes the chain. "0.1" cannot reach 0.2.x -- for a 0.x crate cargo treats
the minor as the major -- so this crate was pinned to the 0.1 line with no lock
refresh able to cross it.
Ordered last on purpose. Widening here first was tried and measured: it
resolves 0.1.1 and 0.2.1 side by side, because forensic-vfs and
forensic-vfs-resolver both carried the old requirement. Both had to publish
(0.7.2 and 0.3.2) before this converges.
Also unsticks two layer-2 lock lags this crate had accumulated: forensic-vfs
0.7.0 -> 0.7.2 (0.7.1 was published and never picked up) and
state-history-forensic 0.1.0 -> 0.2.1, where 0.1.0 still declared rust-version
1.85 -- the floor the 0.1.1 backport existed to correct.
Verified, three ways:
- `cargo tree -i state-history-forensic@0.1.1` -> did not match any packages
- single 0.2.1 entry in Cargo.lock
- `cargo tree -d` duplicate set is byte-identical to origin/main's, so no new
duplicate is introduced (35 pre-existing pairs, unchanged)
`cargo metadata --locked` passes and the suite is green: 90 passed, 0 failed,
33 test targets.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
…en pulls in CI runs `cargo vet --locked`, which will not refresh imports.lock, so the cached publisher records still named forensic-vfs 0.7.0, forensic-vfs-resolver 0.3.1 and state-history-forensic 0.1.0 while the widen resolves 0.7.2, 0.3.2 and 0.2.1. Bookkeeping, not a supply-chain decision. All three already have [[trusted.*]] entries for user-id 347968 (h4x0r) with criteria safe-to-deploy, and every new version was published by that same account inside its trust window: forensic-vfs 0.7.2 published 2026-08-09 window 2026-07-07..2027-08-06 forensic-vfs-resolver 0.3.2 published 2026-08-09 window 2026-07-18..2027-08-05 state-history-forensic 0.2.1 published 2026-08-06 window 2026-06-16..2027-08-06 Dates read from the crates.io API, independently of cargo-vet. The set of attested crate NAMES is unchanged at 41 before and after -- the check that separates version churn (this) from a new crate entering the graph, which would be a decision and not a refresh. No exemption added, no certify, and not --accept-all.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The last step of the
state-history-forensic0.1 -> 0.2 chain."0.1"cannotreach 0.2.x — for a 0.x crate cargo treats the minor as the major — so this
crate sat on the 0.1 line with no lock refresh able to cross it.
Why this went last
Widening here first was tried, and measured. It does not converge:
Both published members of the
forensic-vfsworkspace carried the oldrequirement, so both had to release — 0.7.2 and 0.3.2 — before a consumer's
graph could resolve one version.
deny.tomlsetsmultiple-versions = "warn",so a leaf-first fix would have gone green over the duplicate and nobody would
have seen it.
Also unsticks two lock lags
Separate from the requirement, this crate's lock had drifted:
forensic-vfs0.7.0 → 0.7.2 — 0.7.1 published and was never picked upstate-history-forensic0.1.0 → 0.2.1 — 0.1.0 still declaresrust-version = 1.85, the over-declared floor the 0.1.1 backport existed tocorrect, so this crate was building against the un-fixed version
Neither is addressed by
rangeStrategy: "bump"; they are lock-level staleness,not requirement-level.
Evidence
cargo tree -i state-history-forensic@0.1.1→ did not match any packages0.2.1entry inCargo.lock, no second versioncargo tree -dduplicate set byte-identical toorigin/main's — 35pre-existing duplicate pairs, none added.
state-history-forensicappears inneither set.
cargo metadata --lockedpassescargo test --workspace --all-features --no-fail-fast→ 90 passed, 0 failed,33 targets, exit 0
Noticed in passing, not addressed here
cargo tree -dshows two of our own crates duplicated in this graph —safe-read0.1.0 vs 0.2.1 andzip-forensic-core0.1.0 vs 0.2.0. Same class ofproblem as this PR, one narrow requirement upstream holding an old line alive.
Pre-existing and out of scope, but worth its own pass.