Update maintenance status and alternatives in RUSTSEC-2024-0436.md

[esrauch]

Add additional alternative of paste-complete which is another fork which does not intend to add additional features

[esrauch]

Please see the (hopefully not too inflammatory) text on https://crates.io/crates/paste-complete for the motivation here.

As a concrete motivating explanation, as Google's official Protobuf crate, paste seems like the correct choice of dep and we wouldn't ant to take a dep onto pastey. But, if Protobuf publishes with a dep on paste will cause alarm and concern because of this rustsec.

As near term workaround I have published paste-complete is published and I can subscribe to that it is maintained. I assume Rustsec thinks these notices are WAI and so probably the right long term here is for paste crate to be taken away from current maintainer and moved to someone else who would be considered an active maitnainer an then the rustsec can be dropped.

[djc]

I'm not interested in advertising this crate with its zero downloads. People can always find it themselves when they need it.

[esrauch]

Yes, I did create it just to try to force some resolution on this topic.

I'd still like to ask to have the discussion here even in that case; listing Pastey in the notice seems problematic by comparison by driving people from a "good" package to something that is much higher risk to get bad patches.

I think looking at the prior issues discussing this rustsec in other projects, very few projects view Pastey as a viable alternative to the archived Paste project from a security perspective (I didn't actually find any case that did when I searched for GitHub issues discussing how to resolve the problem of this rustsec showing up as a problem).

Maybe it's appropriate to remove Pastey or include more disclaimers that the notice is that Paste is archived but has no known security concerns?

[esrauch]

Actually, is there a better process to discuss if this rustsec should be dropped/retracted instead? Maybe better topic on a github issue instead of in this PR comments?

Unmaintained notices being in rustsec make a lot of sense for certain libraries; if (for example) Tonic or Prost or whatever performed a similar action, where those foreseeably should expect to need patches for security/correctness, it is a good idea to warn transitive users that they might be using something that will foreseeably fall into being a security concern in the future.

Archiving of paste by contrast seems exactly premised on 'this will never need a security patch' and it seems the community is generally in agreement with that (where the response from ~all projects is just to denylist this rustsec rather than take action). Then (unlike other cases) having the rustsec published for this specific case seems to really be aligned with the community understanding of the situation.

[djc]

I'm open to a discussion on whether the paste advisory should be withdrawn. Suggest opening a PR to do that with a bunch of context and discussion in the PR description.

[tarcieri]

@esrauch there have been various issues opened effectively complaining or questioning the usefulness of tracking unmaintained crates like paste, and perhaps we should put some canned answers in HOWTO_UNMAINTAINED.md.

If you feel a crate is truly "done" and will never receive updates, one option is to vendor the code somewhere, or as you have done make a fork you control which allows you to reuse it across multiple other crates. At least in other package ecosystems, unmaintained packages are frequent targets of supply chain attacks, and taking either of these steps will protect you from them. Now I sure hope that doesn't happen to the particular author of this crate as they have unusually widespread reach in the Rust ecosystem, but that's one general motivation and the steps you can take to address it. Being able to do security response when issues are discovered is another.

However to address some of your other concerns:

I too have been a bit concerned about pastey given its widespread usage, relatively unknown author, and currently failing CI. On the other hand I don't want to play gatekeeper. Perhaps we can give a clearer disclaimer in our recommendations.

Something we've discussed in the past that could potentially be implemented (not sure if there's an open issue offhand) is leveraging the dependency graph analysis in cargo-lock to locate the toplevel packages in a workspace and then only apply (at least by default) informational advisory checks to immediate, rather than transitive, dependencies. There seems to be a bit of a thundering hurd problem when we file unmaintained advisories, tooling opens issues on downstream projects (which is also something we should try to fix), and then downstream users all go to complain to upstream maintainers.