4 ms·

In some security circles, use of F-Droid is discouraged: https://privsec.dev/posts/android/f-droid-security-issues/ https://privsec.dev/posts/android/f-droid-s

In some security circles, use of F-Droid is discouraged: https://privsec.dev/posts/android/f-droid-security-issues/ https://privsec.dev/posts/android/f-droid-security-issues/ https://www.privacyguides.org/en/android/obtaining-apps/#f-droid https://www.privacyguides.org/en/android/obtaining-apps/#f-d... My understanding is that this largely stems from the fact that F-Droid compiles and signs all the apps on behalf of the application developers, so there is a loss of control there. Some will say that this is what redistributable builds are for, but in my experience they are not actively/widely verified even if they do support it, especially publicly.

cynicalsecurity 2y ago
Security is a while different topic. The article is about the positive aspects of demopolisation, freedom and competition.
lupusreal 2y ago
Packager middlemen give me a layer of protection against application developers selling out to malware companies.
- majorchord 2y ago
  I say that possibility is canceled out because those layers of protection also provide avenues for additional bad actors and even more possibility of places to inject malware/compromises.
  - lupusreal 2y ago
    Examples of that? Debian has about three decades of history, have any of their packagers ever sold out?
    - majorchord 2y ago
      I was more referring to supply chain attacks and intentional backdoors, which have happened multiple times in the past. Debian servers have also been hacked before.
  - g-b-r 2y ago
    They might provide additional avenues, but they remove others, so it's hard to assess what's safer (I'd lean towards F-Droid-like solutions). The best of both worlds is where both the developer and a third party certify the builds, as happens with F-Droid's reproducible builds. On Android you're still left on deciding whose signature to put on the binary, however (I'd prefer one from the third party, differently from what happens with F-Droid reproducible builds).
    - majorchord 2y ago
      It would be nice if both parties could sign the binary. My biggest issue with reproducible builds is that not every project supports it, and many that do aren't being verified (like Signal).
- NotPractical 2y ago
  F-Droid already saved me from this: https://liliputing.com/android-app-maker-simple-mobile-tools-acquired-by-zipoapps/ https://liliputing.com/android-app-maker-simple-mobile-tools... I trust F-Droid more than $RANDOM_GITHUB_ACCOUNT.
aniviacat 2y ago
Isn't this the same situation as with linux software repos?
- majorchord 2y ago
  Yes and it is often a source of contention as well, not only for those same reasons but also others. For example, package maintainers often configure the programs differently (see: keepassxc drama) and often the users expect support from the upstream for problems they have no control over, sometimes even causing the upstream to stop development entirely due to the entitlement and abuse of downstream users.
altfredd 2y ago
> F-Droid compiles and signs all the apps on behalf of the application developers At least they are open and honest about it. As opposite to Google, who promised to let developers do the signing, but soon (after gaining worldwide popularity) took over with extremely shoddy justification.
NotPractical 2y ago
The first source you linked is run by GrapheneOS community members so it's slightly biased: https://privsec.dev/about/ https://privsec.dev/about/
- g-b-r 2y ago
  I'd bet good money that Madaidan was Daniel Micay
- aniviacat 2y ago
  Why would GrapheneOS be biased against F-Droid? It's not like they have their own app store. (They have "Apps" but that's not any competition.)
  - NotPractical 2y ago
    There was some drama between the two communities unfortunately. I can't remember the exact details.
noirscape 2y ago
Privacyguides isn't very good in my experience. It's got a real "blind leading the blind" thing going on, where a bunch of half-truths are repeated ad-nauseam because at some point, someone told them that thing X is bad for your privacy. It's probably best exemplified in how they can't seem to stop recommending Brave, even though you're probably better off just loading up literally any other browser that isn't Google Chrome with privacy extensions instead. Practically speaking, you should just assess the following threat model; which is going to be a greater threat to you: * An application developer who can be bought out and have their tools replaced with adware. (Ref. https://news.ycombinator.com/item?id=38505229 https://news.ycombinator.com/item?id=38505229 ) * The F-Droid servers, where the most realistic threat is a rogue actor obtaining the keys. That second one is also mitigated by the fact that F-Droid generally prefers to practice "reproducible signing"; basically they'll distribute the developers apk, not the one on F-Droids buildserver, if the F-Droid release matches the GitHub release (minus the signature obviously), making the signature problem mostly a non-issue. For most people, I'd argue the former (a "surprise update" to insert anti-features[0]) is a greater risk than the latter, so F-Droids model fits them better. The sole exception would be extremely privacy sensitive apps where trusting the developer is more paramount than having the second man in-the-middle that F-Droids maintainers are. (A basic example of that would probably be Signal.) [0]: As defined here, although not all are relevant for users: https://f-droid.org/docs/Anti-Features/ https://f-droid.org/docs/Anti-Features/ , although I'd just add de facto adding pointless microtransactions and subscriptions to this list. They're just not included since F-Droid wouldn't ship them.
davexunit 2y ago
This is part of the longstanding devs vs. distros tug of war. There is a loss of control for the devs, but it's better for the user to have distros like F-Droid. The alleged security benefits feel paternalistic, like the dev knows best so only they should be able to sign binaries. Why someone would get into FOSS development and then get upset when someone exercises their rights to build from source and distribute binaries is baffling to me.
- majorchord 2y ago
  > Why someone would get into FOSS development and then get upset when someone exercises their rights to build from source and distribute binaries is baffling to me. This happens at an alarming rate within the video game emulation community. Many projects (including MAME) have openly expressed deep disdain for any forks existing at all. It's like they think any difference a fork has is a negative thing and then aggressively attack that... as if there is only one way to write software. Some projects have even stopped upstream development entirely, or closed the source or changed their license... just over forks. License violations (including GPL as well as non-commercial ones) are also rampant there.
jlkuester7 2y ago
Do these same concerns still pertain to dev-hosted F-Droid repos? (E.g. I am thinking of how I install Bitwarden from the their own repo: https://mobileapp.bitwarden.com/fdroid/ https://mobileapp.bitwarden.com/fdroid/) IMHO, one of the best parts about the F-Droid ecosystem is its openness. Security models are not a one-size-fits-all and it is important to me to have access to software from multiple sources.
- g-b-r 2y ago
  Dev-hosted repos are the same as downloading from the developer's site, they offer none of F-Droid's guarantees

cynicalsecurity 2y ago

Security is a while different topic. The article is about the positive aspects of demopolisation, freedom and competition.

lupusreal 2y ago

Packager middlemen give me a layer of protection against application developers selling out to malware companies.

majorchord 2y ago
I say that possibility is canceled out because those layers of protection also provide avenues for additional bad actors and even more possibility of places to inject malware/compromises.
- lupusreal 2y ago
  Examples of that? Debian has about three decades of history, have any of their packagers ever sold out?
  - majorchord 2y ago
    I was more referring to supply chain attacks and intentional backdoors, which have happened multiple times in the past. Debian servers have also been hacked before.
- g-b-r 2y ago
  They might provide additional avenues, but they remove others, so it's hard to assess what's safer (I'd lean towards F-Droid-like solutions). The best of both worlds is where both the developer and a third party certify the builds, as happens with F-Droid's reproducible builds. On Android you're still left on deciding whose signature to put on the binary, however (I'd prefer one from the third party, differently from what happens with F-Droid reproducible builds).
  - majorchord 2y ago
    It would be nice if both parties could sign the binary. My biggest issue with reproducible builds is that not every project supports it, and many that do aren't being verified (like Signal).
NotPractical 2y ago
F-Droid already saved me from this: https://liliputing.com/android-app-maker-simple-mobile-tools-acquired-by-zipoapps/ https://liliputing.com/android-app-maker-simple-mobile-tools... I trust F-Droid more than $RANDOM_GITHUB_ACCOUNT.

aniviacat 2y ago

Isn't this the same situation as with linux software repos?

majorchord 2y ago
Yes and it is often a source of contention as well, not only for those same reasons but also others. For example, package maintainers often configure the programs differently (see: keepassxc drama) and often the users expect support from the upstream for problems they have no control over, sometimes even causing the upstream to stop development entirely due to the entitlement and abuse of downstream users.

altfredd 2y ago

> F-Droid compiles and signs all the apps on behalf of the application developers At least they are open and honest about it. As opposite to Google, who promised to let developers do the signing, but soon (after gaining worldwide popularity) took over with extremely shoddy justification.

NotPractical 2y ago

The first source you linked is run by GrapheneOS community members so it's slightly biased: https://privsec.dev/about/ https://privsec.dev/about/

g-b-r 2y ago
I'd bet good money that Madaidan was Daniel Micay
aniviacat 2y ago
Why would GrapheneOS be biased against F-Droid? It's not like they have their own app store. (They have "Apps" but that's not any competition.)
- NotPractical 2y ago
  There was some drama between the two communities unfortunately. I can't remember the exact details.

noirscape 2y ago

Privacyguides isn't very good in my experience. It's got a real "blind leading the blind" thing going on, where a bunch of half-truths are repeated ad-nauseam because at some point, someone told them that thing X is bad for your privacy. It's probably best exemplified in how they can't seem to stop recommending Brave, even though you're probably better off just loading up literally any other browser that isn't Google Chrome with privacy extensions instead. Practically speaking, you should just assess the following threat model; which is going to be a greater threat to you: * An application developer who can be bought out and have their tools replaced with adware. (Ref. https://news.ycombinator.com/item?id=38505229 https://news.ycombinator.com/item?id=38505229 ) * The F-Droid servers, where the most realistic threat is a rogue actor obtaining the keys. That second one is also mitigated by the fact that F-Droid generally prefers to practice "reproducible signing"; basically they'll distribute the developers apk, not the one on F-Droids buildserver, if the F-Droid release matches the GitHub release (minus the signature obviously), making the signature problem mostly a non-issue. For most people, I'd argue the former (a "surprise update" to insert anti-features[0]) is a greater risk than the latter, so F-Droids model fits them better. The sole exception would be extremely privacy sensitive apps where trusting the developer is more paramount than having the second man in-the-middle that F-Droids maintainers are. (A basic example of that would probably be Signal.) [0]: As defined here, although not all are relevant for users: https://f-droid.org/docs/Anti-Features/ https://f-droid.org/docs/Anti-Features/ , although I'd just add de facto adding pointless microtransactions and subscriptions to this list. They're just not included since F-Droid wouldn't ship them.

davexunit 2y ago

This is part of the longstanding devs vs. distros tug of war. There is a loss of control for the devs, but it's better for the user to have distros like F-Droid. The alleged security benefits feel paternalistic, like the dev knows best so only they should be able to sign binaries. Why someone would get into FOSS development and then get upset when someone exercises their rights to build from source and distribute binaries is baffling to me.

majorchord 2y ago
> Why someone would get into FOSS development and then get upset when someone exercises their rights to build from source and distribute binaries is baffling to me. This happens at an alarming rate within the video game emulation community. Many projects (including MAME) have openly expressed deep disdain for any forks existing at all. It's like they think any difference a fork has is a negative thing and then aggressively attack that... as if there is only one way to write software. Some projects have even stopped upstream development entirely, or closed the source or changed their license... just over forks. License violations (including GPL as well as non-commercial ones) are also rampant there.

jlkuester7 2y ago

Do these same concerns still pertain to dev-hosted F-Droid repos? (E.g. I am thinking of how I install Bitwarden from the their own repo: https://mobileapp.bitwarden.com/fdroid/ https://mobileapp.bitwarden.com/fdroid/) IMHO, one of the best parts about the F-Droid ecosystem is its openness. Security models are not a one-size-fits-all and it is important to me to have access to software from multiple sources.

g-b-r 2y ago
Dev-hosted repos are the same as downloading from the developer's site, they offer none of F-Droid's guarantees