Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby Central's Attack on RubyGems [pdf]

pup-e.com

Post reply on HN
Print view View original

81–90 of 286 posts

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

#81

Post by cxr »

simonw wrote: post #71
UseofWeapons1 wrote: post #61

Earlier quoted context omitted.

The post is quite clear? They call on the sponsors to stop funding ruby central, and the employment status bit is a clear concern extending from ruby central’s supposed takeover. Read the post more clearly before accusing someone of LLM usage. And even if it is, they are still valid points to be discussed, as opposed to trying to bury it with an LLM accusation.

I brought up LLM usage precisely because the two things I called out here are weird - the kind of details an LLM might add. If that's what happened then it's bad because it leaves people who read the comment confused - hence my questions asking about those. If the author confirms that those pieces I asked about serve an intentional purpose then I don't care if they used an LLM or not. My problem isn't with using LLMs…

What content has been invented?

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

#82

Post by krmbzds »

corytheboyd wrote: post #66
thomascountz wrote: post #42

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

Aren’t supply chain attacks caused by package maintainer accounts being compromised? I suppose too many people with keys to the package repository itself is also liability, but those accounts being compromised just hasn’t been what is happening.

[flagged]

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

#83

Post by adgjlsfhk1 »

byroot wrote: post #36
tremon wrote: 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.

Organizations should not do things like this without having their communication done in advance. They new what they were going to do, so they should have the blog post explaining exactly what and why they were doing to release (at the latest) at the same time.

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

#85

Post by woodruffw »

krmbzds wrote: post #82
corytheboyd wrote: post #66

Earlier quoted context omitted.

Aren’t supply chain attacks caused by package maintainer accounts being compromised? I suppose too many people with keys to the package repository itself is also liability, but those accounts being compromised just hasn’t been what is happening.

[flagged]

Your last sentence reads like a weird swipe: as best I can tell, there's no cultural war dimension to this whatsoever?

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

#87

Post by krmbzds »

simonw wrote: post #73
dragonwriter wrote: post #70

Earlier quoted context omitted.

> Why did you include that list of sponsors at the bottom of your post? Clearly, that was because this information directly supports readers following through on the call to action: “And if Ruby Central does not do this we must pressure sponsors to stop funding Ruby Central”. That’s obvious. > What's with the "contingent on employment status or ideological alignment" bit about? That's not been mentioned anywhere else…

Where did the ideological alignment piece come from then?

You can read it here: https://world.hey.com/dhh/no-railsconf-faa7935e

The cancellation of DHH's keynote was purely political. At that time, RubyCentral's response was similarly uncommunicative and their explanation was BS.

This is not the first strike.

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

#88

Post by nevinera »

woodruffw wrote: post #45
nevinera wrote: post #20

Earlier quoted context omitted.

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 Cent…

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

Post reply on HN