4 ms·

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 p

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 1y ago
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 1y ago
  It’s compatible if reproducible builds are used: https://fdroid.gitlab.io/jekyll-fdroid/docs/Reproducible_Builds/ https://fdroid.gitlab.io/jekyll-fdroid/docs/Reproducible_Bui...
  - mdaniel 1y ago
    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&search=binaries&search_code=true https://gitlab.com/search?group_id=28397&project_id=36528&se...
    - notpushkin 1y ago
      Oh, I got it – apparently Play App Signing is mandatory now: https://developer.android.com/studio/publish/preparing#publishing-keys 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_Builds/#publishing-apks-with-the-upstream-developers-signature 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 1y 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 1y 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 1y ago
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 1y 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.

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 1y ago

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 1y ago
It’s compatible if reproducible builds are used: https://fdroid.gitlab.io/jekyll-fdroid/docs/Reproducible_Builds/ https://fdroid.gitlab.io/jekyll-fdroid/docs/Reproducible_Bui...
- mdaniel 1y ago
  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&search=binaries&search_code=true https://gitlab.com/search?group_id=28397&project_id=36528&se...
  - notpushkin 1y ago
    Oh, I got it – apparently Play App Signing is mandatory now: https://developer.android.com/studio/publish/preparing#publishing-keys 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_Builds/#publishing-apks-with-the-upstream-developers-signature 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 1y 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 1y 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 1y ago

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 1y 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.