How to get Signal APKs outside of the Google Play Store

Feature Requests Android Feature Requests
1

Since websocket support has entered Signal it is time to revisit the old topic of getting Signal released outside of the Google Play Store infrastructure. A published a lengthy comment about this in the Eutopia F-Droid repository issue tracker, and was eventually told this was a good place to bring up this topic with the OWS community. So I have taken some time to reshuffle that comment and update it with new information to have a broader discussion with the OWS community about how we could make Signal accessible to non-Google users on Android.

Originally, OWS wasn’t very comfortable with F-Droid distributing Signal. A rationale that was given boiled down to 4 major things missing, in July 2013:

  1. crash reporting
  2. stats gathering
  3. automatic updates
  4. ways knobs to turn features on and off for different builds in the build system

In this earlier discussion, more things were mentionned:

  1. app (virus, presumably?) scanning
  2. f-droid encourages users to tick the “allow 3rd party APKs” knob which is a security issue

Moxie explicitly requested f-droid to not distribute the APK is in this comment. There’s also a screenshot of a twitter conversation that dates from when Signal actually was on F-Droid where moxie asks for the APK to be removed from F-Droid, if i remember correctly. Moxie also directly intervened in the LibreSignal tracker to explicitly ask not to use the name “Signal” for derivative products that were not exactly the same as Signal.

We could also mention that OWS were working on their own “non-Play distribution framework” (see this comment from December 2013) but it’s unclear whether this lead to anything specific. Presumably, this was stalled in February 2014 when moxie realized the effort was pointless without non-GCM push notifications, so maybe this is something OWS would consider again.

The status of each issue in there is, from what I understand:

  1. crash reporting: OWS was working on implementing a native solution for this anyways, but this is an F-Droid limitation, although 0.98 client implemented crash reporting with ACRA - it’s unclear to me if that applies to apps deployed with F-Droid or just the F-Droid client
  2. stats: there were stats in f-droid up to 2013, but they were turned off, because they were useless. a more detailed rationale is in the FAQ, although in September 2016, hans mentioned some stats could be reinstated. so F-Droid limitation here as well.
  3. automated upgrades: the situation has improved significantly on F-Droid’s side here. while by default it’s not possible, once you enable the privileged extension (which should arguably be done in distributed ROM or when flashing anyways), automated upgrades are possible. failing that, F-Droid can now download all APKs in the background but bulk update is still missing. so another F-Droid or ROM/install process limitation here.
  4. build knobs: i have no idea where things stand there, I am not sure what it’s for anyways, but presumably, with the new non-GCM support mentioned earlier, this may be fixed.
  5. app scanning: as far as I know, nothing is being done here on the official F-Droid repo, and nothing is planned there either. so another F-Droid limitation here.
  6. bad security practices: with the new privileged extension, it’s possible to flash F-Droid directly with the ROM and avoid ticking that bad checkbox, so that’s also fixed, provided F-Droid is installed correctly.

Moxie has recently commented that what is needed is:

  1. A small well-written library that we can link into Signal which does
    crash reporting, checking for updates (and posting notifications for
    the user), and reporting basic stats.
  2. A simple web-app that looks like the Play Store console, which
    allows us to publish new APKs, display crash reports, and display basic
    stats.

Then we could link to the signed APK from our website, get crash reports and stats, and make sure users are keeping up to date.

Therefore, I guess we can say that what has been resolved is:

  1. automated upgrades (for privileged f-droid, of course)
  2. build knobs (presumably?)
  3. bad security practices
  4. app scanner (not necessary?)

So what remains to be done for F-Droid inclusion, according to OWS, would be:

  1. crash reporting
  2. stats
  3. webapp to upload binary APKs and display the aforementioned crash reports and stats

The webapp approach seems different than the approach F-Droid has taken so far, which is more connected to the broader reproducible builds effort. Right now, it is possible for F-Droid repositories to reuse existing binaries and signatures, provided that the output matches what is built in the server’s environment, according to this wiki page. Since OWS has made significant efforts to make Signal more reproducible, this could possibly work, although it would mean an F-Droid repo would pull binaries from some public location instead of OWS pushing binaries to a F-Droid repository. It is also unclear to me whether we need the multiple signing key support feature in F-Droid, which remains to be implemented.

