You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
xz got me thinking about how to make it easier for users to trust that the version of the app they've installed is built from the public code, and only the public code.
For the APK attached to the GitHub release page that's relatively straightforward; the APK on the release page can be compared to the APK built from the release workflow, and if they're byte-for-byte identical the user knows it was built using the workflow (which logs e.g., the git hash it was built from, the dependencies, etc).
For Google Play it's going to be more involved. An APK isn't sent to Google Play to be published, an app bundle (.aab) is sent. Google then repackages this in to different APKs for delivery to users depending on their device.
https://developer.android.com/guide/app-bundle/code-transparency is the way to do this; we can sign the files in the .aab file before it goes to Google, and those signatures persist in the APKs Google Play generates. Then we publish the public part cert, along with instructions for how users can verify that the files in the APK delivered by Google Play were signed by the private key from the public cert.
F-Droid publishes the key and build log for each version on the app page (https://f-droid.org/packages/app.pachli/) and the source tarball. Could provide instructions for the user on how to download the tarball provided by F-Droid, checkout the equivalent code from this repo, and compare the two. User still needs to trust the F-Droid build infrastructure.
Builds would be on the GitHub CI infrastructure, reduces the number of things that need to be trusted (although, of course, GH CI is a very attractive target)
Releases to users using F-Droid would be a lot faster (several days faster, given typical F-Droid build times)
Could publish Pachli Current here as well.
None of this covers "How can users trust the developers of the app?" or "How can users trust the code?", it's just "How can users verify the code they're running is the same as the code they can publicly inspect?".
The text was updated successfully, but these errors were encountered:
xz got me thinking about how to make it easier for users to trust that the version of the app they've installed is built from the public code, and only the public code.
For the APK attached to the GitHub release page that's relatively straightforward; the APK on the release page can be compared to the APK built from the release workflow, and if they're byte-for-byte identical the user knows it was built using the workflow (which logs e.g., the git hash it was built from, the dependencies, etc).
For Google Play it's going to be more involved. An APK isn't sent to Google Play to be published, an app bundle (.aab) is sent. Google then repackages this in to different APKs for delivery to users depending on their device.
https://developer.android.com/guide/app-bundle/code-transparency is the way to do this; we can sign the files in the .aab file before it goes to Google, and those signatures persist in the APKs Google Play generates. Then we publish the public part cert, along with instructions for how users can verify that the files in the APK delivered by Google Play were signed by the private key from the public cert.
F-Droid publishes the key and build log for each version on the app page (https://f-droid.org/packages/app.pachli/) and the source tarball. Could provide instructions for the user on how to download the tarball provided by F-Droid, checkout the equivalent code from this repo, and compare the two. User still needs to trust the F-Droid build infrastructure.
Longer term, maybe provide our own F-Droid binary repository (https://f-droid.org/en/docs/Setup_an_F-Droid_App_Repo/). This would be more work, but comes with the following benefits (I think, to be confirmed):
None of this covers "How can users trust the developers of the app?" or "How can users trust the code?", it's just "How can users verify the code they're running is the same as the code they can publicly inspect?".
The text was updated successfully, but these errors were encountered: