Don't know what 'yanking' a crate means specifically, but that seems like an ecosystem problem; in Java for example, maven dependencies are supposed to be immutable and the largest distributor (mvnrepository) doesn't allow updating a package.
More importantly, it seems ring has recently hit a long dry spell of getting no new commits at all. There has been some light maintenance work recently, but outside contributions haven't had a credible path into the main branch for a long while now.
I've just returned from a long break and I do have a concrete plan to catch up on the backlog. I have concrete plans for making it easier for people to get their PRs merged, making ring portable to all platforms, and eliminating all the remaining bits of C code in the next two quarters.
Feel free to reach out privately if you want to talk: brian@briansmith.org.
Using ring without a support contract is clearly a terrible decision. It's not a library any open source project or other library should depend on. Doing so will break your builds and the builds of others that use your library.
There are also other recent improvements, like ring used to require latest rustc very quickly, nowadays it's having MSRV's of older than six months. it also used to be impossible to link together multiple versions of ring in one binary, due to native dependencies used by ring. This issue has also been addressed thankfully.
The bug in cargo made the issues worse but not by much. Pulling crates/packages from the repository will break the build for almost everyone because updating your dependencies to the latest version, especially with an API that is not backwards compatible, takes time. The author suggests bumping versions until the application compiles again and that approach an easily take an afternoon if one of your dependencies hasn't updated yet.
It's the equivalent of the curl team deciding to pull all non-modified distributions of curl more than two versions old, or Angular/React/Svelte/Whatever doing the same, because they don't know if those versions are vulnerable or not.
There would be chaos as suddenly Linux distributions could no longer be built, reproducible builds would probably fail in the forked copies, most web applications would fail to start.
Nobody is asking the author to support older versions, or to not break the API between versions. The API is unstable, it's not had a 1.0 release and it probably never will. All people ask is leaving the old versions up so other projects can still build.
Since the project is open source, I suppose it's possible for someone else to created a ring-unpulled crate that's just the ring crate but with old versions still up. Should be doable with nothing more than a bash script running on a server somewhere.
Not being able to build a fixed release for a vulnerability you discovered in your own code has a bigger impact than a theoretical vulnerability that results in... not getting feature and API updates?
The code author can release his code in whatever way he wants and he can take down all but the very latest version of his package if he wants. It just makes his package unusable as a dependency for any real-world applications.
That's really not how it works when you work with others and use other's resources and time. Nobody's entitled to their effort, but they're also not immune to criticism from others for that effort if they hold that effort out for others - if they expect immunity because it's 'free' they're just wasting people's time and preventing the development of a solution which doesn't.