undefined | Better HN

0 pointsnevinera6mo ago0 comments

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 with open-source communities would fail to predict the backlash though. They really should have forked the repository and switched the deployments over to their downstream fork (if I'm right about the root cause here).

(I'm mostly thinking in terms of supply-chain attacks, like this one: https://blog.rubygems.org/2025/08/25/rubygems-security-respo...)

0 comments

woodruffw6mo ago

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).

nevineraOP6mo ago

Well.. "legal liability" is kind of complex topic. Usually what really matters isn't "what the courts will actually determine if such a case is brought" it's "how much will it cost to prove that lack of liability, and what is the risk that we are wrong?". I also don't believe that such an organization is liable for anything beyond negligence, but whether the lack of an action constitutes negligence is .. well, one can rarely be totally confident in the outcome of that kind of proceeding.

The (mostly PR) explanation they produced seems to express roughly the same thing I was guessing though: https://rubycentral.org/news/strengthening-the-stewardship-o...

nevineraOP6mo ago

Well, there's more information out and it seems pretty.. damning. I wasn't convinced by "power grab", but "economic pressure from our sole remaining major sponsor" is _way_ more believable, and the chain is events is getting fairly clear. Check out Joel's explanation for a coherent delve into the events: https://joel.drapper.me/p/rubygems-takeover/

Now I just have to hope the fallout from this includes a less centralized replacement for the tools I'm used to - I haven't found anything solid yet, but I imagine andre will be examining this problem space with rv now.

blibble6mo ago

there is no contract to assign liability

and I doubt you could ever get negligence to stick, given you are downloading code from some website and running it, on your own accord, entirely unprompted

(but IANAL)

j / k navigate · click thread line to collapse

0 pointsnevinera6mo ago0 comments

(I'm mostly thinking in terms of supply-chain attacks, like this one: https://blog.rubygems.org/2025/08/25/rubygems-security-respo...)

0 comments

woodruffw6mo ago

nevineraOP6mo ago

The (mostly PR) explanation they produced seems to express roughly the same thing I was guessing though: https://rubycentral.org/news/strengthening-the-stewardship-o...

nevineraOP6mo ago

blibble6mo ago

there is no contract to assign liability

and I doubt you could ever get negligence to stick, given you are downloading code from some website and running it, on your own accord, entirely unprompted

(but IANAL)

j / k navigate · click thread line to collapse