Task #1759
what does FDroid do when it finds the same app with different sigs?
| Status: | In Progress | Start date: | 08/21/2013 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | - | |||
| Target version: | integrated audit and user-generated data | |||
| Component: |
Description
it is possible to have multiple FDroid repos that include the same APK. What happens with if they have different signatures? Or are different versions, etc?
History
#1 Updated by n8fr8 over 4 years ago
- Target version set to 0.1 - "Kerplapp"
#2 Updated by hans about 4 years ago
- Target version changed from 0.1 - "Kerplapp" to 0.2 - ChatSecure/Bluetooth
#3 Updated by hans about 4 years ago
- Priority changed from Normal to High
#4 Updated by hans almost 4 years ago
- Target version changed from 0.2 - ChatSecure/Bluetooth to improved security/usability
#5 Updated by pd0x almost 4 years ago
- Status changed from New to Feedback
Tested by creating an application (package ID: com.example.testapp) that I signed with two different keys to produce TestApp.a.apk and TestApp.b.apk. Both APKs were VersionCode 1. I used the fdroidserver tools to create two separate FDroid repos TestRepoA and TestRepoB that each listed com.example.testapp with one APK (TestApp.a.apk or TestApp.b.apk based on the repo name).
Adding both repositories to FDroid in the order TestRepoA and then TestRepoB results in one listing in the FDroid client from TestRepoB installs TestApp.b.apk. If TestApp.a.apk is already installed FDroid prompts for it to be removed before installing TestApp.b.apk
Reversing the order of repository addition (adding TestRepoB then TestRepoA) results in one listing in the FDroid client from TestRepoA that installs TestApp.a.apk. If TestApp.b.apk is already installed FDroid prompts for it to be removed before installing TestApp.b.apk
This seems like a bug. I think the correct behavior is to have two listings for the same Version under the app details screen. Ideally with a means to distinguish which APK listing corresponds to which repository & app signature.
#6 Updated by pd0x almost 4 years ago
Opened Issue 477 with the FDroid project. https://f-droid.org/repository/issues/?do=view_issue&issue=477
#7 Updated by daithib8 almost 4 years ago
UI-wise the complete list of APKs should be in a different activity. Users should normally be able to trust the client enough to scroll past the text and any warnings and press install, without having to examine the full list of available versions. This allows all info from within and without the index to be displayed without being too cluttered and the list can be easily sorted. With a navigation drawer paradigm it wouldn't be too tedious to navigate.
#8 Updated by hans over 3 years ago
- Status changed from Feedback to In Progress
- Assignee deleted (
pd0x)
#9 Updated by hans over 2 years ago
- Target version changed from improved security/usability to integrated audit and user-generated data