Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • fdroidserver fdroidserver
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 297
    • Issues 297
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 43
    • Merge requests 43
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • External wiki
    • External wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • F-Droid
  • fdroidserverfdroidserver
  • Issues
  • #153
Closed
Open
Created Feb 23, 2016 by Hans-Christoph Steiner@eighthaveOwner

optionally support multiple signing keys per APKs

F-Droid should optionally support multiple APKs per app release. For example, with Twidere, once its built reproducibly, it would then make two versions of the APK, one with the existing F-Droid signing key, and the other with the upstream developer's signature. The app metadata would then include the fingerprint of each signing key associated with the respective APK. Then the client can check if the app is installed, and which signing key that installed APK has, and chooses which APK to install. All new installs would default to the developer's signing key, when present.

On a related note, right now, if an app is included in multiple active repos in the client, the last repo in the list wins, which I think is a good behavior, But maybe it would make sense to have that changed to "last repo with matching signing key". But that could become a bit over-complicated. As @mvdan mentioned, fdroidclient might currently implement this as "last updated repo". That would usually have the same result as "last added" but not always.

I do think it should be enforced "last added" and not "last updated". Then if the client needs changeable priorities, it can be implemented by moving the repos around in the list.

This relates to the idea of designing F-Droid to be as close as possible to the Android security model. That means that apps should really have only one official signing key. The reproducible builds plus the repo supporting multiple APKs with different signing keys will put us on the path to achieve that.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking