The RubyGems "Security Incident"

2025-10-103:3017765andre.arko.net

Ruby Central posted an extremely concerning “Incident Response Timeline” today, in which they make a number of exaggerated or purely misleading claims. Here’s my effort to set the record straight.…

Ruby Central posted an extremely concerning “Incident Response Timeline” today, in which they make a number of exaggerated or purely misleading claims. Here’s my effort to set the record straight.

First, and most importantly: I was a primary operator of RubyGems.org, securely and successfully, for over ten years. Ruby Central does not accuse me of any harms or damages in their post, in fact stating “we have no evidence to indicate that any RubyGems.org data was copied or retained by unauthorized parties, including Mr. Arko.”

The actions I took during a time of great confusion and uncertainty (created by Ruby Central!) were careful, specific, and aimed to defend both Ruby Central the organization and RubyGems.org the service from potential threats.

The majority of the team, including developers in the middle of paid full-time work for Ruby Central, had just had all of their permissions on GitHub revoked. And then restored six days later. And then revoked again the next day. Even after the second mass-deletion of team permissions, Marty Haught sent an email to the team within minutes, at 12:47pm PDT, saying he was (direct quote) “terribly sorry” and “I messed up”. Update: Added email timestamp.

The erratic and contradictory communication supplied by Marty Haught, and the complete silence from Shan and the board, made it impossible to tell exactly who had been authorized to take what actions. As this situation occurred, I was the primary on-call. My contractual, paid responsibility to Ruby Central was to defend the RubyGems.org service against potential threats. 

Marty’s final email clearly stated “I’ll follow up more on this and engage with the governance rfc in good faith.”. Just a few minutes after that email, at 1:01pm PDT, Marty also posted a public GitHub comment, where he agreed to participate in the proposed governance process and stated “I’m committed to find the right governance model that works for us all. More to come.” Update: screenshot of comment removed and replaced with link, since the comment appears to still be visible (at least to logged out users) on GitHub.

Given Marty’s claims, the sudden permission deletions made no sense. Worried about the possibility of hacked accounts or some sort of social engineering, I took action as the primary on-call engineer to lock down the AWS account and prevent any actions by possible attackers. I did not change the email addresses on any accounts, leaving them all owned by a team-shared email at rubycentral.org, to ensure the organization retained overall control of the accounts, even if individuals were somehow taking unauthorized actions.

Within a couple of days, Ruby Central made an (unsigned) public statement, and various board members agreed to talk directly to maintainers. At that point, I realized that what I thought might have been a malicious takeover was both legitimate and deliberate, and Marty would never “fix the permissions structure”, or “follow up more” as he said.

Once I understood the situation, I backed off to let Ruby Central take care of their “security audit”. I left all accounts in a state where they could recover access. I did not alter, or try to alter, anything in the Ruby Central systems or GitHub repository after that. I was confident, at the time, that Ruby Central’s security experts would quickly remove all outside access.

My confidence was sorely misplaced.

Almost two weeks later, someone asked if I still had access and I discovered (to my great alarm), that Ruby Central’s “security audit” had failed. Ruby Central also had not removed me as an “owner” of the Ruby Central GitHub Organization. They also had not rotated any of the credentials shared across the operational team using the RubyGems 1Password account.

I believe Ruby Central confused themselves into thinking the “Ruby Central” 1Password account was used by operators, and they did revoke my access there. However, that 1Password account was not used by the open source team of RubyGems.org service operators. Instead, we used the “RubyGems” 1Password account, which was full of operational credentials. Ruby Central did not remove me from the “RubyGems” 1Password account, even as of today.

Aware that I needed to disclose this surprising access, but also aware that it was impossible for anyone except former operators to exploit this security failure, I immediately wrote an email to Ruby Central to disclose the problem.

Here is a copy of my disclosure email, in full.

From: André Arko <andre@arko.net>
Subject: Re: RubyGems.org access
Date: September 30, 2025 at 10:23:12 AM PDT
To: Marty Haught <marty@rubycentral.org>

