How Rubygems.org Protects Oss Infrastructure

Posted4 months agoActive4 months ago

hahahacorn

157 points

35 comments

blog.rubygems.orgSecuritystory

informativepositive

Debate

20/100

Open-Source SecurityRubygemsInfrastructure Protection

Key topics

Open-Source Security

Rubygems

Infrastructure Protection

The RubyGems.org team's dedication to protecting open-source infrastructure has sparked a lively discussion about the Ruby on Rails ecosystem's reliability and productivity. Commenters rave about the framework's ability to get things working quickly, with some even calling it the "practical, boring, reliable workhorse option" - a nod to the "choose boring technology" mantra. While some users nostalgically compare Ruby/Rails to other ecosystems like Perl or JavaScript/TypeScript, others enthusiastically recommend it, sparking requests for tutorials and learning resources. As one commenter clarifies, the RubyGems team is distinct from the Rails framework team, adding a layer of nuance to the conversation.

Snapshot generated from the HN discussion

Discussion Activity

Moderate engagement

First comment

Peak period

8-10h

Avg / period

Comment distribution32 data points

Loading chart...

Based on 32 loaded comments

Key moments

01Story posted
Aug 25, 2025 at 2:02 PM EDT
4 months ago
Step 01
02First comment
Aug 25, 2025 at 4:52 PM EDT
3h after posting
Step 02
03Peak activity
9 comments in 8-10h
Hottest window of the conversation
Step 03
04Latest activity
Aug 26, 2025 at 8:05 AM EDT
4 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (35 comments)

Showing 32 comments of 35

IFC_LLC

4 months ago

2 replies

Interesting how the Internet turned into a place where you have to search for a long time in order to find something valuable. In this case - you have a dedicated team that sits there and diligently works on the quality of their product.

I should have turned to RoR 3 years ago.

ecshafer

4 months ago

1 reply

Ruby on Rails is the most productive web framework I have ever worked in. RoR + the Ecosystem is really geared towards getting things working quickly asap and its great.

IFC_LLC

4 months ago

1 reply

Oh, I will. I will. I'm quite amazed by the dedication of the team that supports the framework and how good of a care they have been taking about it.

Funny enough, one of my first articles I've ever written on the internet was about RoR. It's dated 1st of March 2010. Gosh, It's been 15 years. At that moment I used https://rubyforge.org to download RoR, Instant Rails for Windows and Aptana as an IDE. 15 years have gone by, but RoR is here just like PHP is.

So it's getting better and better.

jrochkind1

4 months ago

Please note though that the team supporting rubygems is not the team that supports the Rails framework. These are different projects.

infamouscow

4 months ago

Welcome to the ecosystem o/

cosmic_cheese

4 months ago

3 replies

Good work to everybody involved. Looking into donating now.

Ruby/Rails and its ecosystem continues to prove itself the practical, boring, reliable workhorse option.

princevegeta89

4 months ago

1 reply

Boring? Not really.

My 2c: it is more enjoyable than the Js/Ts ecosystem we have today.

woodruffw

4 months ago

I think they meant boring in a positive way, as in "choose boring technology."

f4stjack

4 months ago

1 reply

Agreed. Time and time again, I wished I'd knew Ruby and/or RoR. Do you know any good (and "boring" as in time-tested & practical) tutorials/learning resources?

janfoeh

4 months ago

1 reply

"Programming Ruby" [0] ("the pickaxe book") and "Agile Web Development with Rails" [1], both from Pragmatic Programmers.

I learned Ruby and Rails through them in the late 2000's; they are still being released as new editions. It has been a while since I bought new books from PragProg, but they used to have a recurring sale of ~40% off around late autumn (thanksgiving?).

[0] https://pragprog.com/titles/ruby5/programming-ruby-3-3-5th-e...

[1] https://pragprog.com/titles/rails8/agile-web-development-wit...

f4stjack

4 months ago

Ta! Heard about them but will definitely check them out.

wredcoll

4 months ago

God, this gave me flashbacks to people saying the same thing, except with perl.

burnt-resistor

4 months ago

2 replies

But still lacks mandatory gem signing. I also wonder how many malicious gems were published prior to this.

firesteelrain

4 months ago

2 replies

Even if it was mandatory, if it doesn’t get signed by a trusted CA then it is still self signed. RubyGems would have to reject all. But signing alone does not prevent malicious code

mdaniel

4 months ago

3 replies

AIUI, the threat model isn't "self signed versus not," I would suspect the modern threat model is "current release signed by the same cert as prior release". The Android ecosystem is backed by this threat model, and (zip parsing nonsense aside) seems to be doing well with it. Even F-Droid, which runs their own signing stack, participates although it is not compatible with the Play Store distribution mechanism due to "who owns the signing key"

notpushkin

4 months ago

1 reply

It’s compatible if reproducible builds are used: https://fdroid.gitlab.io/jekyll-fdroid/docs/Reproducible_Bui...

