Deps.rs

srijs / cargo-cross

[![dependency status](https://deps.rs/repo/github/srijs/cargo-cross/status.svg)](https://deps.rs/repo/github/srijs/cargo-cross)

This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.

Crate cargo-cross

Dependencies

(18 total, 10 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 chttp^0.1.50.5.5out of date
 console^0.6.10.16.3out of date
 directories^1.0.16.0.0out of date
 env_logger^0.5.120.11.10out of date
 failure^0.1.20.1.8up to date
 heck^0.3.00.5.0out of date
 indicatif^0.9.00.18.4out of date
 log^0.4.30.4.29up to date
 platforms^0.1.33.10.0out of date
 semver^0.9.01.0.27out of date
 serde^1.0.711.0.228up to date
 serde_derive^1.0.711.0.228up to date
 serde_json^1.0.261.0.149up to date
 sha1^0.6.00.11.0out of date
 structopt^0.2.100.3.26out of date
 tar ⚠️^0.4.160.4.45maybe insecure
 tempfile^3.0.33.27.0up to date
 xz2^0.1.50.1.7up to date

Dev dependencies

(2 total, 2 outdated)

CrateRequiredLatestStatus
 assert_cmd^0.9.12.2.0out of date
 cargo-toml-builder^0.1.00.3.0out of date

Security Vulnerabilities

tar: `unpack_in` can chmod arbitrary directories by following symlinks

RUSTSEC-2026-0067

In versions 0.4.44 and below of tar-rs, when unpacking a tar archive, the tar crate's unpack_dir function uses fs::metadata() to check whether a path that already exists is a directory. Because fs::metadata() follows symbolic links, a crafted tarball containing a symlink entry followed by a directory entry with the same name causes the crate to treat the symlink target as a valid existing directory — and subsequently apply chmod to it. This allows an attacker to modify the permissions of arbitrary directories outside the extraction root.

This issue has been fixed in version 0.4.45.

tar: tar-rs incorrectly ignores PAX size headers if header size is nonzero

RUSTSEC-2026-0068

Versions 0.4.44 and below of tar-rs have conditional logic that skips the PAX size header in cases where the base header size is nonzero.

As part of CVE-2025-62518, the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header. This is almost the inverse of the astral-tokio-tar issue.

Any discrepancy in how tar parsers honor file size can be used to create archives that appear differently when unpacked by different archivers. In this case, the tar-rs (Rust tar) crate is an outlier in checking for the header size — other tar parsers (including e.g. Go archive/tar) unconditionally use the PAX size override. This can affect anything that uses the tar crate to parse archives and expects to have a consistent view with other parsers.

This issue has been fixed in version 0.4.45.