Zen

Source string Source string

559/10000 · 559

The string is read only.

English Actions
For restoring, we agreed that it should happen in an in-person meeting. The process requires three shard holders meet with one encrypted backup holder, then the results need be given to a signing server operator. Requiring an in-person meeting could delay the restore process, but the added trust seemed worth it. So this is the default process. We could still switch to partially online process if the need arises. That would require the agreement of five participants.
We believe this is a secure and reliable backup procedure for very sensitive data. We welcome further scrutiny and plan to update the procedure as needed in a future meeting.
(_This meeting was paid for by the [FFDW-DVD grant]({% post_url 2022-02-05-decentralizing-distribution %})._)
Reproducible builds, signing keys, and binary repos
Earlier this year, we reported about our progress concerning [reproducible builds]({% post_url 2023-01-15-towards-a-reproducible-fdroid %}). Meanwhile, more and more apps are using this; you can find [some statistics here](https://gitlab.com/obfusk/fdroid-misc-scripts/-/blob/master/reproducible/overview.md): compared to about 20 apps in November 2022, the number of apps being built reproducibly went up by almost a factor of 10 to around 191 in September 2023\. About 2 out of every 3 apps newly added to F-Droid are using this path. But what exactly does „reproducible build“ mean, in easy terms and without all the „tech-buzz“?
All the years before, F-Droid created a dedicated key for each app to sign the published APKs, but now with reproducible builds F-Droid ships APKs that are signed by the upstream developer(s). Which proves to you that the developer confirmed: „this is what I intended to publish, this was built from my code“. And that it's distributed by F-Droid tells you: „F-Droid confirms, too, that this is the APK built from the very code the developer provided“. So neither of the two could have „sneaked in“ something not contained in the app's source code repository.
Verification at F-Droid, again in easy terms, happens this way: the app is built from the source code on F-Droid's build servers. Then the corresponding APK built by the developer is fetched, and compared against it. The only differences should be the signature files – as the APKs from the developer was signed using their private key, which F-Droid has no access to. If this is the case (i.e. the two APKs match), it was proven to be the very same „binary“ – and F-Droid can distribute the one signed by the developer.
You can find an outline of the process [here]({{ site.baseurl }}/en/docs/Inclusion_How-To/#reproducible-builds), and technical details in [this documentation]({{ site.baseurl }}/docs/Reproducible_Builds/).
Wins and caveats
A few advantages are pretty clear: higher trust is the first thing coming to mind, as now two parties (F-Droid and the developer) can both confirm the integrity of the distributed APK. But there's more to it. For one, if a developer has to push out some „emergency update“ (e.g. to fix a security issue, or something critical was broken) you'd no longer need to wait for a full build cycle or two to get hold of it. As the APK you've installed from F-Droid was signed using the developers' private key, you can simply take an APK they provide you directly by other means (e.g. via the app's repository at Codeberg, GitLab or Github) and update to that – provided you trust the developer enough – which you then must, as such builds are not (yet) verified by F-Droid.
So are there any „drawbacks“? Why does the header mention „caveats“? Well… F-Droid now provides APKs it did not sign itself. So what if an app's source repo was compromised by a malicious party which then modified the code and provided their own release, while the original author e.g. was on vacation, at the hospital or otherwise indisposed? They'd of course sign the APK with their own private key (as hopefully the original author kept their private key safe). But that must somehow be considered and dealt with. So meet:

Loading…

User avatar None

String updated in the repository

  1. F-Droid
  2. Website Posts
  3. English
All the years before, F-Droid created a dedicated key for each app to sign the published APKs, but now with reproducible builds F-Droid ships APKs that are signed by the upstream developer(s). Which proves to you that the developer confirmed: „this is what I intended to publish, this was built from my code“. And that it's distributed by F-Droid tells you: „F-Droid confirms, too, that this is the APK built from the very code the developer provided“. So neither of the two could have „sneaked in“ something not contained in the app's source code repository.
All the years before, F-Droid created a dedicated key for each app to sign the published APKs, but now with reproducible builds F-Droid ships APKs that are signed by the upstream developer(s). Which proves to you that the developer confirmed: „this is what I intended to publish, this was built from my code“. And that it's distributed by F-Droid tells you: „F-Droid confirms, too, that this is the APK built from the very code the developer provided“. So neither of the two could have „sneaked in“ something not contained in the app's source code repository.
9 months ago
Browse all string changes

Things to check

Long untranslated

The string has not been translated for a long time

Reset

Unpluralised

The string is used as plural, but not using plural forms

Reset

Glossary

English English
No related strings found in the glossary.

String information

Source string description
type: Plain text
Flags
md-text, read-only, safe-html
Source string location
_posts/2023-09-03-reproducible-builds-signing-keys-and-binary-repos.md
String age
9 months ago
Last updated
9 months ago
Source string age
9 months ago
Translation file
po/_posts.pot, string 3544