Reproducible Signal builds for Android | Hacker News Reader

Reproducible Signal builds for Android

whispersystems.org

105 pointsqznc18 comments

> Reproducible builds help to verify that the source code in our GitHub repository is the exact source code used to build the compiled Signal APK being distributed through Google Play.

This is huge; it eliminates one of the biggest issues with distributing through third-party app stores.

> Just to head off the inevitable deluge of GPG encrypted emails with dramatic subject lines, we are not doing this in response to any kind of legal threat or presssure. This is just a weekend hack, please don't make us regret it.

I wonder what kinds of mails like these they've received in the past to prompt this disclaimer?

>I wonder what kinds of mails like these they've received in the past to prompt this disclaimer?

I believe he is being a bit tongue-in-cheek. Moxie has previously mentioned his dislike of the typical emails he gets from the type of people that use GPG (http://www.thoughtcrime.org/blog/gpg-and-me/)

And a more recent statement: "Was reflecting on how the quality of my email inbox had become less awful lately, then remembered I added a rule to drop pgp encrypted mail." https://twitter.com/moxie/status/709492776635752448

Reading that, and the blog post linked to by sigmar, his stance comes across as rather belligerent; perhaps even childish. I would expect that if you wanted to communicate with someone who is privacy-conscious, and provides a public e-mail address linked to a GPG-identity, encrypting and signing your message to him or her is only civil and is to be expected.

I understand Moxie's criticism of existing crypto-tools, GnuPG in particular, and he makes some valid points, but dismissing anyone who mails you and uses GPG (because you have published your GPG public key) as nutjobs seems overly antagonistic. That to me seems at odds with the greater goal of facilitating easily attainable privacy and digital freedom for all.

It sounds like he's talking about encrypted mail from people he doesn't know.

I can't speak for others, but the proportion of email I get from strangers that ranks high on a content-quality scale is approximately zero. Encryption status, encoding and MIME types don't seem to have much to do with it.

Dislike is an understatement, I believe he's being disingenuous in that blog post. I don't want to speculate on his motives, your guess is as good as mine.

Even though GPG has been around for almost 20 years, there are only ~50,000 keys in the “strong set,” and less than 4 million keys have ever been published to the SKS keyserver pool ever. By today’s standards, that’s a shockingly small user base for a month of activity, much less 20 years.

Published keys are not a representative for gpgs userbase, a great amount of 'powerusers' (whatever you want to call those who need encrypted messaging to work) will not publish their keys for numerous reasons, only some of them technical.

Cryptopartys started like this and political activists still do this: you exchange keys in person, you'd never ever publish them on the net, you would not be part of moxie's 'shockingly small user base'.

There are two trust problems that verifiable builds are supposed to solve:

1. Did the authors manipulate the source code compared to what they published?

2. Did a third party manipulate the binaries on the distribution channel?

The process of verifying a build can be done through a Docker image containing an Android build environment that we've published.

For the verification, you now depend on a complex binary blob provided by the authors, that is distributed through a different channel (Docker images instead of Google Play).

This is a good solution to the second problem, but it does not preclude OWS insiders from injecting malicious code (they merely need to add the backdoor at the SDK level[0] and use that same SDK for the public releases). Such a manipulation could be performed by an evil insider, or be part of a "government cooperation". I am not saying that OWS is or will be doing this. This is merely an observation of the shortcomings of the overall solution.

[0] "Reflections on Trusting Trust" https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

> For the verification, you now depend on a complex binary blob provided by the authors, that is distributed through a different channel (Docker images instead of Google Play).

Nothing stops you from building the Docker image yourself using the Dockerfile provided in the repo. https://github.com/WhisperSystems/Signal-Android/blob/master...

But those Docker images are not reproducible. They don't build everything from source from a trusted, well-known set of bootstrap binaries, nor will they produce bit-identical binaries. Docker does absolutely nothing to aid in the task of reproducible builds. See https://reproducible-builds.org for more information about initiatives that are helping.

Using something like GNU Guix instead of Docker, one could make good progress towards a reproducible Android tool chain that produces bit-identical APKs. Reproducibility is an ongoing problem, but Guix has been carefully designed to maximize reproducibility and to help identify what isn't reproducible.

As much as I like this, I'm refusing to use Signal for Moxie's[1] stance on requiring access to the address book on iOS [2].

Regretfully I'm not skilled enough to modify the code and create a branch.

[1] https://news.ycombinator.com/item?id=11288169

[2] https://github.com/WhisperSystems/Signal-iOS/search?utf8=&q=...

Oddly, the Android version seems to work just fine if it doesn't have access to your contacts. (Like -ferinstance- if you use Cyanogenmod's Privacy Guard stuff to deny access.)

I don't know, but I've heard Internet Rumors that OWS has been having difficulty finding folks to work on the iOS version of Signal.

Not that you asked for it, but my stance on the read-contacts issue is this: if I can't trust OWS to treat the contacts information that the Signal client transfers to their server as confidential, then I sure as fuck can't trust them to actually resist the urge to subvert either their client or their server code (whether for financial gain, or because someone with a gun comes knocking). Given that I trust OWS to act with integrity, I don't see any significant harm in how they currently handle contact data.

CM's privacy guard doesn't deny access to the contacts, it returns a valid address book listing... just an empty one instead of your real contacts.

Privacy Guard was implemented well before the idea of individual permissions being denied made its way into the Android base, so most apps were not implemented with this expectation and would explode completely if the call to fetch the address book entries failed.

Which is just to say that that's not really a valid comparison.

> CM's privacy guard doesn't deny access to the contacts, it returns a valid address book listing... just an empty one instead of your real contacts. ... Which is just to say that that's not really a valid comparison.

Wot? It's totally a valid comparison.

The problem is transmission of contact information from your phone to a third party. Telling Signal that you have an empty contact list solves that problem, and it solves it far better than just throwing a permissions error or whatever when the software goes to request a contacts list.

> Oddly, the Android version seems to work just fine if it doesn't have access to your contacts.

You're specifically calling out CM's Privacy Guard where the app is unaware that it doesn't have access to your contacts. the difference in behaviour between "Android" and iOS is not "odd" because it's not a 1:1 comparison, and the CM way of doing it specifically mitigates the issue that arises.

A consistent comparison would be seeing what the app does when permission is denied via the runtime permissions in Android 6, because that - like iOS - informs the app that you've denied permission. There is no obvious incongruity between the apps here.

> A consistent comparison would be...

Ah! I see what you're saying (and the source of your objection) now. Thanks for clarifying!

The requirement of a mobile phone number and either Android or IOS, or a linked instance of one of those seems even more restrictive for a tool that claims to be all about privacy. The way governments are rapidly closing up methods to register a mobile phone number without ID are disconcerting, although predictable due to the common use of burner phones as communication device of choice for nefarious purposes.

I do understand this choice when judging Signal purely as a replacement for WhatsApp etc., but even then I wouldn't design a protocol based on the requirement of a mobile phone number and one of the two dominant mobile operating systems (and thus a smartphone).

Branching won't help because you won't be able to replicate their bundle ID when signing, so no push notifications.. A jailbreak tweak seems more appropriate Current version needs an SMS to activate, so unless you use a throwaway SIM you're compromised anyway.

The proper solution is to have own app communicate with your own server with and have that server use a proper Tor-routed IM protocol that actually conceals metadata like your contacts' identities

Reply on news.ycombinator.com