Deps.rs

assets_manager 0.12.1

[![dependency status](https://deps.rs/crate/assets_manager/0.12.1/status.svg)](https://deps.rs/crate/assets_manager/0.12.1)

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 assets_manager

Dependencies

(22 total, 7 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 ab_glyph^0.2.120.2.32up to date
 ahash^0.8.00.8.12up to date
 assets_manager_macros^0.2.40.3.1out of date
 base64^0.220.22.1up to date
 basic-toml^0.1.30.1.10up to date
 bincode^1.23.0.0out of date
 crossbeam-channel^0.50.5.15up to date
 gltf^1.01.4.1up to date
 hashbrown^0.14.30.17.1out of date
 image^0.250.25.10up to date
 log^0.40.4.30up to date
 notify^6.08.2.0out of date
 once_cell^1.161.21.4up to date
 parking_lot^0.120.12.5up to date
 rmp-serde^1.11.3.1up to date
 ron^0.80.12.1out of date
 serde^1.01.0.228up to date
 serde_json^1.01.0.150up to date
 serde_yaml^0.9.10.9.34+deprecatedup to date
 sync_file^0.20.3.2out of date
 tar ⚠️^0.4.380.4.46maybe insecure
 zip^0.68.6.0out of date

Dev dependencies

(4 total, 1 outdated)

CrateRequiredLatestStatus
 cfg-if^1.01.0.4up to date
 env_logger^0.110.11.10up to date
 rand^0.80.10.1out of date
 serde^1.01.0.228up to 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.