APK verification instructions

Where are the instructions for verifying the fdroid APK signature on an Android device, where it will be installed?

Why is the pgp key used to sign the APK not available on the page where the fdroid install download button and the signature are?
https://f-droid.org/en/

But it is…?
https://f-droid.org/FDroid.apk.asc
bilde

As for instructions, that is a good idea. Should be on the PGP key site. I can’t imagine parsing will cause trouble(?)

https://f-droid.org/FDroid.apk.asc
Seems to be just the detached file signature.
The signing key isn’t there.

Spent a bunch of time today trying to figure out how to check the installer signature on Android itself, without a PC.

Doesn’t seem possible with Android OpenPGP or anything else I could think of.
I’m far from a newbie with pgp.
So I’m sure other new users are confused.

The signing key should be here
https://f-droid.org/docs/Release_Channels_and_Signing_Keys

You can also find it on a keyserver; gpg --search-keys f-droid. After importing the key, download the apk and asc, and then gpg --verify FDroid.apk.asc.

…but how to perform those steps from Android I don’t know. :man_shrugging:

Thanks.
I found the key from another post earlier on the forum.

My question was why there’s no link to that page right next to the signature and download links, since a new user needs that key to check the signature.

Searching through public key servers thru gpg doesn’t seem safe, because anyone could throw up a key there called “f-droid”.

The 2 “f-droid” keys could confuse some of the new users all of the time or even all of new users some of the time.

The way it is now, I bet almost no new users bother to check the signature on a PC, before they download it again and install another unchecked copy on their Android.

Thanks forrest. But I am wondering, whether it is that easy, even with a PC “at hand”:

user@host:~/Downloads/android$ gpg --search-keys f-droid
gpg: data source: http://192.146.137.99:11371
(1) Launchpad PPA for F-Droid
4096 bit RSA key EC4632C79C5E0151, created: 2016-09-14
(2) Launchpad PPA for F-Droid
4096 bit RSA key 217AF6E2A2BC641F, created: 2016-09-14
(3) F-Droid admin@f-droid.org
4096 bit RSA key 41E7044E1DBA2E89, created: 2014-04-25
Keys 1-3 of 3 for “f-droid”. Enter number(s), N)ext, or Q)uit > Q
gpg: error searching keyserver: Operation cancelled
gpg: keyserver search failed: Operation cancelled
user@host:~/Downloads/android$ gpg --verify FDroid.apk.asc
gpg: assuming signed data in ‘FDroid.apk’
gpg: Signature made Do 11 Apr 2019 14:41:19 CEST
gpg: using RSA key 7A029E54DD5DCE7A
gpg: Can’t check signature: No public key

So which one should be imported? This issue is also linked with PGP-signature of F-Droid.apk
Any thoughts are appreciated!

I’m able to verify the F-Droid apk using the third entry (admin@f-droid.org). BTW it has the same primary key fingerprint and subkey fingerprint as those listed on the Release Channels and Signing Keys page.

I am not sure the word “easy” applies in any way. jredgui makes some good points. I think a good majority don’t really get this stuff, new users are probably confused, and most probably don’t bother to check the signature. GPG is not easy to use. I don’t think putting the key next to the download actually improves anything though.

BTW, I don’t think blindly trusting the key on the webpage (especially if posted right next to the download) is really any safer than blindly trusting a key off some keyserver. Consider that any attack on the apk would probably be part of an attack on the website itself. Verifying a file was signed by a given key and trusting that key are different problems.

Is there not a group of devs behind f-droid?
Does the f-droid download page itself not come from some GitHub or Gitlab source?

If so, the dev team could all be automatically notified by third-party services that those pages have changed unexpectedly.

The gpg signing system is trustworthy enough even for apps where a lot of money is at stake in site or key attack, such as Bitcoin for example.

The point is there have to be instructions how to do it on the Android device where it will be installed.
Even experienced gpg users can’t figure that out yet.

Otherwise, it’s pointless to even sign the APK.

For those who want the most reliable way to verify, you can build the APK from source yourself, then compare it. Many APKs in F-Droid are built reproducibly. This approach does require technical skill and a chunk of work.

1 Like

@forrest
Yes, I share your opinion that it is difficult to trust a key on a webpage next to a file that should be verified by the stored key. But in my understanding, this is why the pgp key server is involved as another party to verify the key, with which the file is signed.
You write:

I’m able to verify the F-Droid apk using the third entry (admin@f-droid.org).

OK, but in my eyes, it is a bit of trial and error to import the correct key. Or, is there any way to query a key server for the given fingerprint?

> user@host:~/Downloads/android$ gpg --verify FDroid.apk.asc
> gpg: assuming signed data in ‘FDroid.apk’
> gpg: Signature made Do 11 Apr 2019 14:41:19 CEST
> gpg: using RSA key 7A029E54DD5DCE7A

