Ring, unfortunately, has quite toxic project leadership with a history of making hostile decisions towards their contributors and userbase ( see https://github.com/briansmith/ring/issues/774 for one example ). Something to be aware of if you're considering building with it.

It looks like author of ring library tries to protect their user base from security vulnerabilities, but hit by bug(?) in cargo, which changed from warning to error for yanked libraries. Anyway, no promises until API version 1.0.

That's a rather charitable interpretation of events. Events which didn't need to happen. Events which happened for dubious reasons and which depended dubious reasoning.

Demand your money back!

Oh no. Just because they donate their time and effort the community can't criticise them; even if how they work and interact with the community hurts and embarrasses the community... it was all free after all and the community added nothing to it! /s

Then stop using ring? It just sounds like you want to have your cake and eat it too.

I just want people who interact with - and use the resources and time of - the community to behave in accordance with the values of that community.

I don't really get the reasoning (if there's a security bug, surely you know you've fixed it?). I fully support taking down versions that have known vulnerabilities, like the broken OpenSSL crate mentioned in that discussion.

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.

Security is a tradeoff between usability and safety. In this case, the author of ring received a suggestion from Rust security group to yank old, unsupported versions to be on the safe side, which created usability problems with ring. Security-minded people are OK with that, while security-ignorant people are not.

Availability is an important part of the CIA trifecta. A dependency being at the verge of being pulled at any time is a security issue by itself.

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 looks reasonable to me. The author is blunt about how he does things and why he does them, while being polite.

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.

Yanking crates makes them entirely unavailable for downstream users unless they've already locked the yanked version locally. This breaks dependencies and unlocked builds. Yanking crates is a last resort measure (a fundamentally broken release or a release for which you've issued a security advisory) and not something which should be done trivially regardless of whether or not it breaks all of your users for reasons related only to one's own conflicts of interest (i.e. You won't support it because the person asking you doesn't have a support contract). The author is most certainly entitled to be blunt about their support policy. They are not entitled to disregard community conventions when using community provided package hosting services.

So, even though it's a convention, and a supported action, it's taboo for them to yank.

Meanwhile, it's apparently such a sin because of people... That don't bother to lock their deps with a Cargo.lock? And that's not breaking an important convention?

I wouldn't call it toxic per se. It's a very business oriented approach.

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.

Generally you are right that this yanking policy isn't great, there is better tooling around to address security vulnerabilities than cargo yank by the author of the library. But it seems to me that it has been reconsidered. ring hasn't yanked versions of its library for a while, outside of one very recent yanking of an alpha release.

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.

Note that the ring maintainer has long since stopped yanking releases.

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.

The the old yanking policy was extra work I did with the intent to help people. It was unfortunate that Cargo had that bug, but also I should have been much more diplomatic in how I dealt with it.

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: [email protected].

That's awesome. Thanks heaps, Brian. I really appreciate your re-commitment. Apropos, Re: making ring portable to all platforms: IBM have been graciously maintaining a up to date patchset for Ring for years now and there's an outstanding PR here you may not have seen since they filed it in 2020... https://github.com/briansmith/ring/pull/1057

I read through that issue, and it doesn't seem so bad? There is a disagreement, but I don't really see anyone involved being "toxic"?