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

21–30 of 179 posts

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

#21

Post by flumpcakes »

nerdjon wrote: post #13
andrewguenther wrote: post #6

In 2025 there's no reason for anyone to be logging into an AWS account via the root credentials and this should have been addressed in the preventative measures. There's no actual control improvements here, just "we'll follow our procedures better next time" which imo is effectively doing nothing. Also this is really lacking in detail about how it was determined that no PII was accessed. What audit logs were checked?…

> In 2025 there's no reason for anyone to be logging into an AWS account via the root credentials and this should have been addressed in the preventative measures. I am curious what preventative measures you expect in this situation? To my knowledge it is not actually possible to disable the root account. They also had it restricted to only 3 people with MFA which also seems pretty reasonable. It is not unheard of th…

I'm now questioning my sanity but I thought you could disable login for the root account in AWS.

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

#22

Post by dismalaf »

phoronixrly wrote: post #14

So we have DHH with his unhinged posts on one side, and Arko wanting to sell PII on the other. Great! I think we need an f-droid-like project for Rubygems that builds the gems from source, and takes care of signing, and is backed by a non-profit that is independent from Rails/Shopify

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.

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

#23

Post by oneplane »

nerdjon wrote: post #13
andrewguenther wrote: post #6

In 2025 there's no reason for anyone to be logging into an AWS account via the root credentials and this should have been addressed in the preventative measures. There's no actual control improvements here, just "we'll follow our procedures better next time" which imo is effectively doing nothing. Also this is really lacking in detail about how it was determined that no PII was accessed. What audit logs were checked?…

> In 2025 there's no reason for anyone to be logging into an AWS account via the root credentials and this should have been addressed in the preventative measures. I am curious what preventative measures you expect in this situation? To my knowledge it is not actually possible to disable the root account. They also had it restricted to only 3 people with MFA which also seems pretty reasonable. It is not unheard of th…

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 account: solo accounts can't, but you can still prevent use/mis-use by setting a random long password and not writing it down anywhere. In an Org, the org can disable root on member accounts.

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

#24

Post by the_mitsuhiko »

flumpcakes wrote: post #21
nerdjon wrote: post #13

Earlier quoted context omitted.

> In 2025 there's no reason for anyone to be logging into an AWS account via the root credentials and this should have been addressed in the preventative measures. I am curious what preventative measures you expect in this situation? To my knowledge it is not actually possible to disable the root account. They also had it restricted to only 3 people with MFA which also seems pretty reasonable. It is not unheard of th…

I'm now questioning my sanity but I thought you could disable login for the root account in AWS.

Since there are certain operations that can only be done with the root account, there is no way to disable access to it.

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

#25

Post by [deleted] »

sersi wrote: post #17
terracatta wrote: post #8

Earlier quoted context omitted.

Yes because they state under the section "Root Cause Analysis" > Ruby Central failed to rotate the AWS root account credentials (password and MFA) after the departure of personnel with access to the shared vault.

If both password and MFA are stored in the same shared vault then MFA's purpose is compromised. Anyone getting access to that shared vault has the full keys to the kingdom the same as if MFA wasn't enabled. Also in this day and age, there's no reason to have the root account creds in a shared vault, no-one should ever need to access the root account, everyone should have IAM accounts with only the necessary permissio…

[deleted]

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

#26

Post by nerdjon »

oneplane wrote: post #23
nerdjon wrote: post #13

Earlier quoted context omitted.

> In 2025 there's no reason for anyone to be logging into an AWS account via the root credentials and this should have been addressed in the preventative measures. I am curious what preventative measures you expect in this situation? To my knowledge it is not actually possible to disable the root account. They also had it restricted to only 3 people with MFA which also seems pretty reasonable. It is not unheard of th…

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 see how that is actually that much better. You still have a user sitting there with long running credentials that need to be saved somewhere that is outside of how you normally access AWS. Meaning it is also something that could be easily missed if someone left.

Sure yes you could argue that the root user and that IAM user would have drastically different permissions, but the core problem would still exist.

But then you are adding another account(s) on top of the root account that must exist that you now need to worry about.

Regardless of the option you take, the root of the problem they had was 2fold. Not only did they not have alerts on the usage of the root account (which they would still need if they switched to having long running IAM users instead, but now they would also need to monitor root since that reset flow exists) and their offboarding workflow did not properly rotate that password, which a similar problem would also exist with a long running IAM user to delete that account.

At the end of the day there is not a perfect solution to this problem, but I think just saying that you would never use root is ignoring several other issues that don't go away just by not using root.

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

#27

Post by busterarm »

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 gems are, it's this.

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

#28

Post by software_writer »

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…

100%

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

#29

Post by zrail »

dismalaf wrote: post #22
phoronixrly wrote: post #14

So we have DHH with his unhinged posts on one side, and Arko wanting to sell PII on the other. Great! I think we need an f-droid-like project for Rubygems that builds the gems from source, and takes care of signing, and is backed by a non-profit that is independent from Rails/Shopify

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.

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

#30

Post by Imustaskforhelp »

phoronixrly wrote: post #14

So we have DHH with his unhinged posts on one side, and Arko wanting to sell PII on the other. Great! I think we need an f-droid-like project for Rubygems that builds the gems from source, and takes care of signing, and is backed by a non-profit that is independent from Rails/Shopify

Yes!

Not even sure why you are being downvoted, this is such a great idea actually.

F-droid has been so professional and they are just so professional

There was this developer (axet) who recently accused f-droid of somehow convincing the users "maliciously" that the funds are going to the the creator and f-droid when in reality it was going to f-droid and he name called them and what not..

Do you know what f-droid team still said?

They said that they can help him in the donation process and remove theirs and they actually took some feedback from what I know...

They clarified that the donations in their about page that the money that you donate through f-droid in their website's homepage donate goes to f-droid only which should be obvious but for some it wasn't

they also had f-droid donate in the website links of apps and I am not sure when they stopped it but they also stopped it and I deeply deeply respect it.

Like, okay maybe mistakes happen but f-droid is seriously good corporation. We might need something like that for sure. I genuinely think that out of thinking about open source so much, I realized that we need to have priorities to share things about open source.

F-droid is on the top of the list, its just that great, then there is signal/grapheneos or maybe all 3 are on top...

F-droid as an organization is something that I deeply appreciate and its a shame of google's attestation. I genuinely love f-droid nowadays.

Post reply on HN