to make sure it belongs to admin@f-droid.org?

@Mr.T
Hrm, I don’t know how to query the keyserver for a fingerprint. I must admit that I noticed the matching fingerprints during verification of the apk (and not before). Of course finding the same key in multiple places makes me more willing to trust the signature. This is also my understanding of keyservers (that they can be useful when needing to establish a web of trust).

I have learned of another option. Add the line keyserver-options auto-key-retrieve
to gpg.conf and the appropriate key will be automatically downloaded and imported when running gpg --verify. This seems to be the easiest way to obtain the key by far.

Hello,

Regarding the page for Release Channels and Signing Keys, do all 3 sets of the Verification commands need to be entered?

https://f-droid.org/en/docs/Release_Channels_and_Signing_Keys/

Thanks!

@forrest
Thanks. OK, the following would help

to download the necessary pgp keys whenever they are needed and in the following to handle the “error message” of unknown keys, but in my opinion, you might lose a lot of control here. Or does the download of every key have to be confirmed by the user?
You might also download the necessary key via

gpg --keyserver [NAME OF KEYSERVER] --recv-key 7A029E54DD5DCE7A
(as ssamer writes in SHA256 checksum of FDroid.apk)

but I have hoped to be able to verify the necessary key before I add it to the key-ring.
I thought, the keyserver should be the address of choice to query it for the owner of a given key.

If you’re going to use auto-key-retrieve, might as well not bother to verify the APK or anything at all.

Whatever it is will always verify as long as the attacker bothered to sign it with his own key and upload it to public servers.

That is simply not true @jredgui. As I have tried to explain before, verifying a file has been signed with a given key and trusting that signature belongs to a given identity are two different things. GPG rightly warns you that the signature is untrusted even with a good key. You, as a PGP user, need to take steps to establish a web of trust (and to sign the public keys that you trust).

but in my opinion, you might lose a lot of control here

I agree. Your keyring will inevitably become filled with cruft for the convenience. You will probably need to --delete-keys often.

However you obtain the key, be it --search-keys, or -recv-key, or -import (of something published on a website), that is only the starting point. Without taking steps to validate the key (as actually belonging to F-Droid) then verification of the signature on the file means nothing. An attacker could absolutely sign the apk with their own key and push that to a keyserver. They could also publish their own key right next to the download (after hacking the website).

…its moot though. The gpg release key doesn’t exist in isolation. The same key is published on the website and keyserver, and has been signed by F-Droid devs, whose keys have been signed by others, and so on and so on. Ideally you should be able to validate it within your web of trust (https://www.gnupg.org/gph/en/manual/x547.html).

OK, now I guess I understand the output of querying a gpg keyserver, e.g. with “0x7a029e54dd5dce7a”,
https://keyserver.ubuntu.com/pks/lookup?search=0x7A029E54DD5DCE7A&op=vindex&fingerprint=on

I was expecting to find the RSA key 0x7a029e54dd5dce7a somewhere in these results, but I assume, that this is its “web of trust”, i.e., list of keys that have signed the queried RSA key.

I was really hoping to find a manual, where this output is explained in detail … and I have spent a lot of time on that search. At least, this makes sense.

1 Like

Hello again,

Regarding the page for Release Channels and Signing Keys, do all 3 sets of the Verification commands need to be entered?

https://f-droid.org/en/docs/Release_Channels_and_Signing_Keys/

Thanks!

In my case the verification of the apk worked with

user@host:~$ gpg --search-keys f-droid
gpg: data source: http://192.146.137.98:11371
(1) Launchpad PPA for F-Droid
4096 bit RSA key EC4632C79C5E0151, created: 2016-09-14
(2) Launchpad PPA for F-Droid
4096 bit RSA key 217AF6E2A2BC641F, created: 2016-09-14
(3) F-Droid admin@f-droid.org
4096 bit RSA key 41E7044E1DBA2E89, created: 2014-04-25
Keys 1-3 of 3 for “f-droid”. Enter number(s), N)ext, or Q)uit >

And then selecting the 3rd key. Afterwards the verification of the apk file gives

user@host:~/Downloads/android$ gpg --verify FDroid.apk.asc
gpg: assuming signed data in ‘FDroid.apk’
gpg: Signature made Do 11 Apr 2019 14:41:19 CEST
gpg: using RSA key 7A029E54DD5DCE7A
gpg: Good signature from “F-Droid admin@f-droid.org” [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 37D2 C987 89D8 3119 4839 4E3E 41E7 044E 1DBA 2E89
Subkey fingerprint: 802A 9799 0161 1234 6E1F EFF4 7A02 9E54 DD5D CE7A

These fingerprints can be verified on the webpage

Hope that helps.

Mastodon