RUSTSEC-2024-0375 (unmaintained) on 2024-09-25: atty is unmaintained

The maintainer of atty has published an official notice that the crate is no longer under development, and that users should instead rely on the functionality in the standard library's IsTerminal trait.

Alternative(s)

  • std::io::IsTerminal - Stable since Rust 1.70.0 and the recommended replacement per the atty maintainer.
  • is-terminal - Standalone crate supporting Rust older than 1.70.0
RUSTSEC-2021-0145 (unsound) on 2021-07-04: Potential unaligned read

On windows, atty dereferences a potentially unaligned pointer.

In practice however, the pointer won't be unaligned unless a custom global allocator is used.

In particular, the System allocator on windows uses HeapAlloc, which guarantees a large enough alignment.

atty is Unmaintained

A Pull Request with a fix has been provided over a year ago but the maintainer seems to be unreachable.

Last release of atty was almost 3 years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

https://github.com/softprops/atty/pull/51

https://github.com/softprops/atty/issues/57

GHSA-g98v-hv3f-hcfr

These reviews are from Crev, a distributed system for code reviews. To add your review, set up cargo-crev.

0.2.14 (current) Rating: Positive Thoroughness: Medium Understanding: Medium

by matthiasbeyer on 2022-09-22

Simple codebase, looks good. Did not look at the cfg(windows) code.

0.2.14 (current) Rating: Positive + Unmaintained Thoroughness: High Understanding: High

by git.jcg.re/jcgruenhage/crev-proofs.git on 2022-09-19

One of the more foundational crates found in the dependency tree of a lot of rust programs, because both clap and env_logger pull this in.

In my review I've fully read the source code and can confirm that I fully understand what's happening in here. The unix and hermit targets are extremely straight-forward. As for the windows target, that's a bit more complicated, but still manageable in the end. Windows doesn't have a clear API for determining whether something is a (pseudo) TTY, so the heuristics provided by this crate are as good as it's going to get.

This crate has quite a few unsafe code sections, but that's sometimes required for providing a safe interface. In this case, we need it because the underlying functions for unix (libc) are unsafe, and the same applies to a bunch of winapi functions used in the heuristics for windows.

The bits of unsafe code that's not just wrapping an unsafe function provided by another library are all in the windows heuristics, and involved provisioning buffers that winapi calls can write info back into and some pointer magic. While I couldn't spot an issue with this, a look into the issue tracker revealed that other's have. The buffer creation on the heap is not necessarily aligned properly, meaning that there's a possible soundness issue on windows targets here.

Last but not least, we have to talk about maintenance and and alternatives: The soundness issue mentioned above has been known for over a year, with a fix first pushed to a PR shortly after. Even though there's been reviews from well-known rustaceans, the author hasn't merged this PR yet, and in general there hasn't been any relevant activity for a while.

An alternative implementation that has been derived from atty is is-terminal, which has taken this into consideration and has taken over the rest of the implementation from here, with a slightly different API. They're also switching the underlying implementations around, reducing the amount of unsafe.

As for why I'm still rating this as positive: With the exception of the potential unsoundness bug on windows, this crate is still okay-ish to be used. Also: Getting rid of it soon is not realistic, because it's in the dependency tree of quite a few widely-used crates.

To summarize: Widely used, foundational crate. Except for on windows, this is perfectly fine, on windows there's an unsoundness bug, and there has not been an update or other activity from upstream. is-terminal is a good alternative, which was derived from this crate, but includes the fix for the unsoundess bug.

0.2.14 (current) Rating: Positive Thoroughness: Medium Understanding: Medium

by vlad20012 on 2021-09-15

This version only adds support for target_os = "hermit" via hermit_abi crate. The rest of the code in the crate has not been changed.

0.2.14 (current) Rating: Positive Thoroughness: Low Understanding: Medium

by andrewaylett on 2021-04-08

Code changes are minimal and sensible.

The current version of atty is 0.2.14.

0.2.13 (older version) Rating: Positive Thoroughness: Low Understanding: Medium

Approved without comment by kornelski on 2019-08-22

0.2.11 (older version) Rating: Positive Thoroughness: Medium Understanding: Medium

by git.sr.ht/~icefox on 2019-08-22

Small platform-functionality wrapper, nothing exciting.


These reviews are from cargo-vet. To add your review, set up cargo-vet and submit your URL to its registry.

cargo-vet does not verify reviewers' identity. You have to fully trust the source the audits are from.

safe-to-run

This crate can be compiled, run, and tested on a local workstation or in controlled automation without surprising consequences. More…

does-not-implement-crypto (implies crypto-safe)

Inspection reveals that the crate in question does not attempt to implement any cryptographic algorithms on its own.

Note that certification of this does not require an expert on all forms of cryptography: it's expected for crates we import to be "good enough" citizens, so they'll at least be forthcoming if they try to implement something cryptographic. When in doubt, please ask an expert.

crypto-safe
Implied by other criteria

All crypto algorithms in this crate have been reviewed by a relevant expert.

Note: If a crate does not implement crypto, use does-not-implement-crypto, which implies crypto-safe, but does not require expert review in order to audit for.

safe-to-deploy (implies safe-to-run)

This crate will not introduce a serious security vulnerability to production software exposed to untrusted input. More…

unknown

May have been packaged automatically without a review


Lib.rs has been able to verify that all files in the crate's tarball, except Cargo.lock, are in the crate's repository with a git tag matching the version. Please note that this check is still in beta, and absence of this confirmation does not mean that the files don't match.

Crates in the crates.io registry are tarball snapshots uploaded by crates' publishers. The registry is not using crates' git repositories, so there is a possibility that published crates have a misleading repository URL, or contain different code from the code in the repository.

To review the actual code of the crate, it's best to use cargo crev open atty. Alternatively, you can download the tarball of atty v0.2.14 or view the source online.