search

killercup / cargo-edit

A utility for managing cargo dependencies from the command line.
http://killercup.github.io/cargo-edit/
MIT License
3.09k stars 148 forks source link

concolor-control Archived; requires potentially insecure atty #900

Closed theory closed 4 months ago

theory commented 4 months ago

Looks like cargo-edit dependency concolor has been archived for over a year. It, in turn, depends on atty, which appears to be unmaintained and has a potential security issue (sample dependabot report.

Should concolor be removed or replaced with something that's maintained?

epage commented 4 months ago

With rust-lang/cargo#12425, I am treating cargo-edit as in maintenance mode and am doing the absolute minimum work on it, including for what PRs get reviewed.

theory commented 4 months ago

Thanks. I'm only interested in seeing security vulnerabilities addressed wherever possible. Whether or not it's worth it here presumably has to do with the timing of rust-lang/cargo#12425 as a replacement.

I suppose in the meantime I can just tell dependabot to STFU about atty.

epage commented 4 months ago

Why does dependabot care about cargo-edit dependencies?

theory commented 4 months ago

In this dependabot report, it says atty has a "potential unaligned read". That project depends on pgrx, which depends on cargo-edit, which depends on concolor, which depends on atty.

There are actually a few other paths to atty through pgrx; details in pgcentralfoundation/pgrx#1778.

epage commented 4 months ago

I can't access that dependabot report.

I'm going to guess you are depending on cargo-edit as a library? Why is that?

theory commented 4 months ago

I am not, but pgrx does. I don't know why.

theory commented 4 months ago

rust-lang/rustup#3443 has some information about the atty vulnerability.

workingjubilee commented 4 months ago

Because cargo-pgrx wants to update the files in Cargo.tomls for similar reasons in specific ways...?

workingjubilee commented 4 months ago

In practice, this is not at all a concern from the security perspective as we don't even support Windows much less use a custom allocator.

epage commented 4 months ago

So long as you know that for a while cargo-edit-the-lib is developed exclusively for cargo-edit-the-bin, semver is tracking the bins and not the libs, we are free to remove things as needed even if used by library users, and this has gone into deep maintenance mode as the functionality is moved into Cargo.

As this doesn't seem to be an issue, I'm closing this.