Hi Marty,

It has come to my attention that despite the statements in [your] email, I have had uninterrupted access to RubyGems.org production environments from September 18 until today, September 30, via the root credentials of the Ruby Central AWS account, as well as continued and ongoing access to the full feed of production alerts and logs in DataDog.

It seems that the only permissions I have had removed are from the GitHub organization named "rubygems", which as you know is unrelated to the RubyGems.org production access you mention in your email.

I have also noticed I am still, as of September 30, the owner of the GitHub organizations named "rubycentral" and "rubytogether".

I am unable to transfer the HelpScout or PagerDuty accounts, as you have disabled my andre@rubygems.org Google account.

Please advise as to your desired resolution of this situation.

Thank you,
André Arko

Ruby Central did not reply to this email for over three days.

When they finally did reply, they seem to have developed some sort of theory that I was interested in “access to PII”, which is entirely false. I have no interest in any PII, commercially or otherwise. As my private email published by Ruby Central demonstrates, my entire proposal was based solely on company-level information, with no information about individuals included in any way. Here’s their response, over three days later.

From: Marty Haught <marty@rubycentral.org>
Subject: Re: RubyGems.org access
Date: October 3, 2025 at 6:54:01 PM MDT
To: André Arko <andre@arko.net>

Hi André,

Please confirm that you cannot access the Ruby Central AWS root account credentials, either through the console or by access keys.

In addition, please confirm whether you are in possession of any RubyGems.org production data,  including, but not limited to, server logs, access logs, PII, or other organizational data.

Thank you,
Marty

In addition to ignoring the (huge) question of how Ruby Central failed to secure their AWS Root credentials for almost two weeks, and appearing to only be aware of it because I reported it to them, their reply also failed to ask whether any other shared credentials might still be valid. There were more.

From: André Arko <andre@arko.net>
Subject: Re: RubyGems.org access
Date: October 5, 2025 at 11:59:35 AM PDT
To: Marty Haught <marty@rubycentral.org>

Hi Marty,

Thanks for letting me know you got my email disclosing my unintended access. I’m concerned that security must not be a very high priority for Ruby Central since no one acknowledged my disclosure for more than three days, but I appreciate the confirmation.

As far as I can tell, I can no longer access the Ruby Central AWS root account either through the console or via access keys.

I confirm I did not download or save any production data after your email of September 18, including server logs, access logs, PII, or other organizational data.

However, while checking AWS credentials in order to write this email, I discovered that several other service credentials have not been rotated, and are still valid for production AWS access. That means both myself and the other former operators all still have access to AWS via those previously-shared credentials.

I would appreciate it if you could answer the request from my first email, and reply with your desired resolution for this remaining unintended production access, as well as the GitHub organization ownership.

Thanks,
André

Unbeknownst to me, while I was answering Marty’s email in good faith, Ruby Central’s attorney was sending my lawyer a letter alleging I had committed a federal crime, on the theory that I had “hacked” Ruby Central’s AWS account. On the contrary, my actions were taken in defense of the service that Ruby Central was paying me to support and defend.

With my side of the story told, I’ll leave it to you to decide whether you think it’s true that “Ruby Central remains committed to transparent, responsible stewardship of the RubyGems infrastructure and to maintaining the security and trust that the Ruby ecosystem depends on.”

My time to write is sponsored by Spinel. If your company could use some world-class expertise on gems, Rails, CI, or developer productivity, check out spinel.coop and hire us!

Read the original article

Comments

  • By ChrisArchitect 2025-10-103:35

    Related:

    Rubygems.org AWS Root Access Event – September 2025

    https://news.ycombinator.com/item?id=45530832

  • By mbStavola 2025-10-104:416 reply

    One of the primary justifications given for the takeover was to secure the gems service and offer trustworthy stewardship. Reading this, I don't really get the sense that the new maintainers are really prepared to deliver on either.

    That said, I really don't like the hand waving of the HTTP log thing in this post. Yeah sure, company names aren't as sensitive/radioactive as an SSN or an email, but selling usage data isn't exactly a noble endeavor.

    I don't think anyone comes out of this looking good. Some are worse than others, sure, but this is just a mess from top to bottom.

    • By tetha 2025-10-107:42

      Mh, one of our security admins recently said something that's very fitting to the discussion: If you are removing an employee from a company, and you have to rely on their personal integrity instead of technical controls to avoid problems, you are doing very basic access control wrong. And if you're doing absolute fundamentals like that wrong, how much is your entire information security worth then?

      And reading this, and the other disclosure from Ruby Central, they seem to be handling this maintainer/employee offboarding woefully incompetently at really, really basic levels. Obtaining control to secret management and doing a general secret rotation of management secrets isn't an obscure first step.

    • By plorkyeran 2025-10-104:531 reply

      My primary takeaway from all of this is that I do not want to be depending on infrastructure run by Ruby Central. Maybe it’ll turn out that the previous status quo was even worse and we just got incredibly lucky that it never exploded, but the people now running things have consistently failed to inspire confidence.

      • By adamors 2025-10-106:23

        That is my takeaway as well, this whole saga is a comedy of errors and the butt of the joke is the new RC.

    • By psadauskas 2025-10-1013:32

      Plus, its not a good look for RubyCentral for trying to smear Andre for it, when it is perfectly acceptable within their own Privacy Policy[1]:

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

      [1]: https://rubycentral.org/privacy-notice/

    • By darkwater 2025-10-106:351 reply

      > That said, I really don't like the hand waving of the HTTP log thing in this post

      What "hand waving"? André explicitly mentioned he did not have any log or information.

      • By mbStavola 2025-10-107:003 reply

        No but he was seeking it, from the email in the RubyCentral article and directly from TFA:

        > I have no interest in any PII, commercially or otherwise. As my private email published by Ruby Central demonstrates, my entire proposal was based solely on company-level information, with no information about individuals included in any way.

        Here Andre is downplaying his ask of the logs. Even if Andre didn't get them, the logs were desired. Had Ruby Central acquiesced the logs would've been parsed and sold. Might not be an issue for you but I am frankly not interested in having any data shared or sold like this.

        • By Xylakant 2025-10-107:223 reply

          I don't even understand why RubyCentral included the proposal to use the log data in the post about a security incident. Whatever we may think of the proposal, the only purpose of including it in this place is to smear Andre.

          The incident is clear cut and makes RubyCentral staff look incompetent. They cut off access to 1password and did not even consider that someone may have a copy of the credentials somewhere? As in "maybe in their head"? Rotating shared credentials in such a situation is security 101 and they failed. And when Andre notifies them that they failed, instead of quietly saying "Thanks, we've fixed that", they make it a security incident and include - without any further context - a single email from something that must have been a longer conversation.

          • By mbStavola 2025-10-107:51

            Without more details, it's hard for me to nail down the exact motivations at play here.

            My current read is that RC majorly botched the takeover, demonstrated gaps in security know-how, and then retroactively framed everything as a problem with André. The details of the logs are mostly immaterial to the rest of the claims, but are still suspicious enough to spice up the announcement. I believe this because, at the moment, I don't see anything in the original RC post that wasn't satisfactorily explained by this post.

          • By bigiain 2025-10-107:471 reply

            > I don't even understand why RubyCentral included the proposal to use the log data in the post about a security incident.

            Yeah you do. They're intentionally smearing him. (And they're no better at doing that than they are at security.)

            • By Xylakant 2025-10-1011:201 reply

              Yes, that’s what they do. But I still fail to grasp how that helps them - they still look pretty bad. Worse, actually - if you want to frame Andre as the bad actor, then my next question is “You knew that a bad actor had previous access, why in the name of $deity did you not double check that they have no access?”

              • By GreenWatermelon 2025-10-1611:15

                Because they're woefully incompetent, they thought that would help them.

          • By ____mr____ 2025-10-107:55

            It was probably included as a motive for Andre to keep unauthorized access

        • By deng 2025-10-108:511 reply

          > Had Ruby Central acquiesced the logs would've been parsed and sold.

          Which the privacy policy of RubyCentral allows, so I don't get why they suddenly have ethical problems with that, apart of course from throwing shade on Andre. Parsing logs for company access is what basically everyone does, and frankly, I don't see the problem with getting leads from data like this. That has nothing to do with "selling PII".

          • By skywhopper 2025-10-109:381 reply

            Yes. While I personally don’t like this practice, it is so widespread and there is so much demand for it that it’s not unusual given their privacy policy makes explicit mention of it.

            The best argument you could make is that gem owners should be able to see “who” downloads their gems. If they were self-hosting the packages, they would have that data. Of course, charging for it is the ookier part.

            • By deng 2025-10-1011:04

              Say you provide a service for free and are desperate for corporate sponsorship. Who wouldn't look at what companies are using your service and contact them with "Hey, I'm seeing you are using our service, can we have a chat"? You basically have no other means of contacting companies nowadays without getting into trouble for cold-calling/spamming.

        • By darkwater 2025-10-107:171 reply

          Honestly, I can't really see what you are reading through the lines here. Are you by any chance involved with RubyGems / RubyCentral? In my case, I'm just a bystander and not even a Ruby developer (but I worked in a Ruby company in the past so I know the ecosystem).

          EDIT: oh, you might be referring to the RubyCentral statement. I didn't read the original security incident text, so my bad here. Sorry.

          • By mbStavola 2025-10-107:38

            I am definitely not affiliated with either, moreso my opinion is considerably more negative of the new maintainers (both for the method of takeover and their handling of this incident). Quite frankly, I don't even know why you would even ask if I was.

            I do not feel like I'm reading between any lines here-- Ruby Central directly showed that André Arko asked for the data to sell in order to cover the on-call fees. Yes, they have reason to smear him and shouldn't be trusted, but André confirms that he asked for the logs. None of that is up for debate, these are just the facts!

            What we can argue about is 1) whether this is meaningfully different than what RC does already as noted by their ToS and 2) whether or not company names derived from the HTTP logs is sensitive or whatever. It is my position that neither André nor RC should be selling this sort of usage data, regardless of motivation. Personally I think the monetization of such data is bad in general, but I understand not everyone feels the same. It just gives me the ick.

            EDIT: Immediately after submitting this, I saw that you issued a correction. Bad timing on my part I suppose!

    • By bigiain 2025-10-106:593 reply

      They were all spitballing ideas about how to recover from the DHH-driven dropping of corporate sponsorship dollars, and how too keep the support lights on.

      I think an offer of covering all the 2nd level support costs in return for the right - that Ruby Central's own T&Cs grant - to monetise company usage stats, is a reasonable offer.

      The "other side's" alternative was to steal ownership and control of a whole bunch of volunteer gem authors work at the behest of a different corporate sponsor who was clearly demonstrating they wanted to be able to not only throw their weight around and force policies and priorities on RubyGems/RubyCentral, but also to make it personal by explicitly calling for long term contributors to be removed entirely on a whim.

      • By ksec 2025-10-112:27

        This is interesting, because I would have thought after all the information revealed, at least both sides could be blamed and usage stats is a no - no.

        We all do see things very differently.

      • By prescriptivist 2025-10-113:05

        This is such a strange take. Ruby Central, for better or worse, is the steward of Rubygems/Bundler. If Mike Perham wants to withdraw his funding because he thinks DHH is a white supremacist, then that's fine. But DHH didn't do that, Perham did.

        Arko is not a completely innocent, non-self-interested character here. He has announced a project to end-run the existing rubygems, bundler, etc infrastructure before all this, in the name of "better tooling", but his tooling is solely owned by him and a handful of people that really, really don't like DHH. Controlling this aspect of the ruby toolchain ecosystem is in their own self-interest and overlaps with their deep disdain for the politics and corporate nature of the existing stewards of the ruby toolchain ecosystem. Maybe their approach and stewardship of this fork of the toolchain is more just, secure and equitable, but make no mistake -- they are fighting the same war that DHH and Shopify are, which is who controls the keys to the toolchain. Do you think if Arko, Perham, et. al. had control they would somehow be completely neutral, apolitical stewards of the ecosystem? No! They have made it clear with their money and machinations that they do not want to operate in the same ecosystem as DHH and their politics and ethics are intertwined with their relationship to the ruby community. They are no different than him.

        Meanwhile those of us who just want stability are stuck between two factions who claim righteousness and ownership. I wish they all could be deposed and some more mature non-individual foundation could take over.

      • By phoronixrly 2025-10-109:412 reply

        I blame DHH for all of this. He needs to step up, walk his words back and mend the damage to the Ruby community he has done. Including chipping in with the funding he cost Rubygems.

        • By ljm 2025-10-1011:192 reply

          Everyone is responsible for their own actions and DHH hasn't made anybody do anything. The reactions to his statements, whether you agree with what he said or not, are entirely voluntary.

          What it does reveal is the fragility of a community that can seemingly be disrupted because of a single controversial blog post from a guy known to be controversial. This has counter-intuitively elevated DHH's position to that of a lynchpin, accentuating his importance as opposed to pressing him into obscurity.

          I personally found DHH's take reprehensible and whatever respect I had for the man has all but vanished, but the Ruby community really does like to throw the baby out with the bathwater sometimes.

          • By psadauskas 2025-10-1013:391 reply

            It wasn't DHH's latest awful blog post that made Mike Perham pull Sidekiq's support. It was because Ruby Central invited him back to the last Railsconf, after having kicked him out of Railsconf 2 years prior for his awful blog posts.

            • By ljm 2025-10-1015:29

              I stand corrected on that matter then. The most recent blog coincides with this quite conveniently.

          • By phoronixrly 2025-10-1011:581 reply

            So, let me get this straight, you blame Sidekiq (and others!) for pulling their sponsorship, thus throwing the baby (rubygems.org) with the bath water (the reputational damage they'd get from being associated with Ruby Central and DHH)?

            • By ljm 2025-10-1013:37

              Notably I didn't use the word 'blame' but correctly assigned accountability to the people who made the decisions they did, for whatever reason they had. The parenthetical examples are yours alone, not mine.

              Beyond that, yes...the Ruby community is dramatic and this is not the first time a furore has been made over some inter-community conflict with a bunch of reactionary stuff kicking off.

        • By dismalaf 2025-10-1016:56

          Shopify stepped up with funding. And the community is bringing out pitchforks whining about big tech...

  • By wgjordan 2025-10-106:552 reply

    I think the biggest missing piece in the opposing accounts of this incident is how exactly the production-access removal was communicated. There's a huge gap between how the two posts are framing the clarity of the communications that happened on Sept 18:

    > September 18 2025 18:40 UTC: Ruby Central notifies Mr. Arko, via email, of the board’s decision to remove his RubyGems.org production access, and the termination of his on-call services.

    > Marty Haught sent an email to the team within minutes, at 12:47pm PDT [19:47 UTC?], saying he was (direct quote) “terribly sorry” and “I messed up”. [...] the complete silence from Shan and the board, made it impossible to tell exactly who had been authorized to take what actions. As this situation occurred, I was the primary on-call.

    André also mentioned that he disclosed further remaining production access a few days ago, on Oct 5. Looking forward to Ruby Central's followup post-incident review for this subsequent incident, which they failed to address or mention at all in their initial publication.

    • By skywhopper 2025-10-109:32

      Yeah, given that RC was willing to publish an email from Arko about an unrelated topic in their “security incident review”, it’s unfortunate they aren’t publishing how the access suspension was actually communicated to folks. Sounds like it was sudden enough and weird enough that Arko’s actions in response of locking down the AWS account were totally justified.

    • By emmelaich 2025-10-108:00

      So weird that Marty is using corporate speak to someone who I presume he's been working with for up to ten years.

      All of them really, not just Marty H.

HackerNews