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…
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.
"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."
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"
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 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…
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"
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.
Based; mandatory MFA is annoying as hell.
So the solution is none? Not better MFA tools?
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."
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.
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"
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...
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.