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

Rubygems.org AWS Root Access Event – September 2025

rubycentral.org

Post reply on HN
Print view View original

31–40 of 179 posts

Re: Rubygems.org AWS Root Access Event – September 2025

#31

Post by Imustaskforhelp »

zrail wrote: post #29
dismalaf wrote: post #22

Earlier quoted context omitted.

Gem can pull in gems from any repository, even straight from a git server like GitHub. And most of the time gems are built from scratch on your computer, Nokogiri is the only one I can think of that isn't.

The problem, as with every package manager, is transitive dependencies. It's all well and good to set up direct dependencies to only pull from git repositories, but bundler still needs a way to resolve those gems' dependencies. You could pre-resolve every dependency in your chain to a git repository, even to a fork under your own control, but that will end up being a maintenance nightmare.

Can't a middle compromise happen as it happens in something like golang?

Can some vps/serverless provider not do this like fly.io as an recent example with kurt got got? or hetzner?

I think that golang's model can actually be sort of cheaper/ more cost effective for servers as compared to how ruby might be doing it right now and so cheaper might mean that a new non profit can be created which can work on less money/outside funding/drama overall

Re: Rubygems.org AWS Root Access Event – September 2025

#32

Post by zrail »

nerdjon wrote: post #26
oneplane wrote: post #23

Earlier quoted context omitted.

You don't need the root account, unless you need to bypass all policies. In such a scenario, you a use the root access reset flow instead, reducing standing access. As for other flows (break glass, non-SSO etc), that can all be handled using IAM users. You'd normally use SAML to assume a role, but when SSO is down you'd use your fallback IAM user and then assume the role you need. As for how you disable the root acco…

To me that sounds like security by obscurity not actual security. If you have the ability to go through the reset flow than then why is that much different than the username and password being available to a limited sets of users. That would not have prevented this from happening if the determination was made that all 3 of these users need the ability to possibly get into root. As far as having an IAM user, I fail to…

Resetting the root password requires proving access to the email address associated with the root account. It also leaves a massive papertrail.

Re: Rubygems.org AWS Root Access Event – September 2025

#33

Post by [deleted] »

busterarm wrote: post #27

Props to Ruby Central for taking all of the smears and reputational damage on the chin silently while they mitigated an actual security incident, made absolutely sure and wrote up a proper post-mortem. All of that in line with their original statement that their actions taken were in the interest of security/integrity of their platform. If there's any evidence that you need to know who the proper stewards of Ruby's g…

[deleted]

Re: Rubygems.org AWS Root Access Event – September 2025

#35

Post by heartbreak »

dismalaf wrote: post #19
brunosutic wrote: post #15

Does anyone know if Arko can have legal troubles (like being sued) if it can be proven he "removed authorized users" from RubyCentral AWS account?

RubyCentral is a legal entity and they paid him for his work so they definitely could take action against him if he was shown to have harmed users or the company in any way.

Legal recourse is an interesting omission from their update, especially considering this was surely approved by their attorney(s).

Re: Rubygems.org AWS Root Access Event – September 2025

#36

Post by zrail »

Imustaskforhelp wrote: post #31
zrail wrote: post #29

Earlier quoted context omitted.

The problem, as with every package manager, is transitive dependencies. It's all well and good to set up direct dependencies to only pull from git repositories, but bundler still needs a way to resolve those gems' dependencies. You could pre-resolve every dependency in your chain to a git repository, even to a fork under your own control, but that will end up being a maintenance nightmare.

Can't a middle compromise happen as it happens in something like golang? Can some vps/serverless provider not do this like fly.io as an recent example with kurt got got? or hetzner? I think that golang's model can actually be sort of cheaper/ more cost effective for servers as compared to how ruby might be doing it right now and so cheaper might mean that a new non profit can be created which can work on less money/o…

Retrofitting Go's dependency model into Ruby is not trivial. Go has used full URLs for dependencies from the jump, making a central package repository irrelevant. Ruby doesn't have that. At best you might have a source code URL in the gem source that you can access from a gem server, but that doesn't really anything. Someone still has to provide the index.

Re: Rubygems.org AWS Root Access Event – September 2025

#37

Post by mikey_p »

codegeek wrote: post #7

"The root account credentials, essentially the highest level of administrative control, are stored in a shared enterprise password manager in a shared vault to which only three individuals had access: two current Ruby Central staff members and one former maintainer, André Arko" I am wondering. Did they at least have MFA enabled on the root login or not ?

So they failed to properly protect their credentials?

This sure doesn't reflect all this supposed professionalism and improvements RC was supposed to make.

Years ago, I decided with all the DHH drama, that using Rails was too much of a liability and this shit just makes the whole Ruby ecosystem a liability to anything build in that ecosystem.

Re: Rubygems.org AWS Root Access Event – September 2025

#38

Post by ctoth »

AWS account root access on a language package registry for 11 days. Not EC2 root - AWS account root. Complete control over IAM, S3, CloudTrail, every-damn-thing.

They're claiming "no evidence of compromise" based on CloudTrail logs that AWS root could have deleted or modified. They even admit they "Enabled AWS CloudTrail" after regaining control - meaning CloudTrail wasn't running during the compromise window.

You cannot verify supply chain integrity from logs on a system where root was compromised, and you definitely can't verify it when the logs didn't exist (they enabled them during remediation?).

So basically, somebody correct me here if I'm wrong but ... Every gem published Sept 19-30 is suspect. Production Ruby applications running code from that window have no way to verify it wasn't backdoored. The correct response is to freeze publishing, rebuild from scratch (including re-publishing any packages published at the time? Ugh I don't even know how to do this! ) , and verify against offline backups. Instead they rotated passwords and called it done.

Re: Rubygems.org AWS Root Access Event – September 2025

#39

Post by deng »

If they really have ethical concerns regarding sharing data with third parties, maybe they should update their privacy policies accordingly?

"We collect information related to web traffic such as IP addresses and geolocation data for security-relevant events and to analyze how and where RubyGems.org is used."

(https://rubygems.org/policies/privacy)

"We may share aggregate or de-identified information with third parties for research, marketing, analytics, and other purposes, provided such information does not identify a particular individual."

(https://rubycentral.org/privacy-notice/)

Re: Rubygems.org AWS Root Access Event – September 2025

#40

Post by mikey_p »

terracatta wrote: post #3

That email screenshot is pretty bad for Arko. It clearly shows intent to sell PII data to a third party during a time when Ruby Central had diminished funds and needed help affording basic services. What the fuck.

Why do they need money? What happened to their funding?
Post reply on HN