What is the status of Delta Chat with regard to reproducible builds? (I.e., a guarantee that the binary build corresponds precisely to the source input (or the advertised source input).)
See:
2 Likes
There were no efforts to make DC builds reproducible so far because this would be quite some effort, esp. as we are developing a core in Rust and 3 different uis.
Thanks for your response. I was afraid the answer might be something
along those lines.
I would like to point out, as someone not involved in the development
of Delta Chat (and therefore itās easy for me to say), the following:
-
Applications like Delta Chat are a prime target for nation state
compromise. -
The open source nature of Delta Chat means that binary build
injection techniques are definitely on the menu. -
Binary injection during the build process is, for all practical
purposes, undetectable without repoducible builds. -
Such binary injections are able to cause catastrophic loss of
security properties. -
Certain groups of Delta Chat users may have a lot riding on the
integrity of the Delta Chat application.
What I am saying is that reproducible builds is not a nice-to-have,
but an essential property of the software, given its intended
application areas.
Naturally, there are other threat vectors, such as operating system
level compromise (Android, iOS and so on). But many of those issues
are outside of the control of the Delta Chat developers. Although
reproducible builds are difficult, they are not outside the control of
Delta Chat developers.
I would therefore recommend that reproducible builds be explicitly
entered somewhere into the list of priorities for future work on Delta
Chat.
Once again, Iām not saying that itās either quick or easy to do. Iām
just saying itās necessary.
David
1 Like
To be exact, the lack of accessibility to main sources by people in restricted nations like Cuba, already increase the risk of undetected binary injections or third party non-reliable modified builds as third party sources are the main way to obtain the app in many cases.
As for Session, in difference to Delta Chat apk releases, provides, at least, checksums and extra signatures for every provided build (https://github.com/loki-project/session-android/releases) in which some āissuesā finished in a few faulty hashes in some older releases with the time which was already criticized by the community, including me (https://github.com/loki-project/session-android/issues/179).
The problem of using binaries from untrusted sources is already solved
by publishing signed cryptographically secure checksums of the
official binary releases, like the Debian project does. It would
appear, therefore, that you have not yet appreciated the problem that
reproducible builds solve. The problem is that the Delta Chat
developers /themselves/ do not know, without having reproducible
builds, if they are distributing compromised binaries.
Of course, it is also not an argument that because some users may not
benefit, then all users will be made to suffer the same fate.
David
I wasā¦ supporting your proposition from the beginningā¦ and just added the extra case of Session for, at least, a little advantageā¦
Thank you. Apologies for the misunderstanding.
David
1 Like
The first step is to get reproducible builds for the core library, and it depends on this issue being solved: https://github.com/rust-lang/rust/issues/34902
It makes sense to try something like this https://github.com/rust-lang/rust/issues/50556 with the core library and report if it does not build the same binary.
1 Like
Yes, that seems a good place to begin.
David
In case anyone is interested in this:
On 18th September, Bernhard M. Wiedemann will give a presentation in German, titled Wie reproducible builds Software sicherer machen (āHow reproducible builds make software more secureā) at the Internet Security Digital Days 2020 conference.
Of interest:
After many years of development work, the compiler for the Rust programming language now generates reproducible binary code. This generated some general discussion on Reddit on the topic of reproducibility in general.
2 Likes
@David_Trudgett from the link you posted:
OK, well results for 1.45.0 say āunreproducibleā again, and the auto-generated diff did not complete after 2 hours. Shall I open an issue for CI integration tests on this? If I understand correctly there are concerns about it taking up too much resources, or something.
I tried building deltachat-core-rust with Guix.
Currently there is a trouble with dependency vendoring. Guix downloads all packages and places them into guix-vendor directory so the build can be carried out in an isolated environment without the network access.
cargo vendor produces this cargo/config.toml:
[source.crates-io]
replace-with = "vendored-sources"
[source."https://github.com/async-email/async-smtp"]
git = "https://github.com/async-email/async-smtp"
rev = "2275fd8d13e39b2c58d6605c786ff06ff9e05708"
replace-with = "vendored-sources"
[source."https://github.com/async-email/encoded-words"]
git = "https://github.com/async-email/encoded-words"
branch = "master"
replace-with = "vendored-sources"
[source."https://github.com/deltachat/lettre"]
git = "https://github.com/deltachat/lettre"
branch = "master"
replace-with = "vendored-sources"
[source."https://github.com/deltachat/rust-email"]
git = "https://github.com/deltachat/rust-email"
branch = "master"
replace-with = "vendored-sources"
[source."https://github.com/dignifiedquire/sqlx"]
git = "https://github.com/dignifiedquire/sqlx"
branch = "fix-pool-time-out"
replace-with = "vendored-sources"
[source.vendored-sources]
directory = "vendor"
But Guix generates this file manually and only provides a source replacement for crates-io source, so cargo attempts to download all the github dependencies and fails during the build phase.
One way to proceed is to get rid of github dependencies and ensure all the dependencies are on crates.io before making another release. Another is to teach Guix to add vendoring entries for git dependencies.
F-Droid announced support for reproducible builds:
Documentation is here:
https://f-droid.org/en/docs/Reproducible_Builds/
It allows developers to sign APKs with their own signature and F-Droid will distribute original APK if it is able to reproduce it.
2 Likes
Looks like NixOS will have a package for the core and KDeltaChat soon:
Nix has all the tools needed to check reproducibility, same as Guix.
Edit: NixOS now offers builds of libdeltachat core and python bindings for x86_64 and aarch64.
2 Likes
deltachat-rpc-server binaries in the latest release 1.136.2 are reproducible:
$ nix build .#deltachat-rpc-server-armv6l-linux
$ sha256sum result/bin/deltachat-rpc-server
0ef56ccd194ed68673d75cca38b56096fd67e87a469bca6b4a5e6d54baf9204c result/bin/deltachat-rpc-server
This is the same as what GitHub Actions CI built and uploaded to the release:
$ curl -sL https://github.com/deltachat/deltachat-core-rust/releases/download/v1.136.2/deltachat-rpc-server-ar
mv6l-linux | sha256sum
0ef56ccd194ed68673d75cca38b56096fd67e87a469bca6b4a5e6d54baf9204c -