Commit 0fee343a authored by Michael Pöhn's avatar Michael Pöhn

update reproducible builds documentation

parent 6fcafe8b
---
layout: page
title: Reproducibile Builds
title: Reproducible Builds
---
F-Droid supports
[reproducible builds](https://reproducible-builds.org) of apps, so
that anyone can run the build process again and reproduce the same APK
as the original release. This means that F-Droid can verify that an
app is 100% free software while still using the original developer's
APK signatures. Ideally, all of the built APKs will have the exact
same hash, but that is a more difficult standard with less payoff.
Right now, F-Droid verifies reproducible builds using the APK
F-Droid supports [reproducible builds](https://reproducible-builds.org)
of apps, so that anyone can run the build process again and reproduce
the same APK as the original release. This means that F-Droid can
verify that an app is 100% free software while still using the original
developer's APK signatures. Ideally, all of the built APKs will have
the exact same hash, but that is a more difficult standard with less
payoff. Right now, F-Droid verifies reproducible builds using the APK
signature.
This concept is occasionally called "deterministic builds". That is a
......@@ -23,28 +22,61 @@ can run the process and end up with the exact same result.
### How it is implemented as of now
Publishing signed binaries from elsewhere (e.g. the upstream developer)
Publishing signed binaries from elsewhere (e.g. the upstream-developer)
is now possible after verifying that they match ones built using a
recipe. Everything in the metadata should be the same as normal, with
the addition of the `Binaries:` directive to specify
where (with pattern substitution) to get the binaries from.
Publishing only takes place if there is a proper match. (Which seems
very unlikely to be the case unless the exact same toolchain is used, so
I would imagine that unless the person building and signing the incoming
binaries uses fdroidserver to build them, probably the exact same
buildserver id, they will not match. But at least we have the
functionality to support that.)
This procedure is currently implemented as part of `fdroid
publish`. At the publish step, there are two options: a) sign
the built apk, or b) download a signed binary from elsewhere, compare it
with the built one, and if they match publish the downloaded (externally
signed) one. Option b) is enabled by having a
`Binaries:https://foo.com/path/to/myapp-0.1.apk`
directive in the metadata, to provide a URL where the binaries are to be
retrieved from (with substitutions for the version number in the APK
file name).
recipe. Publishing only takes place if there is a proper match. (Which
seems very unlikely to be the case unless the exact same tool-chain is
used, so I would imagine that unless the person building and signing
the incoming binaries uses fdroidserver to build them, probably the
exact same buildserver id, they will not match. But at least we have
the functionality to support that.)
This procedures are implemented as part of `fdroid publish`. At the
publish step, the reproducibility check will follow this logic:
![Flow-chart for reproducibility check](../../../assets/docs/reproducible-builds/publish.png)
#### Publish both (upstream-)developer singed and F-Droid signed APKs
Use this approach for shipping a version of an app, with both
(upstream-)developer signed and F-Droid signed APKs. This enables us
to ship updates for users who installed apps from other sources than
F-Droid (eg. Play Store) which are therefore singed by the
app-developers, while also shipping updates for apps which were built
and singed by F-Droid.
This requires to put (upstream-)developer signatures into fdroiddata.
We provide a command for easily extracting signatures from APKs:
$ cd .../fdroiddata
$ fdroid signatures F-Droid.apk
You may also supply HTTPS-URLs directly to `fdroid signatures` instead
of local files. The signature files are extracted to the according
metadata directory ready to be used with `fdroid publish`. A signature
consists of 3 files and the result of extracting one will resemble this
file listing:
$ ls metadata/org.fdroid.fdroid/signatures/1000012/
CIARANG.RSA CIARANG.SF MANIFEST.MF
#### Exclusively publishing (upstream-)developer signed APKs
For using this older approach, everything in the metadata should be the
same as normal, with the addition of the `Binaries:` directive to
specify where to get the binaries from. In this case F-Droid will never
attempt to ship APKs signed by F-Droid. Should `fdroid publish` manage
to verify that a downloaded APK can be built reproducibly, the
downloaded APK will be published. Otherwise F-Droid will skip
publishing this version of the app.
Here is an example for a `Binaries` directive:
Binaries:https://foo.com/path/to/myapp-%v.apk
Also see: [Build Metadata Reference - Binaries](../Build\_Metadata\_Reference/#Binaries)
### Verification builds
......@@ -99,7 +131,7 @@ otherwise reproducible build where the only difference is the
The "_platform_" is part of the Android SDK that represents the
standard library that is installed on the phone. They have two parts
to their version: "version code", which is an integer that represents
the SDK release, and the "revision", which represents bugfix versions
the SDK release, and the "revision", which represents bug-fix versions
to each platform. These versions can be seen in the included
_build.prop_ file. Each revision has a different number in
_ro.build.version.incremental_. Gradle has no way to specify the
......@@ -120,7 +152,7 @@ A standard part of the Android build process is to run some kind of
PNG optimization tool, like `aapt singleCrunch` or `pngcrush`. These
do not provide deterministic output, it is still an open question as
to why. Since PNGs are normally committed to the source repo, a
workaround to this problem is to run the tool of your choive on the
workaround to this problem is to run the tool of your choice on the
PNG files, then commit those changes to the source repo (e.g. `git`).
Then, disable the default PNG optimization process by adding this to
_build.gradle_:
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment