[drran]

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.

[jeroenhd]

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.

[drran]

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.

[jeroenhd]

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.

[justinjlynn]

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.

[drran]

Demand your money back!

[justinjlynn]

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

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.

[ohbtvz]

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

[justinjlynn]

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.