Bump astral-tokio-tar to 0.6.2 for RUSTSEC-2026-0145

[fnando]

What

Bumps astral-tokio-tar from 0.6.1 to 0.6.2.

Why

Advisory fix for RUSTSEC-2026-0145.

Known limitations

Cargo.lock also shows incidental version moves on windows-sys, socket2, and rustix subtrees. These are MSRV-aware resolver re-picks triggered by re-resolution after the bump, not deliberate downgrades.

[Copilot]

Copilot wasn't able to review any files in this pull request.

[claude]

Claude finished @fnando's task in 2m 17s —— View job

---

Review

• Load context and PR data
• Inspect the Cargo.lock diff
• Verify advisory and version change
• Check for side-effects (other crates moved)
• Post review

Summary

The targeted change — astral-tokio-tar 0.6.1 → 0.6.2 for RUSTSEC-2026-0145 — looks correct. Cargo.toml declares astral-tokio-tar = "0.6.0" (caret), so 0.6.2 satisfies the constraint without manifest churn. Lockfile-only PRs for advisory fixes are the right shape.

Findings

🟡 Incidental transitive downgrades (left an inline comment on Cargo.lock).
Out of 12 changed package entries in the lock, only 1 is the intended astral-tokio-tar bump — the other 11 are unrelated downgrades of transitive deps:

Crate	main	this PR	notes
astral-tokio-tar	0.6.1	0.6.2	✅ intended (advisory fix)
windows-sys (via colored)	0.59.0	0.48.0	⚠️ downgrade
windows-sys (via getrandom/quinn-udp/rustls/tempfile)	0.60.2 / 0.59.0	0.52.0	⚠️ downgrade
socket2 (via hyper-util/quinn/quinn-udp)	0.6.0	0.5.10	⚠️ downgrade
rustix subtree (linux-raw-sys/windows-sys)	newer	older	⚠️ downgrade

The PR description attributes these to "MSRV-aware resolver re-picks", but the workspace rust-version = "1.93.0" is high — MSRV-aware resolution is meant to allow newer versions, not force older ones. None of these crates are direct deps in any Cargo.toml, and astral-tokio-tar doesn't depend on socket2 / windows-sys / rustix directly, so 0.6.2 shouldn't force any of them backwards. This pattern more closely resembles a full cargo update (or a regen with a different local toolchain) than a surgical bump.

Recommendation: rerun with --precise so the diff is only the advisory fix:

git checkout origin/main -- Cargo.lock
cargo update -p astral-tokio-tar --precise 0.6.2

That keeps the security audit trail clean and avoids re-introducing older transitive versions that may carry their own advisories.

Verification I couldn't do here

• I didn't run cargo build / cargo audit in this review env — please ensure CI is green.
• I can't reach the RUSTSEC database from this environment to independently confirm 0.6.2 patches RUSTSEC-2026-0145; worth eyeballing the advisory link / changelog.

Verdict

Approve the intent (advisory fix), but recommend reworking the lockfile to a single-package change before merging. If the incidental downgrades are intentional, the PR description should explain why the newer transitive versions had to go.
• Branch: astral-tokio-tar-RUSTSEC-2026-0145

[claude]

Claude encountered an error after 2m 59s —— View job

---

Re-review after @fnando's reply

• Read @fnando's reply with actual cargo update --precise output
• Inspect repo resolver/MSRV config
• Check CI advisory coverage
• Revise verdict

Correction: my previous recommendation was wrong

@fnando, you're right and I apologize for the noise — the experiment you ran is exactly the right one and the result is conclusive. cargo update -p astral-tokio-tar --precise 0.6.2 on a clean origin/main lockfile produces the same 12-line diff that's already in this PR. So the transitive moves are not an artifact of a wholesale cargo update; they're what the current resolver produces for the minimal command.

What's actually going on

This workspace has resolver = "2" + rust-version = "1.93.0" (Cargo.toml:2,25) and channel = "stable" (rust-toolchain.toml:2). Even though --precise only pins one package, cargo still re-runs full graph resolution under that constraint, and recent cargo applies MSRV-aware version selection by default. Re-resolving today picks slightly different transitive versions than what was written when origin/main's lockfile was last regenerated — that's what the PR description was getting at, and on a clean reproduction it holds up.

In practical terms: the transitive moves here are unavoidable with any reasonable workflow short of hand-editing the lockfile to surgically replace only the astral-tokio-tar block and checksum. That would diverge from cargo's own output and would be undone the moment anyone re-runs cargo update.

Safety check on the moved crates

The "downgraded" versions are mature, widely-used stable releases — windows-sys 0.48/0.52, socket2 0.5.10, older linux-raw-sys. None of these are known to carry advisories that the newer versions fix. Worth confirming via the cargo-deny advisories matrix entry in .github/workflows/rust.yml:35-46; note that job is continue-on-error: true for advisories, so a flag would show up as a warning rather than a hard fail — worth eyeballing the run on this PR.

Verdict

Approve the intent and the change as it stands. The intentional bump (astral-tokio-tar 0.6.1 → 0.6.2 for RUSTSEC-2026-0145) is correct, and the incidental transitive moves are what cargo produces for the minimal command — not a process issue. Recommend just confirming the cargo-deny advisories matrix entry is clean on the CI run before merging.

Sorry again for the back-and-forth — your reproduction was the right way to settle this.
• Branch: astral-tokio-tar-RUSTSEC-2026-0145