So I believe it is getting more and more possible to distribute Signal on F-Droid or at least outside the Play Store. There’s just a few hurdles along the way. The first of which is to make sure my report is accurate. :) I would say the next step for this work would be:

  1. review this report and spot any inaccuracies - i guess it’s correct until further notice
  2. wait for the non-GCM build stuff to be released (which should be real soon now) - it’s now released
  3. make sure F-Droid can build Signal reproducibly
  4. ask nicely the OWS folks to see if they are comfortable with the remaining limitations seems like crash reporting and stats is still something that OWS strongly requires
  5. if not, implement crash reporting, stats and app scanning (or whatever remains) in F-Droid / Signal
  6. make a pull request on F-Droid with the shiny new build
  7. victory.

Thanks in large part to moxie himself (but also to the F-Droid folks), we are much, much closer to a liberated signal than we were 4 years ago. The server side is still proprietary now publicly available under the AGPLv3. The client is also fully free software, optionally including the dependencies, so that’s really encouraging. I would recommend people reconsider their strong positions and see how it is, after all, possible to collaborate in a positive way. The Noise folks really showed us the way here, and we should probably be grateful to them as well…

In the meantime, people can install the APK directly from signal.org and signatures can be verified with the apksigner commandline program (e.g. apksigner verify --print-certs Signal-website-release-3.31.4.apk).

11 Likes
2

Don’t forget that OWS could setup their own f-droid repository as the Guardian Project has. This means they can implement some of the features still required themselves such as the stats, build system and app signing.

That’s how Noise was being distributed in f-droid. I’m sure because Signal is such a popular app, the f-droid folks would add a checkbox to enable its repo in the menus by default again like the Guardian Project.

I would highly be in favour of community efforts to help out f-droid and work on some of these features for obvious reasons :stuck_out_tongue_closed_eyes:

https://f-droid.org/wiki/page/Installing_the_Server_and_Repo_Tools

6 Likes
3

Thanks for the conclusion on this topic. As an F-Droid developer, I want to resolve some outstanding questions.

There are plans on checking APKs on viruses.

Crash reporting/ACRA is only used in the client itself, so an app needs to implement ACRA itself.

Like you mentiones correctly, it’s also planned to do an opt-in popularity contest.

With the privileged extensions it’s possible to automatically update apps in the background. We’re working on getting it included in popular ROMs (Copperhead, FairPhone, Lineage).

If F-Droid is included in the official repository, I think it’s the best if it is done by reproduciable builds. The workflow would be:

  • OWS pushes source code and binary of new version
  • F-Droid builds source code and compares it with the official one
  • F-Droid publishes the OWS signed APK

Like @georgeowell said, it’s also possible for OWS to set up their own repo. This can be done by their CI too.

I posted a link to this thread in the F-Droid forum and pinged some other devs.

5 Likes
4

glad to see all this great work done on f-droid! should there be an issue in the f-droid issue tracker to regroup all those or tracking those here is sufficient?

1 Like
5

The F-Droid privileged extension doesn’t currently work on Android 7.1.1 and previously had various rough edges which is why we aren’t yet including it in CopperheadOS. It will be included once it works and there’s confidence in it being well maintained so that it doesn’t block us from upgrading to new major releases of Android within a couple weeks. If it’s not compatible with a new version of Android, then we’ll need to be able to drop it temporarily, so we need to have a way of going back to F-Droid being a platform app if necessary so that we’ll at least not require users to enable unknown sources, but the automatic app update feature won’t work. Android doesn’t really handle changes in system app keys properly without wiping.

CopperheadOS now has automatic background OS updates for Pixel phones so the lack of automatic F-Droid app updates is more prominent than ever.

2 Likes
6

Related commit:

2 Likes
7

That’s a solution for most users, but we need it available without users enabling unknown sources and unattended upgrades will need to work. The official builds for the Play Store are perfectly good but I don’t think it would be legal to redistribute them. If we were able to redistribute those we wouldn’t need to make rebranded builds. It’s already unnecessary to make any modifications to the code so the issue is mostly solved.

