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.
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…
"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."
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.
I hate Microsoft's approach which puts its own MFA app as somehow better than standard TOTP. I want to use standard apps like authy or aegis or even apple passwords app which doesn't require my phone to be connected to the Internet.
I sincerely do not agree with their premise at all.
Coming back to OP, better MFA tools and allowing people to NOT display the verified checkmark should solve the issue? At least talk to the person and hear their grievances.
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?
"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?).
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.
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.
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.
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
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"
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.
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
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)
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.
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.
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.
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.
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/
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…
It would be nice if OSS maintainers would start charging for extra security features like signed releases at least $1k/y per project.
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.
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.
It would be better if he did kill it.
Ironically, my main memory from back when I used unicorn was that the supported way to stop the server was to run "killall unicorns"
[flagged]
So the solution is none? Not better MFA tools?
I hate Microsoft's approach which puts its own MFA app as somehow better than standard TOTP. I want to use standard apps like authy or aegis or even apple passwords app which doesn't require my phone to be connected to the Internet.
I sincerely do not agree with their premise at all.
Coming back to OP, better MFA tools and allowing people to NOT display the verified checkmark should solve the issue? At least talk to the person and hear their grievances.
As noted, the maintainer is eccentric. They will not do anything that requires JavaScript.
Good work to everybody involved. Looking into donating now.
Ruby/Rails and its ecosystem continues to prove itself the practical, boring, reliable workhorse option.
Boring? Not really.
My 2c: it is more enjoyable than the Js/Ts ecosystem we have today.
I think they meant boring in a positive way, as in "choose boring technology."
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?
"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...
Ta! Heard about them but will definitely check them out.
God, this gave me flashbacks to people saying the same thing, except with perl.
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.
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.
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.
Please note though that the team supporting rubygems is not the team that supports the Rails framework. These are different projects.
[dead]
Welcome to the ecosystem o/
Reading this, I couldn't help but think these guys really know where their towel is. The opposite of enshittification?
Isn't this because there isn't a for profit company running this? They don't have to enshittify to make money for investors.
But still lacks mandatory gem signing. I also wonder how many malicious gems were published prior to this.
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
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"
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.
It’s compatible if reproducible builds are used: https://fdroid.gitlab.io/jekyll-fdroid/docs/Reproducible_Bui...
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...
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)
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.
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.
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.
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.