←back to thread

104 points Qwuke | 9 comments | | HN request time: 0.587s | source | bottom
Show context
corytheboyd ◴[] No.45326382[source]
Very reasonable other side to this story, which doesn’t come as much of a surprise. Too bad it didn’t hit the front page.

People went WAY too far WAY too fast on this. There HAS to be urgency to this, the software supply chain is presently, undeniably, under attack.

Frankly, everyone blasting RubyCentral the last few days should feel shame and embarrassment. These aren’t evil suits at Microsoft, they’re normal people invested in maintaining a critical piece of infrastructure for the good of all who love and profit from Ruby.

replies(1): >>45328444 #
1. jaredcwhite ◴[] No.45328444[source]
What? This article is absolutely damning re: RC's leadership and the utter lack of proper transparency, strategic planning, marketing/PR, and solid OSS governance. Did we read the same article?!
replies(2): >>45337041 #>>45341525 #
2. picadi ◴[] No.45337041[source]
i read the article, but didn't see anything damning about it. how big of a staff do you think a tiny 501c3 like RubyCentral is? RC shepherds a pretty small community around a niche DSL with a shoestring non-profit budget that mostly goes towards running conferences.. you can see their financial reports here https://projects.propublica.org/nonprofits/organizations/300...

expectations around "strategic planning" and "marketing/PR" are not realistic. You should just be glad these randos don't have admin access to the Github org anymore. Any one of them were huge targets for adversaries who want to ship malware in Rubygems, supply chain attacks are very real and having commit access directly to rubygems/bundler is too powerful for a rando.

my main takeaway from reading all this is why were so many assorted people given such high levels of access..

replies(1): >>45337348 #
3. nightpool ◴[] No.45337348[source]
"These randos" are our friends and fellow contributors. Probably everybody in the Ruby community has worked with theme in one capacity or another. The article provides no reason why they should have had their contribution permissions revoked. Just because you think of Ruby as a "niche DSL" and the people maintaining its core infrastructure as "randos" doesn't mean the rest of us do.
replies(3): >>45339235 #>>45342800 #>>45348875 #
4. nenenejej ◴[] No.45339235{3}[source]
I'm for least privildge and tightening up perms, reviewing who has access. But it just needed some comms and timeline. Unless there was an obvious immediate threat.
5. corytheboyd ◴[] No.45341525[source]
Honestly I don’t know how to feel about it anymore, but I found the rhetoric way too explosive at the time, when nothing was really known. Now that some time has passed, and more has been said… yeah I get your point too.

Ruby has been a HUGE part of building my career, I don’t want to see it slide away one questionable move at a time into full corporate control. It’s not TOO hard to see how this whole thing could just be step one of that :/

replies(1): >>45360530 #
6. ◴[] No.45342800{3}[source]
7. picadi ◴[] No.45348875{3}[source]
just because someone is a nice community member doesn't mean they deserve rewrite-the-commit history admin level access to rubygems and bundler. they can be great committers even without the ego boost of knowing you hold the keys to get a ton of companies hacked without interference.

also, if you step back, Ruby's problem is it consists of a fading community of millenials and Gen Xers who first came to Rails when it was the best/coolest option. however with the majority of builders now turning to JS for web, Rust (and Go) for systems, and Python for ML, it doesn't have a use case anymore that can drive a community or any hope for growth in the future. so a "niche DSL" for legacy webapps and plugin systems is what's left IMO, but i'm sorry for being super frank about it

languages like this with a shrinking community and loose security policies pose around the centralized package management system pose high security risks to its users.

replies(1): >>45374293 #
8. phatskat ◴[] No.45360530[source]
I hate this for the community - I’m an outsider, who always wanted to give Ruby (and Rails) a good swing. However, after this, and after learning about dhh’s awful (imo) stances, I’m not ever going to go near any of it.

I had a similar “yuck” when WPEngine started taking Mullenweg to task over all of the WordPress shenanigans - that hit a lot closer to home for me, as I’ve spent about half of my career building great sites and applications on top of Wordpress. Although I’ve moved on, I was still an active contributor on the WP StackExchange and had my ear to the ground in several plugin repos I authored for employers who contributed to Five for the Future, and replied to comments on blog posts from people who found my previous insights helpful.

I have zero interest to ever go back to that project because of how poorly it’s been managed - if you want to see one man completely wreck an open-source ecosystem, it’s quite a fascinating if not depressing story.

9. nightpool ◴[] No.45374293{4}[source]
I'm not saying that they're just "a nice community member", I'm saying that they're the ones doing the work. They're not randos, they're trusted maintainers in the ecosystem with a proven track record. After the purge, rubygems and Bundler has only one active maintainer, one who's splitting his time between Rails, Ruby core, and many other open source projects. The bundler and gem-specific experts have been removed, and we've gone from a bus factor of 4-5 to a bus factor of 1. This is much, much more unacceptable then the theoretical risk of a trusted, active maintainer with 10+ years of community experience suddenly deciding to go rogue and rewrite history (has this ever happened in the history of a supply chain attack?)

Also, commit access to Github doesn't even say anything about access to deploying the actual package on rubygems. If security really was the goal, there were a million less invasive ways to make this change then revoking commit access from the active maintainers. Set up branch protections, require approvals, etc. There are a lot more tools in the toolbox other than "remove all of the maintainers".