8

Not legal? Why not? Signal is free software, after all… It may be illegitimate or against OWS’s wishes, but that’s hardly a legal requirement.

1 Like
9

Signal is free software, which is why it’s legal to make a rebranded build of the same code (Noise) but that doesn’t necessarily mean it’s okay to make a build called Signal or to redistribute the official Signal builds. Trademark law is separate from copyright law. If they want to control the update mechanism unless they’re relying on the Play Store for their trademark to be used, then that’s their right.

10

Now that there seems to be a commit for 3.31.0 (Support for website distribution build with auto-updating APK · signalapp/Signal-Android@9b8719e · GitHub) that is going to enable this, I’d like to know how I can cleanly disable automatic updates in a self-built version. For most people this would result in install errors anyway because of non-matching signatures.

I can of course completely remove the update functionality but how do I cleanly tell the compiler I’m building a play store version?

11

Apparently that commit doesn’t introduce fully automatic updates. It just shows a notification saying “A new version of Signal is available, tap to update”.

I guess build and / or assembleRelease will output both variants. If you only want the play flavor, ./gradlew assemblePlayRelease should work.

12

sure, of course. i see what you mean and stand corrected. :) it’s kind of crazy that we can trademark common words like “Signal” or “Apple”, but there you go…

1 Like
13

I tried to build the 3.31 branch to test it but webrtc is apparently not yet updated to M57. But when it outputs 2 versions in Android Studio the problem is solved anyway.

14

I would like to switch from the Google Play Store version to the non-play version with automatic updates. Can I do this while preserving my chat history and secret numbers? (I would prefer if my contacts did not get a warning about changed secret numbers)

I’m confused about johanw666’s comment above. If I build the non-play version myself and then use the automatic update function, it will not work because of different signatures? Then how can the update functionality be used?

1 Like
15

You can now install Signal from outside of Play:

I don’t recommend that people do this, but we’ve set this up as a harm reduction strategy since people are already running random APKs signed by other random people instead.

10 Likes
16

3.31.4 already I see? Source code release is only at 3.31.2 + something and Play release at 3.31.3.

1 Like
17

Is this already the GCM-free version?

1 Like
18

Available at GitHub right now.

1 Like
19

That’s great!

Here’s how to verify the fingerprint matches:

$ apksigner verify --print-certs Signal-website-release-3.31.4.apk
Signer #1 certificate DN: CN=Whisper Systems, OU=Research and Development, O=Whisper Systems, L=Pittsburgh, ST=PA, C=US
Signer #1 certificate SHA-256 digest: 29f34e5f27f211b424bc5bf9d67162c0eafba2da35af35c16416fc446276ba26
Signer #1 certificate SHA-1 digest: 45989dc9ad8728c2aa9a82fa55503e34a8879374
Signer #1 certificate MD5 digest: d90db364e32fa3a7bda4c290fb65e310
WARNING: META-INF/services/com.fasterxml.jackson.core.JsonFactory not protected by signature. Unauthorized modifications to this JAR entry will not be detected. Delete or move the entry outside of META-INF/.
WARNING: META-INF/services/com.fasterxml.jackson.core.ObjectCodec not protected by signature. Unauthorized modifications to this JAR entry will not be detected. Delete or move the entry outside of META-INF/.

You may be able to get something out of jarsigner as well, but that one checks the whole cert tree and didn’t give me a SHA-256 hash that I could check.

Also, for f-droid folks, while you need Javascript to see the download button, the actual APK is available on Amazon Cloudfront through the updates.signal.org domain, for example, here’s Signal-website-release-3.31.4.apk.

I’ll update the summary with the progress.

Thanks!

3 Likes
20

I have no plans to distribute this through f-droid, and don’t see what the advantage of doing so would be. I consider this issue to be resolved, and I really hope the people distributing random/broken builds of Signal signed with random keys will stop, or at least stop using the service we maintain at our expense, and stop directing their users to us when they need support. It is making it more difficult to do our work.

5 Likes