RUSTSEC-2024-0375: atty is unmaintained

[github-actions]

atty is unmaintained

Details
Status	unmaintained
Package	atty
Version	0.2.14
URL	softprops/atty#57
Date	2024-09-25

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

See advisory page for additional details.

[DanielVoogsgerd]

I thought I would quickly tackle this one, I was wrong 😅

The main user of atty is humanlog, this should be easily fixable.

Another user is an old version of clap v2. The matching cargo tree is:

atty v0.2.14
├── clap v2.34.0
│   └── workflow v0.3.0
│       └── deliberation v0.1.0 (https://github.com/epi-project/policy-reasoner#9dfd53b9)
│           ├── audit-logger v0.1.0 (https://github.com/epi-project/policy-reasoner#9dfd53b9)
│           │   ├── reasonerconn v0.1.0 (https://github.com/epi-project/policy-reasoner#9dfd53b9)
│           │   │   └── srv v0.1.0 (https://github.com/epi-project/policy-reasoner#9dfd53b9)
│           │   │       └── brane-ctl v3.0.0 (https://github.com/epi-project/brane#8de160da)
│           │   │           └── key-manager v0.1.0 (<epi_dir>/policy-reasoner/fix/atty/tools/key-manager)

There are multiple problems with this dependency chain.
First and foremost, the workflow crate repo has been deleted, I think it is fair to assume it is no longer maintained. I will open a separate issue for this one. I see this has already been resolved. I think it further highlights my second point, though. 😆

But I am also a bit unhappy with the tight coupling / circular dependency between Brane and policy reasoner here. I might be wrong, but I think it is problematic to have policy reasoner (or its tools) depend on Brane(ctl). Maybe it is good to split off these tools into a separate crate that can depend on both crates, but that is just a collection of these niceties.

I am curious what you think, I think/hope clearing these things up will long term help with the stability and maintainability of the ecosystem.

[Lut99]

I agree, it's horrible, lol. I can't remember exactly what parts of brane-ctl it relies on, probably something to do with Docker integration? But to do it probably would be a major refactor of the Brane repo, possibly even splitting into separate repositories to get Cargo to play nice. So I'm always pushing that off...

If you're serious about it, though (and I'd be all for it), can you maybe make an issue where the list the dependencies between the two projects? I know for sure that the brane-ast crate is a shared dependency of both, but I can't recall the rest. If there's a full list we might come up with a nice organisation.

[Lut99]

Anyway, regarding this issue, I just merged the removal of that dependency over at humanlog and I don't see why we can't upgrade the clap version. So this might be fixed for now?

[DanielVoogsgerd]

If you're serious about it, though (and I'd be all for it), can you maybe make an issue where the list the dependencies between the two projects? I know for sure that the brane-ast crate is a shared dependency of both, but I can't recall the rest. If there's a full list we might come up with a nice organisation.

It's a tough one. Papercuts like this do hinder my productivity by quite a lot, as the maintenance burden can be quite high. Updates like the enum-debug one can propagate back and forth endlessly. My hope is that now that we are catching up on maintenance this burden will die down naturally a bit again, but the problem is not solved in that sense.

To mitigate a big part of the problem, I want to define dependencies like enum debug as workspace dependencies, so all are always defined at the same version and I don't have to hunt down that one I forgot somewhere.

If a refactor like that is worth, it will be hard to predict. Until I have exhausted the alternatives, I think I'm going to follow your footsteps and push that off for now.

Anyway, regarding this issue, I just merged the removal of that dependency over at humanlog and I don't see why we can't upgrade the clap version. So this might be fixed for now?

Almost, could you release a patch (I think) version for humanlog? And maybe solve this issue #140 in the same release 😇.

The clap dependency has been resolved. I am waiting on the backlog of PRs to be resolved (no hurry, just don't want to create merge conflicts on every merge) and I will then do a workspace wide cargo update on both repositories which will get rid of these old dependencies.

After we are golden and we can close this issue.

[Lut99]

Released the patch 👍

[DanielVoogsgerd]

Released the patch 👍

Great, it has been updated in #140. Once we merge it, only the one via clap and policyreasoner/workflow remains, but that should just be a Cargo update of the policy reasoner I think.