mdaniel

4 months ago

1 reply

That's interesting, thanks for drawing my attention to it. I would need to go spelunking around to see how they reference an .apk from the Play Store, which I got the impression used crazypants gRPC shenanigans for building download URLs

---

I went sniffing around and while I didn't go through all tens of pages, it sure does seem like that's only used for non-Play Store style verification, and thus my assertion seems to stand https://gitlab.com/search?group_id=28397&project_id=36528&se...

notpushkin

4 months ago

Oh, I got it – apparently Play App Signing is mandatory now: https://developer.android.com/studio/publish/preparing#publi...

This makes it a bit trickier, yeah, though if the developer can get an APK signed with their Play App Signing key, and the app in question is a reproducible build, they can then publish it in F-Droid: https://fdroid.gitlab.io/jekyll-fdroid/docs/Reproducible_Bui...

(and probably they can upload it to their GitHub releases or something so that F-Droid picks it up from there)

33a

4 months ago

Signing doesn't protect against maintainer sabotage, but it could theoretically help if the registry were ever compromised. It mainly works to prevent MITM type attacks on the package distribution itself.

In the case of central package managers like rails/npm/cargo/etc., these benefits are very speculative, but there is probably some merit to adopting this approach in distributed ecosystems like go.

firesteelrain

4 months ago

I’m not convinced key continuity is very useful in the gem ecosystem. The Android model is built on a controlled store where developers rarely rotate keys and Google enforces policies. RubyGems is an open registry where gems are often abandoned, transferred, or sold. In that setting continuity can just mean consistent sabotage if a maintainer goes rogue or loses their key. Without a trust anchor or enforced identity checks, continuity is at best a weak signal.

lmm

4 months ago

1 reply

There are plenty of ways for malicious code to make it out even if there is a full trust path. But every step raises the cost. Even if a developer just signs their releases with a self-signed key, it gives people a chance to notice the key has changed.

firesteelrain

4 months ago

Good point. I was referring to signing as a way to prevent malicious code from being submitted in of itself. Not packages being stolen and similar or same package names being used.

halostatue

4 months ago

I think that trusted publishing has had a bigger impact than the gem signing that was introduced years ago and never worked well because the infrastructure wasn't present.

decasia

4 months ago

3 replies

About this, I noticed a relatively prominent gem maintainer publicly announcing his efforts to avoid rubygems security measures:

> I'll try to get a unicorn 7.x release soon but tests take forever to run on ancient HW and I need to ration releases to keep download counts low in order to stay under the MFA threshold on Rubygems.org

> I don't ever want users viewing me as trustworthy nor liable for anything I do, so no MFA nor sigs from me; just source + docs :>

If I understand correctly - the idea is that the unicorn maintainer does not want to be viewed as trustworthy and is avoiding MFA and signatures because they could build trust that isn't, in this case, wanted.

https://yhbt.net/unicorn-public/20231214230933.M299458@dcvr/

jrochkind1

4 months ago

1 reply

I feel like the unicorn maintainer(s) have been trying to kill unicorn for a while, making decisions meant to be user-hostile. I'm not sure why they are maintaining it at all.

halostatue

4 months ago

1 reply

It would be better if he did kill it.

cortesoft

4 months ago

Ironically, my main memory from back when I used unicorn was that the supported way to stop the server was to run "killall unicorns"

halostatue

4 months ago

1 reply

The maintainer is eccentric. He refuses to use anything that runs JavaScript out of a sense of "Free Software Purity", which means that he cannot use most of the ecosystem to which Ruby has migrated.

He has only contributed to Ruby via the ruby-core mailing list (he does not use the RubyMine interface which backs ruby-core) and the main Ruby git repo hosted by the Ruby team, never anything on GitHub.

I'm sort of surprised that the RubyGems MFA threshold hasn't been updated (it was 180M total downloads in 2022; my gems combined have > 2.5B downloads, so I was never not going to pass the threshold), but he's under 70M downloads shy and each release gets about 15M downloads or so.

I think that his position is irresponsible in today's threat environment, but given the amount of work that I'm doing for OSS maintenance that's just responding to bloody Dependabot updates…

haute_cuisine

4 months ago

It would be nice if OSS maintainers would start charging for extra security features like signed releases at least $1k/y per project.

drzaiusx11

4 months ago

From the unicorn readme:

"unicorn is an HTTP server for Rack applications that has done decades of damage to the entire Ruby ecosystem due to its ability to tolerate (and thus encourage) bad code."

Might have something to do with it.

Dan42

4 months ago

1 reply

Reading this, I couldn't help but think these guys really know where their towel is. The opposite of enshittification?

cortesoft

4 months ago

Isn't this because there isn't a for profit company running this? They don't have to enshittify to make money for investors.

3 more comments available on Hacker News

View full discussion on Hacker News

ID: 45016794Type: storyLast synced: 11/20/2025, 5:51:32 PM

Want the full context?