zlacker

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

>>nightp+(OP)
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.

>>nightp+(OP)
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.

>>picadi+VZ2
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".