Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Versions published more than 30 days ago cannot be deleted. Please contact RubyGems support to request deletion of this version if it represents a legal or security risk. #4630

Open
rubyFeedback opened this issue Apr 21, 2024 · 1 comment
Assignees

Comments

@rubyFeedback
Copy link

rubyFeedback commented Apr 21, 2024

Versions published more than 30 days ago cannot be deleted. Please contact RubyGems support to request deletion of this version if it represents a legal or security risk.

^^^ just had that now when I tried to remove an older version of a gem I maintain that had a few bugs.

Could someone let us know who made that decision?

I do not want to be associated with old code that I no longer maintain, so the only option I now have is to remove my
account at rubygems completely, rather than receive emails asking about old, buggy code here; and "contacting" xyz random person at rubygems.org is a no-go, not sure who at rubygems.org had that strange idea. Before I do so, I'd like to know whether that decision will be reverted or not. Either way is fine for me but I would like to know.

@martinemde
Copy link
Member

Hi @rubyFeedback,

We expected that the time constraint might need adjusting, so thank you for reaching out. The goal is to cause as little disruption as possible to the community and the maintainers while setting boundaries on acceptable use. We chose these specific constraints to allow most yanks, but to require communication with our security team when they are likely to have a large impact on the users of rubygems.org.

The decision was made by the Ruby Central Open Source Committee. The aim of the committee is to ensure that we act in the best interest of the community as a whole.

I'm happy to explain the reasoning behind our decision. Our logic is as follows:

  1. In assessing the risks to the rubygems.org ecosystem, we agreed that there is a significant risk of attacks or disruptions caused by large maintainers deleting gems used by hundreds of thousands of people.
  2. Deleting a gem from the ecosystem after it has been public for a period of time is more likely to cause major disruption.
  3. Sometimes this disruption is desirable. Large bugs, legal situations, or security vulnerabilities in major gems should be communicated to rubygems staff so that we can respond appropriately. Usually more is required than simply deleting the gem.
  4. In order to reduce the multiplicative negative impact of deleting widely used or old gems, we believe it's our right and responsibility to our community to ask people to communicate with us before performing largely disruptive actions rather than acting unilaterally.

Old versions are known and even expected to have bugs. That's the purpose of patch versions. A single maintainer choosing to delete publicly distributed versions breaks untold numbers of people and forces an immediate halt to their processes. Instead of allowing people to go through normal upgrade processes, a maintainer can unilaterally dictate the breakage of any package they maintain. We ask that maintainers include rubygems.org in this decision when their gem meets certain criteria.

We are open to evolving these constraints collaboratively if we are not meeting our goals. For anything urgent, we have a 24 hour on call rotation ready to help with emergencies that may arise.

@martinemde martinemde self-assigned this Apr 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants