3 ms·

Fdroid owning the signing keys for the apps of other developers was always a security mistake. This announcement should make them realize this instead of doubli

Fdroid owning the signing keys for the apps of other developers was always a security mistake. This announcement should make them realize this instead of doubling down on it.

beeflet 1y ago
No it isn't. I trust fdroid more than random app developers.
someNameIG 1y ago
Why? Isn't that how most linux distros do their repos?
- charcircuit 1y ago
  It is, but Linux distros are not the pinnacle of security. They use a security model decades out of date, so they are not something you should try and copy off of.
  - someNameIG 1y ago
    But has there been many actual reported security issues due to it? Like has anyone downloaded malware fro the official Ubuntu or Fedora repos?
    - charcircuit 1y ago
      CVE-2008-0166 a maintainer added a security bug to openssl and it was distributed to many machines resulting in many weak ssh keys being generated. Between openssl releasing their library and it making its way to end user's machines a security vulnerability was injected.
      - AAAAaccountAAAA 1y ago
        That was literally before the first production Android phone become available. Does not seem to be a particularly common occurance. Though due to the current world situation, supply chain attacks might admittedly become more common.
  - array_key_first 1y ago
    Sure, but the reality is that your average Linux distro repo has WAY less malware than the play store. Your security model doesn't matter much when the people doing the security are bad actors. Google is a malicious actor - they actively incentivize malware on the play store.
deivid 1y ago
Fdroid need to build the apps themselves to ensure they match the upstream source. They've moved away from owning the keys by recommending reproducible builds, however reproducible builds are hard and many app authors don't do it
_flux 1y ago
They have a reason mentioned by others, however what was news to me that the Google Android application registration also requires them! https://developer.android.com/developer-verification#register-your-apps https://developer.android.com/developer-verification#registe... says Register your apps: You'll need to prove you own your apps by providing your app package name and app signing keys. Couldn't this also be verified with a challenge-response signing, using the key? Why should Google have the ability to sign apps of the developer, instead of it being an end-to-end deal? Perhaps they need to have the ability to slip in some additional code if the government so wishes? Or perhaps there is actually a legit reason for Google to have those keys or I have a misunderstanding of the requirement? Maybe F-Droid could relax that requirement if it were feasible to do reproducible builds. Then the developer could just deliver the package to F-Droid, F-Droid would check that it matches what they have, and then publish it. But that's probably not going to happen. Alternatively some deeper proof-based certificate could be devised, but that's even less likely to happpen..
- charcircuit 1y ago
  They already have required it since 2021. https://support.google.com/googleplay/android-developer/answer/9842756 https://support.google.com/googleplay/android-developer/answ... The main benefits is that Google is able to optimize downloads for individual devices. It also makes the situation where the developer loses a private key and then they can no longer push anymore updates to their app no longer possible. I'm not a fan of this approach of essentially allowing Google free reign to use your key for deploying jpdates.
  - iggldiggl 1y ago
    > The main benefits is that Google is able to optimize downloads for individual devices. I don't think Google does the more invasive bit of stripping out non-applicable code protected by API level checks (Build.VERSION.SDK_INT), and otherwise, the simple splitting up of native libraries by ABI, graphics resources by display density and string resources by language (plus any additionally defined code modules for on-demand download of optional features) could have been done wholly locally, too, including signing.

Fdroid owning the signing keys for the apps of other developers was always a security mistake. This announcement should make them realize this instead of doubling down on it.

beeflet 1y ago

No it isn't. I trust fdroid more than random app developers.

someNameIG 1y ago

Why? Isn't that how most linux distros do their repos?

charcircuit 1y ago
It is, but Linux distros are not the pinnacle of security. They use a security model decades out of date, so they are not something you should try and copy off of.
- someNameIG 1y ago
  But has there been many actual reported security issues due to it? Like has anyone downloaded malware fro the official Ubuntu or Fedora repos?
  - charcircuit 1y ago
    CVE-2008-0166 a maintainer added a security bug to openssl and it was distributed to many machines resulting in many weak ssh keys being generated. Between openssl releasing their library and it making its way to end user's machines a security vulnerability was injected.
    - AAAAaccountAAAA 1y ago
      That was literally before the first production Android phone become available. Does not seem to be a particularly common occurance. Though due to the current world situation, supply chain attacks might admittedly become more common.
- array_key_first 1y ago
  Sure, but the reality is that your average Linux distro repo has WAY less malware than the play store. Your security model doesn't matter much when the people doing the security are bad actors. Google is a malicious actor - they actively incentivize malware on the play store.

deivid 1y ago

Fdroid need to build the apps themselves to ensure they match the upstream source. They've moved away from owning the keys by recommending reproducible builds, however reproducible builds are hard and many app authors don't do it

_flux 1y ago

They have a reason mentioned by others, however what was news to me that the Google Android application registration also requires them! https://developer.android.com/developer-verification#register-your-apps https://developer.android.com/developer-verification#registe... says Register your apps: You'll need to prove you own your apps by providing your app package name and app signing keys. Couldn't this also be verified with a challenge-response signing, using the key? Why should Google have the ability to sign apps of the developer, instead of it being an end-to-end deal? Perhaps they need to have the ability to slip in some additional code if the government so wishes? Or perhaps there is actually a legit reason for Google to have those keys or I have a misunderstanding of the requirement? Maybe F-Droid could relax that requirement if it were feasible to do reproducible builds. Then the developer could just deliver the package to F-Droid, F-Droid would check that it matches what they have, and then publish it. But that's probably not going to happen. Alternatively some deeper proof-based certificate could be devised, but that's even less likely to happpen..

charcircuit 1y ago
They already have required it since 2021. https://support.google.com/googleplay/android-developer/answer/9842756 https://support.google.com/googleplay/android-developer/answ... The main benefits is that Google is able to optimize downloads for individual devices. It also makes the situation where the developer loses a private key and then they can no longer push anymore updates to their app no longer possible. I'm not a fan of this approach of essentially allowing Google free reign to use your key for deploying jpdates.
- iggldiggl 1y ago
  > The main benefits is that Google is able to optimize downloads for individual devices. I don't think Google does the more invasive bit of stripping out non-applicable code protected by API level checks (Build.VERSION.SDK_INT), and otherwise, the simple splitting up of native libraries by ABI, graphics resources by display density and string resources by language (plus any additionally defined code modules for on-demand download of optional features) could have been done wholly locally, too, including signing.