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.
