Live data from Hacker News

Ruby Central's Attack on RubyGems [pdf]

pup-e.com

41–50 of 286 posts

Re: Ruby Central's Attack on RubyGems [pdf]

#41
post #34

Earlier quoted context omitted.

Someone with absolutely no technical background, a recipe for disaster.

Opposed to hiring someone with a technical background but no experience running a non-profit?

As opposed to someone with experience with both?

Re: Ruby Central's Attack on RubyGems [pdf]

#43

Earlier quoted context omitted.

Links: https://rubycentral.org/news/reflections-on-railsconf-2025-f... https://www.linkedin.com/in/shancureton

Someone with absolutely no technical background, a recipe for disaster.

Rhiannon worked with Ruby Central for a bit, left a few weeks ago, and just shared this: https://bsky.app/profile/rhiannon.io/post/3lz6zcflg2s26

Re: Ruby Central's Attack on RubyGems [pdf]

#45

Earlier quoted context omitted.

I think the missing piece here is that almost every person publicly involved with RubyGems’ development has left the project in recent weeks. I don’t have any special insight here, but from an outsider’s perspective it seems as through Ruby Central is trying to turn a former “host” relationship into a “control” relationship.

I think you're right, but I suspect the root here is one of legal liability - if rubycentral is operating as a nonprofit that hosts _a recurring attack vector on other companies_, they'll have legal obligations to secure that service against those attacks. I assume they are continuously deploying out of that repository, and took the simplest route to controlling the attack vectors? I'm not sure how anyone familiar wi…

That would be a pretty broad assumption of liability: I'm not very involved in Ruby but I am involved in Python packaging, and to my knowledge there's been no similar discussion around the PSF's keys-to-the-code control over PyPI (which is in a similar position in terms of supply chain attack vectors).

In other words: that argument is interesting, but it feels strained to me :-) -- I don't think RubyGems or Ruby Central is actually legally liable in this way (or if they are, it suggests a failure of clarity in their EULA/TOS).

Re: Ruby Central's Attack on RubyGems [pdf]

#47

An update from Ruby Central: Strengthening the Stewardship of RubyGems and Bundler https://rubycentral.org/news/strengthening-the-stewardship-o...

Totally reads like post-facto CYA. they could have communicated this to the maintainers internally beforehand instead of blindsiding them.

Re: Ruby Central's Attack on RubyGems [pdf]

#50
post #36
post #31

Earlier quoted context omitted.

All we got right now is one side of the story That's because Ruby Central chooses not to communicate. I'm not going to reserve judgment against intentionally mute hostile actors.

Organizations are necessarily slower to communicate than individuals, give them a couple days. People need to chill out before jumping to conclusions like that.

What why? An organization is made up of individuals who had a heads up because they had a bunch of meetings and made the decision to do this, if anything they had a head start on communication. Their silence is their choice.
Post reply on HN