File informational advisories for unmaintained crates

[tarcieri]

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:

• Tracking unmaintained crates #134
• https://internals.rust-lang.org/t/tracking-unmaintained-crates-using-rustsec/10884

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:

• chan: recommend crossbeam-channel
• libusb: recommend rusb
• rust-crypto: recommend ring, RustCrypto (org), sodiumoxide
• term: recommend termcolor

[shssoichiro]

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

[tarcieri]

@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.

[topokel]

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]

@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]

@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]

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]

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

[kw217]

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]

@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]

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

[tarcieri]

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

Edit: filed: #183

[tarcieri]

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

[davidbarsky]

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

[Evrey]

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]

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.