Ph.D. student at UC Riverside. Creator of @appmanager. My interests are security, privacy, linguistics, medical science and physics.
Ph.D. student at UC Riverside. Creator of @appmanager@floss.social. My interests are security, privacy, linguistics, medical science and physics.
Posts
Ph.D. student at UC Riverside. Creator of @appmanager. My interests are security, privacy, linguistics, medical science and physics.
Ph.D. student at UC Riverside. Creator of @appmanager. My interests are security, privacy, linguistics, medical science and physics.
Ph.D. student at UC Riverside. Creator of @appmanager. My interests are security, privacy, linguistics, medical science and physics.
@grote@chaos.social @y20k@chaos.social This issue can be addressed in several different ways depending how the app was published on F-Droid.
For apps published with the explicit consent from the maintainer: F-Droid can ask the maintainer to include an adi-registration.properties with the maintainer's own unique key if the developer has an account with Android developer verification program. Otherwise, they can ask the maintainer to use F-Droid's own key and let F-Droid claim the package ID instead.
If the developer doesn't care, inactive, or no explicit consent has been given, F-Droid can claim it using an skeleton package (https://github.com/android/security-samples/tree/main/AndroidDeveloperVerificationAPKSigningExample) for verification. But this can be complicated depending on the package ID. If F-Droid uses a different package ID, it should be easy. If not, F-Droid needs to ask Google to explicitly allow them to use the same package ID since Google wants to reduce collision as much as possible.
Ph.D. student at UC Riverside. Creator of @appmanager. My interests are security, privacy, linguistics, medical science and physics.
Ph.D. student at UC Riverside. Creator of @appmanager. My interests are security, privacy, linguistics, medical science and physics.
Ph.D. student at UC Riverside. Creator of @appmanager. My interests are security, privacy, linguistics, medical science and physics.
Ph.D. student at UC Riverside. Creator of @appmanager. My interests are security, privacy, linguistics, medical science and physics.
@y20k@chaos.social I think a potential solution is creating a verifiable build by pushing adi-registration.properties file into the version control system. Once it's published on F-Droid, you can add that signature as an additional key in the Android developer verification page.
Ph.D. student at UC Riverside. Creator of @appmanager. My interests are security, privacy, linguistics, medical science and physics.
Apps subjected to potential impersonation attack:
- App Manager
- Captive Portal Controller
Apps with F-Droid priorities:
- SetEdit
- UnApkm
- Metro (since this app is exclusive to F-Droid)
Ph.D. student at UC Riverside. Creator of @appmanager. My interests are security, privacy, linguistics, medical science and physics.
Ph.D. student at UC Riverside. Creator of @appmanager. My interests are security, privacy, linguistics, medical science and physics.
Ph.D. student at UC Riverside. Creator of @appmanager. My interests are security, privacy, linguistics, medical science and physics.
It appears one or more impersonators have already registered some of the #Android applications that I maintained, including @appmanager@floss.social. I've reported this to #Google, but not sure what's going to happen. The Android developer verification is still in beta, and it doesn't have a lot of features now to deal with this kind of problems.