Skip to content

fix(deps): widen state-history-forensic to 0.2 - #17

Merged
h4x0r merged 2 commits into
mainfrom
fix/state-history-0.2
Aug 9, 2026
Merged

fix(deps): widen state-history-forensic to 0.2#17
h4x0r merged 2 commits into
mainfrom
fix/state-history-0.2

Conversation

@h4x0r

@h4x0r h4x0r commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

The last step of the state-history-forensic 0.1 -> 0.2 chain. "0.1" cannot
reach 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:

state-history-forensic v0.1.1
└── forensic-vfs v0.7.0            # then, after 0.7.2 shipped:
└── forensic-vfs-resolver v0.3.1
    └── forensic-vfs-engine v0.1.9

Both published members of the forensic-vfs workspace carried the old
requirement, so both had to release — 0.7.2 and 0.3.2 — before a consumer's
graph could resolve one version. deny.toml sets multiple-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-vfs 0.7.0 → 0.7.2 — 0.7.1 published and was never picked up
  • state-history-forensic 0.1.0 → 0.2.1 — 0.1.0 still declares
    rust-version = 1.85, the over-declared floor the 0.1.1 backport existed to
    correct, 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.1did not match any packages
  • one 0.2.1 entry in Cargo.lock, no second version
  • cargo tree -d duplicate set byte-identical to origin/main's — 35
    pre-existing duplicate pairs, none added. state-history-forensic appears in
    neither set.
  • cargo metadata --locked passes
  • cargo test --workspace --all-features --no-fail-fast → 90 passed, 0 failed,
    33 targets, exit 0

Noticed in passing, not addressed here

cargo tree -d shows two of our own crates duplicated in this graph —
safe-read 0.1.0 vs 0.2.1 and zip-forensic-core 0.1.0 vs 0.2.0. Same class of
problem as this PR, one narrow requirement upstream holding an old line alive.
Pre-existing and out of scope, but worth its own pass.

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.
@socket-security

socket-security Bot commented Aug 9, 2026

Copy link
Copy Markdown

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Addedforensic-vfs@​0.7.210010093100100
Addedforensic-vfs-resolver@​0.3.210010093100100
Addedstate-history-forensic@​0.2.110010093100100

View full report

…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.
@h4x0r
h4x0r merged commit a241723 into main Aug 9, 2026
16 checks passed
@h4x0r
h4x0r deleted the fix/state-history-0.2 branch August 9, 2026 14:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant