141–150 of 179 posts
They buried the lede... Arko wanted a copy of the HTTP Access logs from rubygems.org so his consultancy could monetize the data, after RC determined they didn't really have the budget for secondary on-call. Then after they removed him as a maintainer he logged in and changed the AWS root password.
They buried the lede... Arko wanted a copy of the HTTP Access logs from rubygems.org so his consultancy could monetize the data, after RC determined they didn't really have the budget for secondary on-call. Then after they removed him as a maintainer he logged in and changed the AWS root password.
> failed to rotate the AWS root account credentials ... stored in a shared enterprise password manager Unfortunately, many enterprises follow the poor practice of storing shared credentials in a shared password manager without rotating them when an employee with prior access leaves the company.
Earlier quoted context omitted.
Thinking about this a bit more... it sure is interesting that around the time of a competing project launch that something just happens which might reasonably completely compromise trust in the previous incumbent, isn't it? Odd!
how can you trust gem.coop isn't already mining request logs + IPs to try and monetize lists of companies using specific packages & versions — besides the privacy/ethical concerns it is super useful data for hackers looking for vulnerable apps no single person should have Github owner + AWS root password for a major language's package manager and ecosystem just sitting around on their laptop while they fly around to…
They buried the lede... Arko wanted a copy of the HTTP Access logs from rubygems.org so his consultancy could monetize the data, after RC determined they didn't really have the budget for secondary on-call. Then after they removed him as a maintainer he logged in and changed the AWS root password.
What a truly wild situation. In a certain sense this post justifies why RC wanted so badly to take ownership - I mean, here you have a maintainer who clearly has a desire to sell user data to make a buck - but the way it all played out with terrible communication and rookie mistakes on revoking access undermines faith in RC's ability to secure the service going forward. Not to mention no explanation here of who legal…
Presuming, as a group full of security peers kibitzing about this in a chat right now all do, that the "unauthorized actor" here is Andre Arko, this is Ruby Central pretty directly accusing Arko of having hacked Rubygems.org; it depicts what seems to be a black letter 18 USC 1030 violation. Any part of this narrative could be false, but I don't see a way to read it and take it as true where Arko's actions would be OK…
1. Try to get in touch, quickly, with someone with the power to fix it and explain what needs to be rotated.
2. Absent 1, especially if it cannot be done quickly, rotate the credentials personally to get them back to a controlled state (by someone who actually understands the security implications) with the intent to hand them off. Especially if you still _think_ of yourself as responsible for the infrastructure, this is a no-brainer compared to letting anyone else who might be in the same “should have lost access but didn’t, due to negligence” maintain access.
Not a legal defense, but let’s not be too hasty to judge.
Earlier quoted context omitted.
What a truly wild situation. In a certain sense this post justifies why RC wanted so badly to take ownership - I mean, here you have a maintainer who clearly has a desire to sell user data to make a buck - but the way it all played out with terrible communication and rookie mistakes on revoking access undermines faith in RC's ability to secure the service going forward. Not to mention no explanation here of who legal…
I can give benefit of the doubt that making a proposal to monetize user data is a poorly-considered, bottom-scraping effort to find a replacement funding source for the on call work. Most of us would not consider it, but I think it should be ok to occasionally pitch some bad ideas, all else being equal and lacking full context. But messing with the credentials crosses an ethical line that isn't excused no matter how…
1. RC takes over GitHub Repository and locks everyone out
2. Arko takes over RubyGems server and locks everyone out.
EDIT: Missed their email notification revoking his production access. Yeah looks like they could have a legal basis.
Earlier quoted context omitted.
I can give benefit of the doubt that making a proposal to monetize user data is a poorly-considered, bottom-scraping effort to find a replacement funding source for the on call work. Most of us would not consider it, but I think it should be ok to occasionally pitch some bad ideas, all else being equal and lacking full context. But messing with the credentials crosses an ethical line that isn't excused no matter how…
I can only assume it is silly revenge seeking behavior. Look at how symmetrical it is: 1. RC takes over GitHub Repository and locks everyone out 2. Arko takes over RubyGems server and locks everyone out. He was an authorized actor right up until they tried to remove him, but they forgot to revoke his access credentials. I wonder if legally-speaking he was even considered unauthorized. EDIT: Missed their email notific…
Seems someone took it a step further and changed the locks too.
I'd recommend to people to wait for a response - RubyCentral spins up a gazillion accusations right now and has been in the last days (and, it is also incomplete, because why did they fire every dev here and placed Marty Haught in charge specifically? They never were able to logically explain this; plus, why didn't they release this write-up before? It feels very strange to wait here; they could have clarified things…
https://andre.arko.net/2025/10/09/the-rubygems-security-inci...
I'd recommend to people to wait for a response - RubyCentral spins up a gazillion accusations right now and has been in the last days (and, it is also incomplete, because why did they fire every dev here and placed Marty Haught in charge specifically? They never were able to logically explain this; plus, why didn't they release this write-up before? It feels very strange to wait here; they could have clarified things…
> I'd recommend to people to wait for a response https://andre.arko.net/2025/10/09/the-rubygems-security-inci...