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 poof

Dependencies

(21 total, 2 outdated, 2 possibly insecure)

CrateRequiredLatestStatus
 clap^4.44.5.38up to date
 dirs^6.06.0.0up to date
 errno^0.30.3.12up to date
 lazy_static^1.5.01.5.0up to date
 libc^0.20.2.172up to date
 reqwest^0.12.150.12.15up to date
 serde^1.01.0.219up to date
 zip^0.63.0.0out of date
 tar ⚠️^0.40.4.44maybe insecure
 flate2^1.01.1.1up to date
 xz2^0.10.1.7up to date
 bzip2 ⚠️^0.40.5.2out of date
 sevenz-rust2^0.13.10.13.2up to date
 log^0.4.270.4.27up to date
 env_logger^0.11.80.11.8up to date
 clap-verbosity-flag^3.0.23.0.3up to date
 regex^1.11.11.11.1up to date
 rayon^1.10.01.10.0up to date
 semver^1.0.261.0.26up to date
 anyhow^1.01.0.98up to date
 self_update^0.42.00.42.0up to date

Dev dependencies

(2 total, all up-to-date)

CrateRequiredLatestStatus
 tempfile^33.20.0up to date
 serial_test^33.2.0up to date

Build dependencies

(1 total, 1 possibly insecure)

CrateRequiredLatestStatus
 chrono ⚠️^0.40.4.41maybe insecure

Security Vulnerabilities

chrono: Potential segfault in `localtime_r` invocations

RUSTSEC-2020-0159

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

Workarounds

No workarounds are known.

References

tar: Links in archive can create arbitrary directories

RUSTSEC-2021-0080

When unpacking a tarball that contains a symlink the tar crate may create directories outside of the directory it's supposed to unpack into.

The function errors when it's trying to create a file, but the folders are already created at this point.

use std::{io, io::Result};
use tar::{Archive, Builder, EntryType, Header};

fn main() -> Result<()> {
    let mut buf = Vec::new();

    {
        let mut builder = Builder::new(&mut buf);

        // symlink: parent -> ..
        let mut header = Header::new_gnu();
        header.set_path("symlink")?;
        header.set_link_name("..")?;
        header.set_entry_type(EntryType::Symlink);
        header.set_size(0);
        header.set_cksum();
        builder.append(&header, io::empty())?;

        // file: symlink/exploit/foo/bar
        let mut header = Header::new_gnu();
        header.set_path("symlink/exploit/foo/bar")?;
        header.set_size(0);
        header.set_cksum();
        builder.append(&header, io::empty())?;

        builder.finish()?;
    };

    Archive::new(&*buf).unpack("demo")
}

This has been fixed in https://github.com/alexcrichton/tar-rs/pull/259 and is published as tar 0.4.36. Thanks to Martin Michaelis (@mgjm) for discovering and reporting this, and Nikhil Benesch (@benesch) for the fix!

bzip2: bzip2 Denial of Service (DoS)

RUSTSEC-2023-0004

Working with specific payloads can cause a Denial of Service (DoS) vector.

Both Decompress and Compress implementations can enter into infinite loops given specific payloads entered that trigger it.

The issue is described in great detail in the bzip2 repository issue.

Thanks to bjrjk for finding and providing the patch for the issue and the maintainer responsibly responding to release a fix quickly.

Users who use the crate with untrusted data should update the bzip2 to 0.4.4.