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.
