Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File informational advisories for unmaintained crates #173

Closed
4 tasks done
tarcieri opened this issue Oct 2, 2019 · 21 comments
Closed
4 tasks done

File informational advisories for unmaintained crates #173

tarcieri opened this issue Oct 2, 2019 · 21 comments

Comments

@tarcieri
Copy link
Member

tarcieri commented Oct 2, 2019

Now that cargo-audit v0.9 is out with support for informational advisories, it would be good to start filing advisories for unmaintained crates.

Previous discussion around this topic:

Note that for users of older versions of cargo-audit which lack support for informational advisories, these advisories will appear as hard errors. There's not much we can do about that except have people upgrade to a newer cargo-audit release which does.

I'd propose including the version of the last crate release so that in the event unmaintained crates are maintained again and see new releases, we can filter those releases from these advisories automatically. So if the last release of a crate were 0.1.2, add:

unaffected_versions = ["> 0.1.2"]

Ideally we can also add a list of alternative maintained crates to consider so these advisories are actionable. We can always update this list retroactively in the event someone has a new alternative to recommend.

Here are some unmaintained crates that have come up in discussion and some suggested alternatives to recommend:

@shssoichiro
Copy link

I'd like to suggest marking failure as unmaintained. I've been using err-derive as an alternative.

@tarcieri
Copy link
Member Author

tarcieri commented Oct 4, 2019

@shssoichiro there's active maintenance work on failure currently underway:

rust-lang-deprecated/failure#319

While I'd agree it might make sense to consider it "soft deprecated" from a colloquial ecosystem perspective, I wouldn't call it "unmaintained".

That said, if that PR doesn't land in... say 90 days, that would change my opinion.

@distransient
Copy link

For those who are unfamiliar, has the RustSec team considered an automated process integrated into crates.io where authors can mark (and un-mark) their crates as unmaintained if they wish? (if this isn't already possible) Or perhaps for example, maybe checking if a Github repository linked to a crate is marked as Archived?

@tarcieri
Copy link
Member Author

tarcieri commented Oct 4, 2019

@distransient one source of information which is already catalogued is the badges.maintenance status catalogued in Cargo.toml, which I was recently discussing in a Reddit thread.

I think it would be very much worth data mining crates which self-identify as unmaintained from crates.io itself by keying off this attribute.

However, in the same thread, I also spelled out a bit of a mission statement as to what I think we want to ultimately accomplish with unmaintained crate warnings:

Our goal with cataloging RustSec advisories for unmaintained crates is to actually make them helpful. This includes due consideration as to whether or not crate is actually "unmaintained" so we don't overburden people with too many "unmaintained" false positives for what are actually "passively maintained" scenarios.

The last thing I want us to be is the "you haven't committed/released regularly enough" police. I think we should "do no harm" in terms of being the deciding factor for people who are borderline committed to a crate to push them over the edge to "unmaintained" status.

Rather than that, I think we should individually catalogue and provide well-considered recommendations for popular core ecosystem crates which are obviously unmaintained, have well-maintained alternatives/successors, and are clear candidates for "ecosystem deprecation".

@shssoichiro
Copy link

@tarcieri Thanks, glad to see some signs of life re. failure. I assumed it was dead since the last merged PR was in March, and the open PRs and issues have piled up.

@fogti
Copy link

fogti commented Oct 4, 2019

What's up with danburkert/memmap-rs#90? I think it currently counts as passively maintained, althrough PRs and Issues seem to pile up.

@markmmm
Copy link

markmmm commented Oct 6, 2019

The Author of Notify has put a big "Abandoned" messgine in their readme - maybe it should be considered: https://crates.io/crates/notify

@kw217
Copy link
Contributor

kw217 commented Oct 7, 2019

I attempted to get the owner of https://crates.io/crates/cassandra to transfer ownership to me, but got no response despite trying for months. https://crates.io/crates/cassandra-cpp is my maintained fork. Also the dependent crates: https://crates.io/crates/cassandra-sys -> https://crates.io/crates/cassandra-cpp-sys .

@tarcieri
Copy link
Member Author

tarcieri commented Oct 7, 2019

@markmmm notify appears to be in a... somewhat strange state where the author claims to have abandoned it but given several people access to it. It had a release in September so I wouldn't call it unmaintained.

@tarcieri
Copy link
Member Author

tarcieri commented Oct 7, 2019

@zserik will keep an eye on the issue you filed danburkert/memmap-rs#90

@tarcieri
Copy link
Member Author

tarcieri commented Oct 7, 2019

@kw217 that does indeed look unmaintained. I'll file an advisory.

Edit: filed: #183

@tarcieri
Copy link
Member Author

Regarding failure, it looks like 0.1.6 will be out soon: rust-lang-deprecated/failure#331

@davidbarsky
Copy link

I've just published failure 0.1.6: https://docs.rs/failure/0.1.6/failure/

@Evrey
Copy link

Evrey commented Jan 17, 2020

So… assuming we are still collecting potentially unmaintained crates here:

  • logos: Most recent version is the 1 year old 0.10.0-rc2, last commit was 2019-03-09, and there are a lot of open bug-related issues, including ones about easily OOM-killing logos. So, could potentially be unmaintained. Sadly, an alternative crate does not exist.
  • shared_library: 0.1.9 is two years old, and there are 4 years old yanked 0.2.* versions. Last commit on GitHub was also 2 years ago, and there are bug-related open issues. A potential alternative looks to be dlopen. The author of dlopen seems to burst-update this crate every few months.
  • bit-set states that it is in maintenance mode.

@tarcieri
Copy link
Member Author

I'd prefer to only file advisories that are actionable, i.e. there are crates to switch to, but otherwise it seems like all of those are applicable with the possible exception of logos, provided you can't find an alternative to recommend.

@Evrey
Copy link

Evrey commented Jan 18, 2020

In that case only actions on shared_library and bit-set need to be taken. For bit-set, this pops up as a potential alternative:

  • bitvector: Apparently based on rustc-internal data structures. No activity in the issues, but seemingly regular commit activity, last commit from a month ago. API looks mostly drop-in replaceable.

As for logos, there's still hoping its creator will pop up back into existence and greet everyone with a big update.

@Shnatsel
Copy link
Member

I'm not sure bit-set qualifies for an advisory. The README states that the maintainers are still merging fixes, so it is not a security risk to rely on bit-set.

@tarcieri
Copy link
Member Author

tarcieri commented May 2, 2020

FYI, failure has been officially deprecated, and I filed a tracking issue for eventually filing an unmaintained crate advisory for it: #284

The dirs and directories crates GitHub repos were recently archived, and I opened an issue about filing an unmaintained crate advisory for those as well: #282

@Evrey
Copy link

Evrey commented May 2, 2020

As for logos: Back on track.

@tarcieri
Copy link
Member Author

tarcieri commented May 7, 2020

As noted on #290: bigint is unmaintained

@pinkforest
Copy link
Contributor

This seems old tracking issue -

Closing in favor of tracking indvidual crates under their own separate issues - the way we've adopted.

If something needs to be discussed then we can always do those in discussions.

Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants