Submit to Official F-Droid repo(f-droid.org)

[carbongreat13]

Please agree to the following

• [X] I have searched existing issues for duplicates
• [X] I agree to follow this project's Code of Conduct

Summary

Publish in the official F-Droid repository, not the Cryptomator F-Dorid repository.

Motivation

The official F-Droid repository is known for its concern for security and privacy. If Cryptomator is there, it will give a good impression of security and privacy-conscious software.

Considered Alternatives

No response

Anything else?

No response

[SailReal]

We'd love to bring Cryptomator into the official F-Droid repository. There is already a packaging request https://gitlab.com/fdroid/rfp/-/issues/713 but unfortunately, we are not making any progress here, as we need API keys to access some cloud storage and cannot simply publish those keys. It's also not possible to safely load them from anywhere later on without an account.

[ghost]

as we need API keys to access some cloud storage and cannot simply publish those keys.

Instead of keeping the API key in the binary, why don't users register themselves as developers and enter the API key they have obtained into the application for use? like rclone.

[overheadhunter]

why don't users register themselves as developers and enter the API key

I can not find it right now, but this exact topic has been discussed in a different issue as well (feel free to mark as duplicate if found). Our answer to this was essentially this:

1. there are users able to register as developers and create api keys
2. there are users not able to run a single-command Gradle build
3. however, the intersection between 1. and 2. is most certainly insignificantly small

Therefore we decided that creating a UI for entering keys is a disproportionate effort, especially when the main argument is all about security conscious people who want to build software themselves anyway.

While we allow building the app locally, the only funding for continuous development depends on people "too lazy" to go this extra mile. But this is yet a different topic and must not be mixed (and has been discussed in other issues as well).

[SailReal]

I didn't find the conversation either but I'll close the issue anyway, since @overheadhunter has summarised all the arguments here.

We'll definitely keep an eye on the official F-Droid repo and if there's another way to provide client credentials into the repo like e.g. GitHub secrets, we'll take another look at it.

[SailReal]

As discussed in https://gitlab.com/fdroid/rfp/-/issues/713, an org.cryptomator.light variant will be added to the F-Droid main repo, which only uses the cloud services that do not require an API key. In this version, there is also a note in the cloud list that there are other variants of the app with more cloud services. If you click on the link in this note, you land in a new activity in which you can

1. add the F-droid repo with a click

   val intent = context.packageManager.getLaunchIntentForPackage("org.fdroid.fdroid")
   intent.data = Uri.parse("https://static.cryptomator.org/android/fdroid/repo?fingerprint=F7C3EC3B0D588D3CB52983E9EB1A7421C93D4339A286398E71D7B651E8D8ECDD")
   startActivity(intent)
   

   and then open cryptomator in F-droid for installation with another click

   val intent = context.packageManager.getLaunchIntentForPackage("org.fdroid.fdroid")
   intent.data = Uri.parse("https://f-droid.org/en/packages/org.cryptomator/")
   startActivity(intent)
   

2. install the website version which is downloaded and installed with a click

In any case, it is also explained why there are these different variants and which is the right one for which use case. The package name org.cryptomator.light means that it is a completely different application that does not interact with our org.cryptomator application at all.

Here is a picture of how I imagine this to be (it can still change a lot just to clarify the principle, org.cryptomator.light will probably also change):

[thevigilante0]

The official F-Droid repository is known for its concern for security and privacy. If Cryptomator is there, it will give a good impression of security and privacy-conscious software.

It's important to know that F-droid itself has security issues, as presented in this blog, mainly point 1, 2, and 4

[SailReal]

@thevigilante0 Thanks for sharing this blog post and your thoughts.

Yes, we know that, especially because of point 1, we use the variant with reproducible builds, so the APK is signed by us, see e.g. https://gitlab.com/fdroid/rfp/-/issues/713#note_1055926901. The first installation is still problematic, updates have to be signed with the same key, this would be noticeable if an update came via a different repo signed with a different key but you definitely have to check from which repo the app is offered during the first installation. Late updates can be a serious problem, that is true and also in section 4, there are some valid points.

In summary, we share the opinion that it depends on the threat model and knowledge. For example, I don't trust my mother to download our APK from GitHub or our website, install apksigner and verify it, even verifying a SHA256 on a Android device requires a third party app but I do trust her to check which F-Droid repo the app comes from the first time she installs it, to install it only from the main repo (and verify it) and not to press it if another button appears later instead of an update button. Installing Aurora Store which have some of the problems of F-Droid too, or just because of Cryptomator to install the Playstore with Playservices in GrapheneOS doesn't make sense IMO. So what alternative do we have for such people currently?

However, it is certain that in any case it is a hard trade-off, which varies depending on the personal threat model.