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 buildkite-jobify

Dependencies

(26 total, 8 outdated, 3 possibly insecure)

CrateRequiredLatestStatus
 anyhow^1.01.0.81up to date
 app_dirs2^2.32.5.5up to date
 base64^0.130.22.0out of date
 bytes^1.01.6.0up to date
 camino^1.01.1.6up to date
 clap^3.24.5.4out of date
 crossbeam^0.80.8.4up to date
 flate2^1.01.0.28up to date
 futures^0.30.3.30up to date
 graphql_client^0.110.14.0out of date
 http^0.21.1.0out of date
 lru_time_cache^0.110.11.11up to date
 openssl ⚠️^0.100.10.64maybe insecure
 reqwest^0.110.12.2out of date
 serde^1.01.0.197up to date
 serde_json^1.01.0.115up to date
 serde_yaml^0.90.9.34+deprecatedup to date
 tar ⚠️^0.40.4.40maybe insecure
 toml^0.50.8.12out of date
 tame-oauth^0.70.10.0out of date
 tracing^0.10.1.40up to date
 tracing-subscriber^0.30.3.18up to date
 twox-hash^1.61.6.3up to date
 uuid^1.11.8.0up to date
 tokio ⚠️^1.01.36.0maybe insecure
 k8s-openapi^0.150.21.1out of date

Security Vulnerabilities

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!

tokio: reject_remote_clients Configuration corruption

RUSTSEC-2023-0001

On Windows, configuring a named pipe server with pipe_mode will force ServerOptions::reject_remote_clients as false.

This drops any intended explicit configuration for the reject_remote_clients that may have been set as true previously.

The default setting of reject_remote_clients is normally true meaning the default is also overridden as false.

Workarounds

Ensure that pipe_mode is set first after initializing a ServerOptions. For example:

let mut opts = ServerOptions::new();
opts.pipe_mode(PipeMode::Message);
opts.reject_remote_clients(true);

openssl: `openssl` `X509VerifyParamRef::set_host` buffer over-read

RUSTSEC-2023-0044

When this function was passed an empty string, openssl would attempt to call strlen on it, reading arbitrary memory until it reached a NUL byte.