[Android] Add to F-Droid

[dllud]

Please add the new Electrum for Android into F-Droid repository. You should also provide a direct download link for the apk on your download server (download.electrum.org).

Many of us don't wanna use GApps on our devices.

[ecdsa]

will do

[ecdsa]

APK direct download is now available on the website. I will do F-droid when I find time

[rauferd]

Step-by-step instructions for pushing an App to the F-Droid repository are available here: https://gitlab.com/fdroid/fdroiddata/blob/master/CONTRIBUTING.md

[GrimKriegor]

I've been using Electrum on GNU/Linux for years, but only now realized there was a droid version.

F-Droid is, I dare say, the goto place for free software droid applications, and often the only source for those of us who do not want to run the shaddy monster that is GApps.

Please consider adding Electrum to F-Droid in the near future. Thank you for your time.

[ecdsa]

I think it cannot be added as source repository, because they don't seem to support kivy/buidozer. So I have to add it as a binary APK

[jkufner]

Another option is to set up F-Droid repository. Once you have APK ready, it is only about one file with metadata and one command to run. Users then add your repository to their F-Droid client and updates will run smoothly forever. You can also provide a QR code with the repo URL, then F-Droid will add it automatically. Installation instructions are then:

1. Install F-Droid.
2. Scan this QR code to add Electrum repository.
3. Open F-Droid, install Electrum (it should appear on top of the list).

See:

• https://f-droid.org/wiki/page/Setup_an_FDroid_App_Repo
• https://guardianproject.info/2013/11/05/setting-up-your-own-app-store-with-f-droid/

[eighthave]

There is a prototype for kivy in the git history, but no one ever finished it. We'd be happy to include kivy support if someone wants to work on it.

[eighthave]

Its mostly a question of writing up a provisioning script that installs all the needed bits. None of the F-Droid devs have ever worked with kivy, so we don't know what to put in that script. You can look at the one for adding Qt support, it should be pretty easy for someone who knows kivy:

• https://gitlab.com/fdroid/fdroidserver/commit/91c5fb567a77c0b4a7f320662c8a186abe7b57c9
• https://gitlab.com/fdroid/fdroidserver/merge_requests/172

[ysangkok]

We (the Electrum team) have decided not to prioritize work on an an F-Droid repository or writing the kivy/F-Droid provisioning script, in case it is still needed. We would appreciate pull requests to add support for this, but since it is such a tiny user share and we have many more critical issues, I will close this. Please do not consider this a discouragement.

[PanderMusubi]

For people interested in helping packaging for F-Droid, please see https://gitlab.com/fdroid/rfp/issues/188

[532910]

Why this issue is closed? No one ask you to prioritize work on an an F-Droid repository, but please leave it open until it's not on F-Droid

[IzzySoft]

it is such a tiny user share

Wuahaha… 🤣 Just because F-Droid has no trackers and no statistics? No numbers visible doesn't mean no numbers existing (absence of proof is not proof of absence). That tiny user share just caused over 2.000 page views on a little article of mine within 5 days after the F-Droid blog linked to it. And those were just a part of the users who read that blog – by far not all people who use F-Droid (which I estimate are some millions for sure).

That "tiny user share" consists of users valuing privacy and transparency. If you share those concerns, I urge you to rethink your decision and state so here. As it currently seems you have "many more critical issues" (and that for 3 years now), I'll close the request for packaging of your app – as without your help, we are unable to comply. Once you state your support, we can reopen the request and deal with it. Please feel encouraged 😃

[MagicFab]

@ysangkok I am also wondering why this is closed. It makes it harder to find and follow.

@IzzySoft you're here criticizing closing this bug but you did the same on the F-Droid tracker! How is that coherent ?

[IzzySoft]

@MagicFab it's consequent – and I explained it in my above comment. In this issue here it was signalized inclusion is not supported – so why should we keep it open on our end, if it cannot be included? If that situation changes, we can always reopen.

[SomberNight]

What would need to be done to distribute an apk on f-droid?

[IzzySoft]

