atty is unmaintained and can be replaced by std::io::IsTerminal #34

shavee-bin depends on atty 0.2 for terminal detection in get_password() and process_create(). That crate has been archived by its maintainer and has two open RustSec advisories.

RUSTSEC-2024-0375 — unmaintained

https://rustsec.org/advisories/RUSTSEC-2024-0375

The maintainer's own notice recommends the standard library's IsTerminal trait as the replacement.

RUSTSEC-2021-0145 — unsound, potential unaligned read

https://rustsec.org/advisories/RUSTSEC-2021-0145

Neither is exploitable in shavee today: the unaligned read is in the Windows console path, which is never compiled on Linux. This is dependency hygiene rather than an active vulnerability.

Current usage

shavee-bin/Cargo.toml:23        atty = "0.2"
shavee-bin/src/main.rs:3        use atty::Stream;
shavee-bin/src/main.rs:61       if atty::is(Stream::Stdin)
shavee-bin/src/main.rs:76       if atty::is(Stream::Stdin)

Proposed fix

std::io::IsTerminal has been stable since Rust 1.70 and provides identical behavior with no additional dependency:

use std::io::IsTerminal;

if stdin().is_terminal() { ... }

The workspace is already on edition 2024, so the MSRV is not a concern.

Effect on the dependency graph

atty is the only consumer of classic winapi in the tree:

atty v0.2.14
├── hermit-abi v0.1.19
├── libc
└── winapi v0.3.9
    ├── winapi-i686-pc-windows-gnu
    └── winapi-x86_64-pc-windows-gnu

Removing it drops 5 crates from Cargo.lock: atty, hermit-abi, winapi, winapi-i686-pc-windows-gnu, winapi-x86_64-pc-windows-gnu.

Note this does not remove the windows-sys / windows-targets family, which is pulled independently by clap and tokio.

Verification

See changes in my branch:

https://github.com/cmosetick/shavee/tree/deps/replace-atty-with-is-terminal

The change has been built and tested locally: shavee_core, shavee and shavee_pam all compile, and the full workspace test suite passes (24 tests).