signing key fingerprint should be sole ID for repos in the database

In order to support mirroring and other use cases well, the signing key fingerprint should be the sole ID used to determine the uniqueness of a repo. The signed repo metadata will then include canonical and official mirror URLs. The repo metadata will also still be trusted no matter where it comes from, as long as it has a valid signature from a trusted key. This then means that people can carry local mirrors, then when users add that local mirror to their F-Droid, it will automatically know the canonical and official mirror URLs since they are included in the signed metadata.

Once this in place, we have a lot of flexibility in mirroring. For example, we could have an "F-Droid Mirror" app that just makes it easy to mirror repos while keeping the original metadata. The mirror app can then advertise itself on local wifi via Bonjour, then any user who has opted into that mirror and already trusts the repo signing key would automatically receive updates from that mirror when its reachable.

Some areas that we'll need to think about changes:

• database representations of repos
• URL representation in UI, e.g. ManageReposActivity and RepoDetailsActivity
• flow of adding a new repo

Some user stories for this:

• José has an Android phone, but there is no 3G Internet in his region. He can, however, get on WiFi at his school, or when he walks by a local hotel or café. He uses these occasions to download new apps and upgrade the ones he has. Once he gets to school, he wants to share these with all of his friends.

• A human rights organization runs trainings in places where the internet is slow, expensive, and unreliable. In their trainings, they use apps, videos, and ebooks on the mobile devices. A trainer sets up an app store that includes all the needed apps, videos and publications. The trainees connect to the trainer's LibraryBox which is a mirror of the organizations official repo. After the trainings, the trainees continue to get updates via the internet since they are already setup for the official repo, and the official repo includes official mirrors.

ping @pserwylo @crwinfrey @n8fr8

This all sounds good, and I'm on board for moving toward using signing keys as the canonical representation of a repository provider. Here is a few additional things to consider:

• Swap repos are a little different, in that it is not as important to always trust that the person you are swapping with is the same as last time (maybe 12 months ago at the same annual conference). Right now it treats signing keys a little poorly. Some thought into what it means for a device to generate its own signing key for a swap repo is required: ** Should it ever be able to regenerate a new key? ** What would that mean for people who had previously swapped with that device?
• In the training example you outlined above, do you envision people installing F-Droid for the first time from the trainer? Or already have it installed. ** If it is installed from the trainers device, then TOFU comes into play because the version of F-Droid given to you is going to specify the signing ey for GP and F-Droid repos. If that is malicious, it is all stuffed from there. Not sure there is much that can be done here, other than AppObservatory type approaches.
• The final case where a trainer wants to send thorugh apps from Orot and Chat Secure - this sounds like we are confusing the difference between reproducabile builds + apk signing keys vs mirrors + repo signing keys. ** Bother are of course great and desirable ** Might want to come up with some user stories for the docs/wiki to explain when a mirror is preferable to hosting apks signed by upstream in your own custom repo.

I think swap repos should be treated exactly the same regarding signing key as identity, mostly because I see no reason to treat swap repos differently here.

There might be benefits to remembering the swap repo's key. We can make more stuff happen automatically when the user has opted in to trusting a specific repo. I'm thinking we'll probably want to reuse the "Just Once/Always" concept here when prompting the user "do you want to swap with so and so?".

Swap repos generate and save the key. If the app is uninstalled and reinstalled, it gets a new key, and it becomes in effect a new repo. I think that's fine the way it is. Even if we build some kind of stored relationship, it will only be a tiny bit of info, and starting a swap again will only require a little bit more interaction.

Yeah, I was a bit off on the last user story, I'm going to edit it.

This will be a big win for swap repos incidentally, because right now, I can have device X with signing key Y on IP address 10.0.0.5. But then later, I connect to device Z with signing key A on the same IP address (e.g. different network) and it fails to update because of signing key mismatches. This proposal will fix that problem for free.

Added swap label

mentioned in issue #831 (closed)

mentioned in issue #844 (closed)

assigned to @eighthave

removed assignee

changed milestone to %1.1