@SomberNight F-Droid builds all apps from source. If I understood correctly, this is a Kivy app – and AFAIR it's not that easy for F-Droid to build Kivy apps. Maybe @rudloff could give some details on what is required (I have no build experience at all) – but as a first step, can I take your reopen of this issue as saying you'd be OK with your app being listed at F-Droid? Assuming so, I've reopened the issue on our end as well ad updated the initial post accordingly. Thanks!

[Rudloff]

If the app can be built with buildozer, we should be able to package it (once this issue is fixed).

[SomberNight]

can I take your reopen of this issue as saying you'd be OK with your app being listed at F-Droid?

Yes, sure, it would be nice to be listed at F-Droid.

If the app can be built with buildozer

The app is built using buildozer, yes. The build script is run in a docker container (though this is of course not necessary). See build instructions, and dockerfile.

[Rudloff]

We don't support Docker but a Dockerfile is always useful as a basis to write our build recipe :+1:

[zebra-lucky]

Recently doing merge request on Dash Electrum build version 3.3.4, so with some changes you can do BTC version build:

https://gitlab.com/fdroid/fdroiddata/merge_requests/4807

[zebra-lucky]

in a 3.3.5 differs cherry-picks for p4a...

[zebra-lucky]

Added a small fix to not reset git config on local build:

https://gitlab.com/fdroid/fdroiddata/merge_requests/4807/diffs?diff_id=42558815&start_sha=899b1651e582a49a2a0943e80ebc97fff195bef0

https://gitlab.com/fdroid/fdroiddata/merge_requests/4807#note_172158318

[zebra-lucky]

Need to redo build process, when package will be accepted I write resulting code link.

[PanderMusubi]

@zebra-lucky any updates for this?

[zebra-lucky]

Yes, there is merged recipe for 3.3.6: https://gitlab.com/fdroid/fdroiddata/blob/master/metadata/org.dash.electrum.electrum_dash.yml

[soredake]

Any progress on this?

[PanderMusubi]

Best is to create an issue at fdroiddata regarding update progress.

[xanoni]

