NOTE: Apologies in advance as I think this is bordering on what actually counts as "rust-internals", and is more of a general community management topic as it related to the crates.io ecosystem. That said, I feel this forum is closer to the audience I'm seeking feedback from than http://users.rust-lang.org
I posted a proposal to the RustSec issue tracker I'm attempting to solicit feedback from. The core idea:
Enable crate maintainers to notify downstream users that their crate is unmaintained (and provide recommendations for alternatives, or solicit new maintainers) using cargo-audit and the RustSec Advisory Database.
Full proposal here:
I mention this because I've observed a number of widely utilized core infrastructure crates in the Rust ecosystem which are presently unmaintained. And when I say "unmaintained", I mean their authors are opening issues like "Looking For Maintainers (LFM)", which is presently the case for the term crate which is used for a number of foundational Rust ecosystem tools including but not limited to Cargo:
Goals in a nutshell:
Increase awareness when crates are unmaintained
Help maintainers who want to hand off important crates find new maintainers
If they can't accomplish the above, provide a communication channel for maintainers of crates to recommend their preferred alternatives
Create a central visibility point for unmaintained crates and when ownership is being transferred
The tl;dr: implementation would be to allow crate maintainers to submit an unmaintained.toml file to https://github.com/rustsec/advisory-db, which would be consumed by cargo-audit, which can emit warnings (with a flag to optionally make them an error) when there are unmaintained crates detected in Cargo.lock.
I think it's really useful to be able to track and audit for this, on the other hand I think the severity is potentially quite a bit different from actual vulnerabilities. Or maybe not the severity, but the extent to which the audit result is actionable: for a security vulnerability, typically you can just upgrade to the new version, whereas for an unmaintained crate you now have to (a) pick up maintenance tasks or otherwise help invest energy to find new maintainers or (b) switch your project to an alternative. Both of these are large enough costs that people will want to ignore such problems at least for a while.
As for the mechanism used to track this, we kind of already have this in the Cargo metadata through the badges.maintenance field, so maybe we should use that instead of sticking it in the advisory DB. (Potentially you'd want to use the metadata from the latest version rather than the one in your dep graph, but that should be relatively straightforward?).
A separate mode like cargo audit --unmaintained that checks this stuff sounds great.
(Really I just want cargo audit and the advisory DB to move into cargo proper and the rust-lang org.)
Not to detract from your point, but term no longer appears in Cargo's list of transitive dependencies. Cargo migrated to termcolor from term over two years ago. However, it's still used in tools like rustfmt, clippy, pijul, prettytable-rs and cargo-crev.
What about notifying users about crate which is obviously unmaintained and there is no maintainer around to submit the notice? rust-crypto is a very prominent example here.
I'm interested in detecting and surfacing this info for lib.rs site.
I think there also needs to be a way to report an unmaintained create without involvement of the owner, because the worst cases are when the owner went missing.
A policy for community nomination of unmaintained crates sounds like a good idea. We'd just want to make sure it isn't abused, e.g. filed against crates that are passively-maintained.
Perhaps we could have criteria like:
No commits to the upstream repo for 1+ years
Community nomination via a GitHub issue/PR
Make attempt to contact the crate's author and confirm the crate is unmaintained
Crate authors get right of first refusal: if they do respond and say they don't want it marked as unmaintained, we won't
If no response after a grace period (e.g. 1 month), merge PR into database
Crate authors can still retroactively request the unmaintained advisory be removed, especially if they decide to start maintaining the crate again
A dead man switch mechanism as proposed looks like a good solution.
Not sure what the second step would add beside friction though. Step 1 and 3 can easily be automated (though using a bot for opening issues may be seen as spam by GitHub... The volume should be low enough to avoid being reported).
I don't think github cares about auto-PRs, especially if they're done in good faith. They have an API that allows creating PRs, after all - I've used it in the past to automate similar things.
I recently read about a crackdown by GH regarding a well-intentioned automated PR campaign, which had to be interrupted half way through.
I don't remember the specifics though (except that the intent was to improve some ecosystem, that most users were ok with it, but a few reported it as spam, and GH acted on that).
I suppose some Opt-In on crates.io (for all crates of a user, or per-crate) would satisfy the requirements from Github? That may be the most appropriate solution but leaves open the question of how pro-active and where cargo should be involved in the process of gather an crate owner's consent.
No idea how GH would handle that since the option would be out of their purview. To do things by the books, crates.io would probably have to request write permission to the repos (there's no finer grained permission AFAIK), but that is overkill for this purpose.
Also, people may want to host their source on non-GH hosts. We could then fall back to emailing them.
Edit, here's the list of permissions granted to an app when the "repository" option is checked:
Repositories Public and private
This application will be able to read and write all public and private repository data . This includes the following:
Code
Issues
Pull requests
Wikis
Settings
Webhooks and services
Deploy keys
Collaboration invites
This is what I meant by overkill
This grants a tremendous amount of power to random apps that only need to open issues or PRs.
You can request far more fine-grained permissions using the GitHub Apps API. If you do that, the only thing you'd need to ask for is pull request write permission (obviously) and maybe request the ability to write code (because you need to create a branch to open the pull request against).
