I like this step
State your intention to take over the package in a public forum (we recommend Discourse, the haskell-cafe and/or libraries list). CC the maintainer.
And that there is a human in the loop - by default nothing happens.
Malware takeovers rely on the fact that they may go unnoticed for some time. This is likely to happen from time to time if there is any kind of automated takeover. It's less likely for this to happen if the takeover is manual and widely publicized.
In the Haskell case, the Hackage admins took for themselves the job of doing this mediation
Send an email to the hackage administrators (hackage-admin@haskell.org), with a link to the public email thread.(Include "package takeover request" in the subject).
The admins will grant you maintenance rights or upload a patched version for you.
However, the current crates.io team prefers to not have this policy, as per this RFC. In that RFC I suggested that maybe the job could be done by someone else, since it looks like an important (albeit thankless) thing to do to cultivate a better ecosystem.
Not having a mechanism to facilitate crate ownership changes means that there will be some instances of ecosystem breakage and/or churn that would be avoidable. Think about some very important crate with tons of dependencies, where owner goes MIA and realistically, a lot of projects will not even notice that they should migrate to the specific fork the community coalesced to (such forks tend to be announced on users.rust-lang.org, /r/rust, and other places, but after some time those threads get buried).
But now I think about it, a third-party tool (or even a first party cargo subcommand) that lists actively maintained forks of abandoned dependencies of your project might be a good replacement, at least for people that actually bother to use such a tool (there would still be churn though).
Anyway, about this
I think that it's odd to suppose all crates need to be regularly updated. Some crates are just done, and it's possible that for some crates further updates would be better handled in a separate, forked crate
It would be nice if Rust had some way to specify whether a crate is done, actively maintained, passively maintained (accepts PRs but no first party development), abandoned, etc. A lifecycle setting on Cargo.toml is not a great fit for this job, because Cargo.toml can only be updated with a new release, and it often a crate is declared done after some years of no activity. But crates.io already has some issues related to this config mismatch, and they might be better solved together - for example, the README in crates.io can only be updated with a new release, and this is not always the right thing to do
What is interesting here that the crate owner may decide a crate is done, but the community around it doesn't agree. I think in this case a fork is probably better, unless we are talking about a foundational crate (something at serde level). In this case, it would be better to take over it under the rust-lang umbrella, like libc, rand, etc