Just looked for this on FDroid but no success :(

Please add me to the potential user list.

[PanderMusubi]

@xanoni see https://gitlab.com/fdroid/rfp/-/issues/188

[xanoni]

Created 4 years ago

[SomberNight]

Now that we build reproducible android apks (https://github.com/spesmilo/electrum/pull/7263), I think F-Droid could publish the apks signed by us. We have been publishing apks on our website and on Google's store, signed by the same key, for years. It would be nice if the same key could be used on F-Droid as well, so that users can easily change between distribution mechanisms.

As I said earlier, it would be nice to get published on F-Droid, as that would mean less reliance on Google. This would be much easier though if F-Droid supported docker-based builds. I think the F-Droid build script might have to duplicate much of our existing build scripts instead of just calling them due to lack of docker, and hence I am uncertain how much maintenance work the F-Droid build script would need - ideally we would optimise for minimising F-Droid-specific maintenance. Still, if someone steps up and writes an initial F-Droid build script that can reproduce the apk we published on the website, we would use it and start publishing on F-Droid.

[tsilvs]

if someone steps up and writes an initial F-Droid build script that can reproduce the apk we published on the website, we would use it and start publishing on F-Droid.

What knowledge and skill set that would require of this supposed someone?

[zebra-lucky]

What knowledge and skill set that would require of this supposed someone?

Let's to try?

clone this repos:

https://gitlab.com/fdroid/fdroiddata

https://gitlab.com/fdroid/fdroidserver

[zebra-lucky]

If interested, then the instructions will be applied.

[momobobe]

@Rudloff @linsui @Poussinou @Efreak would you like to have a look and help the process of inclusion?

[tomichec]

Is there any progress since last year? The electrum dash has made it's way to F-Droid and I assume it's not technically that much different. So there is a clear indication it is possible. I'm new into this technology, but I would be willing to help.

[akhavr]

Dash Electrum was brutally defunded while its team was under constant Russian attacks. No more work will be done on Dash Electrum. More info at https://github.com/akhavr/electrum-dash/wiki

[tensor5g]

So if a project that was under constant attack from Russian hackers was able to get onto F-Droid, surely this one should be able to as well?

[akhavr]

So if a project that was under constant attack from Russian hackers was able to get onto F-Droid, surely this one should be able to as well?

You miss the point. Team members were bombed and shelled by Russian Army and Dash Masternode owners told us that we're not allowed to put the notice on the product we develop.

Therefore now there's no dash electrum and no work will be done by our team.

You're free to recover sources, including build scripts, if you can, and reuse them. I don't believe we have them anymore now.

[tensor5g]

But this is the Electrum (bitcoin) repo, this has nothing to do with Dash other than a fork of it was used for Dash and published to F-Droid, showing that it was possible. I don't think anyone here was expecting Electrum Dash developers to put this on F-Droid for the Electrum proper devs.

[akhavr]

But this is the Electrum (bitcoin) repo, this has nothing to do with Dash other than a fork of it was used for Dash and published to F-Droid, showing that it was possible. I don't think anyone here was expecting Electrum Dash developers to put this on F-Droid for the Electrum proper devs.

Electrum Dash was mentioned - I've responded that there's no point in seeking build scripts from the project because it doesn't exist anymore.

[tomichec]

good point, @akhavr. Actually the build scripts are backed up on the fdroiddatata server.

[akhavr]

Good to know. Feel free to reuse them. Tag me or @zebra-lucky if any questions - we'll try to recall what happened then

[SomberNight]

Currently the apk is available from two sources:

• direct download on the website
• google store

Also distributing on f-droid would be a third source. We would like all sources to distribute apks signed by matching apk-signing-keys. Especially considering Lightning channels, it would be bad to have to reinstall when switching between sources.

---

(1) Typically when you publish on the official f-droid store, their buildserver builds from sources and signs with its own key. IIRC this is what electrum-dash did. This does not allow switching sources, so this approach is not satisfactory.

(2) Our apks are built reproducibly, so there is an alternative approach where we provide our own binary apk and signature to the f-droid buildserver, it tries to reproduce it, and if successful, it would then publish with the upstream signature (so allowing switching sources without reinstalling). Unfortunately it seems difficult to integrate our docker-based build scripts with the f-droid buildserver.

(3) Alternatively, we could set up our own f-droid repository, and not use the official f-droid.org one, which could be a "simple binary repo" and just upload the same apk there that is available from the website (and google store). The difficulty with this approach, is that we are quite paranoid about build/distribution security, and to avoid single-point-of-blackmail-failure, this infrastructure would have to be run so that no single trusted person can compromise it alone. (see e.g. https://github.com/spesmilo/electrum-web/blob/b90667fcbc00f5bf1d714eccac2611cd1ac0a9f4/index.html#L225-L233) In case of the google play store, this is achieved by (a) one dev having the apk-signing-key, (b) another dev having access to the google account, (c) google store verifying that updated apks are signed by the expected key. Clearly whoever is running the store is a single point of failure (for new installs only. for existing install the OS is responsible for TOFU).

---

As for updates, we have been working towards a complete rewrite of the GUI used on Android, replacing kivy, and the next release, which is imminent, is going to use qml. The kivy GUI is deprecated and planned to be removed, in favour of the new qml GUI. As for the build system, kivy's sister projects are still used, just not kivy/kivy itself. We use docker to run buildozer and python-for-android still, but now instead of using sdl2 and kivy/kivy, we build and use qt5+pyqt5. I am afraid this made build times and resource requirements several times more demanding, e.g. on my laptop needing ~5x more wall clock time (due to git cloning and building qt5, mainly). However the new GUI is much nicer, and no longer looks like it was written for ice cream sandwich! :)

As before, help towards approach (2) would be welcome.

[tomichec]

Maybe @Rudloff will know if the approach (2) from the previous message is possible.

[Rudloff]

Sorry I don't contribute do F-Droid anymore. F-Droid does support reproducible builds with upstream signature: https://f-droid.org/fr/docs/Reproducible_Builds/ I'm not sure about building with Docker though.

[lebr0n23]

Currently the apk is available from two sources:

* direct download on the website

* google store

Also distributing on f-droid would be a third source. We would like all sources to distribute apks signed by matching apk-signing-keys. Especially considering Lightning channels, it would be bad to have to reinstall when switching between sources.

(1) Typically when you publish on the official f-droid store, their buildserver builds from sources and signs with its own key. IIRC this is what electrum-dash did. This does not allow switching sources, so this approach is not satisfactory.

(2) Our apks are built reproducibly, so there is an alternative approach where we provide our own binary apk and signature to the f-droid buildserver, it tries to reproduce it, and if successful, it would then publish with the upstream signature (so allowing switching sources without reinstalling). Unfortunately it seems difficult to integrate our docker-based build scripts with the f-droid buildserver.

(3) Alternatively, we could set up our own f-droid repository, and not use the official f-droid.org one, which could be a "simple binary repo" and just upload the same apk there that is available from the website (and google store). The difficulty with this approach, is that we are quite paranoid about build/distribution security, and to avoid single-point-of-blackmail-failure, this infrastructure would have to be run so that no single trusted person can compromise it alone. (see e.g. https://github.com/spesmilo/electrum-web/blob/b90667fcbc00f5bf1d714eccac2611cd1ac0a9f4/index.html#L225-L233) In case of the google play store, this is achieved by (a) one dev having the apk-signing-key, (b) another dev having access to the google account, (c) google store verifying that updated apks are signed by the expected key. Clearly whoever is running the store is a single point of failure (for new installs only. for existing install the OS is responsible for TOFU).

As for updates, we have been working towards a complete rewrite of the GUI used on Android, replacing kivy, and the next release, which is imminent, is going to use qml. The kivy GUI is deprecated and planned to be removed, in favour of the new qml GUI. As for the build system, kivy's sister projects are still used, just not kivy/kivy itself. We use docker to run buildozer and python-for-android still, but now instead of using sdl2 and kivy/kivy, we build and use qt5+pyqt5. I am afraid this made build times and resource requirements several times more demanding, e.g. on my laptop needing ~5x more wall clock time (due to git cloning and building qt5, mainly). However the new GUI is much nicer, and no longer looks like it was written for ice cream sandwich! :)

As before, help towards approach (2) would be welcome.

regarding (3) i understood how you avoid single-point-of-blackmail-failure on google play, but i'm curious how you do it with the apk on the website and why it in theory can't be aplied to the f-droid repo apk..

[SomberNight]

regarding (3) i understood how you avoid single-point-of-blackmail-failure on google play, but i'm curious how you do it with the apk on the website and why it in theory can't be aplied to the f-droid repo apk..

Essentially, one dev has the apk-signing-key, and he does not have access to the webserver. You are right, something similar could be done with a custom f-droid repo.

(Access to the webserver is more complicated, as the above linked script shows. the typical flow is that there is a cronjob that has permissions to update the webserver, and it only releases updates if they are signed by two devs.)

Clearly whoever is running the store is a single point of failure (for new installs only. for existing install the OS is responsible for TOFU).

Ok, so with option (3), the line becomes somewhat blurry, but it boils down to that quote ^.

Imagine the webserver is compromised: if users downloaded malicious binaries, they would still be protected if they verify the GPG signatures (none of the people gpg signing has access to the webserver). Re the android apk in particular, again, existing users get TOFU protection from the OS, but new users are exposed to risk. A new user (first-time downloader of the android apk) is only protected if they verify the GPG signature. Now re a custom f-droid repo: if that was compromised, new users would not be protected at all - there is no GPG sig they can manually check and the OS TOFU does not help either.

Though you could argue GPG sigs don't really help new users much anyway, as they likely don't have the pubkeys for any of the signers yet -- basically GPG sort of functions as TOFU as well, these days. But at least ThomasV's GPG key is widely available all over the web and is also signed by many other people.

So I think re security of the apk being on the website vs running a custom f-droid repo, they are similar if users don't verify GPG sigs. For new users that do verify, the website apk is safer. (then again, there are other dimensions to consider, e.g. ~automatic updates, esp. re security patches)

Re first time downloads from Google Play (or central F-Droid repo, if we used it), the analogous attack would have to be done by the store itself.

---

Anyway, I acknowledge this point is perhaps a bit far-fetched -- especially as the OS TOFU sigchecks make Android not really worth it to attack: at any given time the vast majority of downloads I expect are existing users installing updates, not fresh installs. So running a custom f-droid repo is something to consider. But it would be much nicer to figure out option (2) instead.

[lebr0n23]

regarding (3) i understood how you avoid single-point-of-blackmail-failure on google play, but i'm curious how you do it with the apk on the website and why it in theory can't be aplied to the f-droid repo apk..

Essentially, one dev has the apk-signing-key, and he does not have access to the webserver. You are right, something similar could be done with a custom f-droid repo.

(Access to the webserver is more complicated, as the above linked script shows. the typical flow is that there is a cronjob that has permissions to update the webserver, and it only releases updates if they are signed by two devs.)

Clearly whoever is running the store is a single point of failure (for new installs only. for existing install the OS is responsible for TOFU).

Ok, so with option (3), the line becomes somewhat blurry, but it boils down to that quote ^.

Imagine the webserver is compromised: if users downloaded malicious binaries, they would still be protected if they verify the GPG signatures (none of the people gpg signing has access to the webserver). Re the android apk in particular, again, existing users get TOFU protection from the OS, but new users are exposed to risk. A new user (first-time downloader of the android apk) is only protected if they verify the GPG signature. Now re a custom f-droid repo: if that was compromised, new users would not be protected at all - there is no GPG sig they can manually check and the OS TOFU does not help either.

Though you could argue GPG sigs don't really help new users much anyway, as they likely don't have the pubkeys for any of the signers yet -- basically GPG sort of functions as TOFU as well, these days. But at least ThomasV's GPG key is widely available all over the web and is also signed by many other people.

So I think re security of the apk being on the website vs running a custom f-droid repo, they are similar if users don't verify GPG sigs. For new users that do verify, the website apk is safer. (then again, there are other dimensions to consider, e.g. ~automatic updates, esp. re security patches)

Re first time downloads from Google Play (or central F-Droid repo, if we used it), the analogous attack would have to be done by the store itself.

Anyway, I acknowledge this point is perhaps a bit far-fetched -- especially as the OS TOFU sigchecks make Android not really worth it to attack: at any given time the vast majority of downloads I expect are existing users installing updates, not fresh installs. So running a custom f-droid repo is something to consider. But it would be much nicer to figure out option (2) instead.

thank you for replying so quickly and acknowledging the far-fetched point. i really appreciate that!

in case others are still looking for workarounds, until f-droid is supported, i'll try to update electrum via obtainium from the official website for now

[ghost]

Personally, I only use Obtainium, (or manual apk downloads) for small/unimportant apps, such as ones that don't require any important permissions or ones that do not have any internet connectivity. There are several reasons why I do not (will not) use any important apps on my phone from outside the F-Droid ecosystem. Each of them applies here in particular, given the heavy incentives that bad actors have in the cryptocurrency space.

The act of publishing on the F-Droid system, whether as part of the F-Droid main repository or a separate (custom) repository, means that the app would have had to go through layers of scrutiny and several types of ongoing checks by several different community-driven teams. This particular type of vetting exceeds even the kind that can be provided by a proprietary and profit-driven app store. @SomberNight's point (3) above further illustrates my reasoning here.

Such an integrating model for assuring security is a well-established process that has been followed in the open-source world for ALL critical or vulnerable apps. Indeed, your own team already followed this very same model on other open-source platforms well over a decade ago.

Now, to be very clear: I understand Electrum to be a well-vetted, reputable and popular app used by many millions worldwide. But when an entire team fails to adhere to these long-established security practices, it does raise some questions. And there are many instances that come to mind of other apps in the crypto space claiming their code to be "open source" but when one tries to build it becomes readily apparent that there are either closed/proprietary libraries involved without which this is not possible. Or that their published APKs contain some functionality not included in any of the published code. And I assume we are all familiar with the recent news of the criminal indictment of the founders of another such "open-source" app.

I am finding it difficult to comprehend the argument that all the effort that went into building this app is somehow overshadowed by the effort that it is taking to put this on Fdroid.