Switch from tokio-tar to astral-tokio-tar (CVE-2025-62518)

[spatten]

Overview

This PR switches from tokio-tar to astral-tokio-tar@0.5.6 to address CVE-2025-62518.

tokio-tar is vulnerable to the same PAX/ustar header desynchronization issue described in the CVE: when PAX extended headers contain a size override, the parser uses the ustar header size (often zero) instead, allowing an attacker to smuggle entries into a tar archive. Since tokio-tar appears unmaintained, we switch to the actively maintained fork which has the fix in v0.5.6.

Both crates export as tokio_tar, so no import changes were needed — only an Entry::unpack_in() return type change (bool → Option<PathBuf>).

Acceptance criteria

Circe is no longer vulnerable to PAX header desynchronization attacks when processing tar archives.

Testing plan

1. cargo build succeeds.
2. cargo nextest run --all-targets — all 77 tests pass.
3. cargo test --doc — all 10 doc tests pass.

Metrics

N/A

Risks

astral-tokio-tar is a fork of tokio-tar with a slightly different API for Entry::unpack_in() (returns Option<PathBuf> instead of bool). This has been adapted in lib/src/cio.rs. The rest of the API is compatible.

References

• CVE-2025-62518
• GHSA-j5gw-2vrg-8fgx
• Fix commit in astral-tokio-tar

Checklist

• I added tests for this PR's change (or explained in the PR description why tests don't make sense).

Existing tests cover the affected code paths. The vulnerability fix itself is in the upstream dependency.

[spatten]

I had to make this change to fix the release build. Rust no longer allows you to create a release version < the current version, and the current version is 0.0.0, and 0.0.0-<git SHA> is less than 0.0.0.

[coderabbitai]

Walkthrough

The pull request updates the release workflow to compute pre-release versions dynamically by incrementing the patch version from Cargo.toml and appending the git SHA, replacing the fixed 0.0.0-based versioning. Dependencies are upgraded by replacing tokio-tar 0.3.1 with astral-tokio-tar 0.5.6 in both the bin and lib manifests. Additionally, error handling in the cio.rs file is refined by replacing a negated unwrap_warn call with an explicit .is_none() check in the apply_tarball function's unpack result handling.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely identifies the main change: switching to astral-tokio-tar and the specific CVE being addressed.
Description check	✅ Passed	The PR description comprehensively covers all template sections with relevant details: clear overview explaining the CVE issue, acceptance criteria, detailed testing plan with specific commands, risks with API changes documented, and proper references to CVE and advisories.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/release.yml (1)

77-82: PATCH extraction via cut is fragile if the version ever carries a pre-release suffix.

cut -d. -f3 on a version like "0.0.0-alpha" yields "0-alpha", causing $((PATCH + 1)) to either silently produce the wrong value or fail under set -e. A safer extraction uses cut only after stripping any pre-release component, or delegates to cargo metadata's semver fields.

♻️ Proposed robustness fix

-            PATCH=$(echo "$CURRENT" | cut -d. -f3)
+            PATCH=$(echo "$CURRENT" | cut -d. -f3 | cut -d- -f1)

This strips any trailing pre-release label (e.g., 0-alpha → 0) before the arithmetic, making the step robust against non-pure patch versions.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/release.yml around lines 77 - 82, The PATCH extraction is
fragile when CURRENT contains a pre-release suffix; update the workflow to strip
any pre-release label from CURRENT before computing PATCH (or parse semver
fields via cargo metadata) so that PATCH becomes a pure integer; specifically,
modify the logic around CURRENT / PATCH (which currently uses cut -d. -f3) to
remove anything after a hyphen (or otherwise extract the third numeric segment)
before doing $((PATCH + 1)), then continue to use MAJOR, MINOR, GIT_SHA and
cargo set-version as before.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/release.yml:
- Around line 77-82: The PATCH extraction is fragile when CURRENT contains a
pre-release suffix; update the workflow to strip any pre-release label from
CURRENT before computing PATCH (or parse semver fields via cargo metadata) so
that PATCH becomes a pure integer; specifically, modify the logic around CURRENT
/ PATCH (which currently uses cut -d. -f3) to remove anything after a hyphen (or
otherwise extract the third numeric segment) before doing $((PATCH + 1)), then
continue to use MAJOR, MINOR, GIT_SHA and cargo set-version as before.