F-Droid standalone repo

[KOLANICH]

Hello. 0 I don't trust F-Droid much because they sign packages themselves that means that they can insert malware into updates any time. 1 F-droid app allows anyone to create own repos, to do it you just need to drop apk and xml somewhere. For example, to GitHub. 2 I've heard that f-droid has reproducable builds, so it'd be good to compare your builds with fdroid ones (and make fdroid compare your builds with its).

[mar-v-in]

I'd really like to have reproducible builds as well. I think having those is enough if users can easily check signature (ideally builds will be signed using my key and f-droid key). Currently the resulting binaries differ mostly because I use openjdk 8 while f-droid build servers use openjdk 7. I'll check what else is required to have the same builds.

Until this works, you can always use my builds provided here on github. I guess setting up a f-droid repo is too much work for a single end user (most people do not have problems with f-droid :smile: )

[KOLANICH]

I guess setting up a f-droid repo is too much work for a single end user

This can be easily authomated (if we don't touch reproducibility) . You just need to rebuild xml on every build to match the newest version.

[TameOfGroans]

0 "I don't trust F-Droid much because they sign packages themselves"

How would you have them build from source without access to any given developer's key?

I prefer adware [which is malware] be removed prior prior to compilation -- default F-droid build policy. Adware injures users for developer profit. No informed consent. That's bad.

1 And when developer opts not to build as frequently as FDroid?

[KOLANICH]

How would you have them build from source without access to any given developer's key?

The way it was meant to be done: both fdroid and developer use reproducible builds to get almost the same binary, then fdroid overwrites its signature with developer's one.

And when developer opts not to build as frequently as FDroid?

If the dev and fdroid both use RB it doesn't matter - the result doesn't depend on date, only on a version.

[n76]

F-Droid does not overwrite the signature as its builds do not and cannot have the developer's signature to overwrite unless the developer has shared their private key which should never happen.

So even if F-Droid and the developer used the exact same version of the exact same tool chain and came out with identical binaries they will be different after they are signed by the entity that built them.

If you really don't trust F-Droid then you shouldn't trust the developer either: Its all open source so get the sources yourself, examine the code for things you fear and then build and sign it yourself.

[mar-v-in]

It would be possible to dual-sign binaries: I release binaries signed with my keys and build using a defined toolchain in a reproducible manner. F-Droid builds the source code with the same toolchain and signs it with their key. If the resulting binary matches, they can put my signature into it leaving it valid. This way I confirm that the binary contains my software and F-Droid can confirm the binary is build from my source code (so that I cannot include anything but the original source code)

The problem that actually occurs here is Androids handling of signatures, as packages must always be updated with a package of exactly the same signing key combination. If I stop releasing updated or builds are no longer binary compatible, F-Droid will no longer be able to update the app through their app store (without reinstalling), the same applies to the other way round.

As a final solution I could think of not using Android signatures for signature verification. Both F-Droid and me could release a signature of the package contents (eg using PGP) and share it in some "central" place. [ I think it would be nice if F-Droid could provide a platform for this. @mvdan ] Then some kind of app could check those signatures [ maybe directly inside F-Droid ] and the user can see which signatures apply. This for sure is a power user feature, but it could become handy longterm?

[KOLANICH]

As a final solution I could think of not using Android signatures for signature verification. Both F-Droid and me could release a signature of the package contents (eg using PGP) and share it in some "central" place. [ I think it would be nice if F-Droid could provide a platform for this. @mvdan ] Then some kind of app could check those signatures [ maybe directly inside F-Droid ] and the user can see which signatures apply.

A bad idea because android standard way is to rely on package signatures to prevent unauthorized replacement of packages by malicious stores.

F-Droid does not overwrite the signature

In the wiki it is written that fdroid compares own build with dev's one and publishes dev's one if they match, not just overwriting the sig. I ccc talk they said that it downloads a devs's build, put signature from it over fdroid binary and then verify it, if it is ok the apk is published.

[mar-v-in]

Reproducible builds will allow apps signed by me to be added to F-Droid some day in the future. If I am going to spend time on anything mentioned in this issue it's not the custom repository, but the reproducible builds.

If you need a standalone F-Droid repository that contains binaries signed by me until then, feel free to use the binaries I provide on GitHub and put them in your own repository. Setting up a repository just for you (and apparently you're the only user interested in that) is pointless work if you can do it for yourself - and I guess you can as you seem to know a bit about it.

[IzzySoft]

I guess setting up a f-droid repo is too much work for a single end user

For one single end-user: yes, I'd agree. But considering the other advantages (you can sign with your key, updates are available when you decide – no delay), and the fact that such a repo is easily added to the F-Droid client – it might be worth it. Actually, a simple binary repository could be set-up in an hour or less.

To me, this would be a nice thing to have – even better if the devs of the related backends can be brought into this. A "full µg repo", so to say, with everything in that's needed (maybe even the Xposed module). If maintained by the dev himself, I'd trust it as much as F-Droid in this case.

I don't share the concerns of @KOLANICH in regard to the F-Droid builds (just the opposite: I count this a plus – despite of the trouble with signatures when using different sources). Still, I'd warmly welcome such a repo for the reasons I gave above.

[mar-v-in]

F-Droid updates are usually delayed by less than 24 hours. For most users the delay of 24 hours is negligable.

The only thing I could imagine to be useful would be a nightly build repo. That would probably fit less for normal users, but would be nice for developers, testers and early-adopters.

[IzzySoft]

I wasn't aware the delay is that small – and fully agree this nullifies my corresponding argument. Thanks for that fact, @mar-v-in ! And yes, an "early bird" repo sounds useful indeed – though I'd rarely fit into one of those groups ;)

[agilob]

0 I don't trust F-Droid much because they sign packages themselves that means that they can insert malware into updates any time.

Builds are reproducible and complete build log is available on wiki.

[IzzySoft]

Apart from that, I guess @mar-v-in just forgot to close this issue – as the stand-alone repo for microG is already available at https://microg.org/fdroid/ (also see my Inofficial (and incomplete) list of F-Droid repositories).

[mar-v-in]

Indeed.