search

xmikos / fdroiddata

Eutopia.cz F-Droid Repository
GNU Affero General Public License v3.0
40 stars 8 forks source link

Future of LibreSignal #39

Closed ilf closed 7 years ago

ilf commented 7 years ago

Over on https://github.com/LibreSignal/LibreSignal/, there's an issue Future of LibreSignal now that Signal is Google-free.

One comment sais:

There are ways of shipping binaries with the F-Droid server: you don't need to rebuild the binaries. You can just get the APK from the signal.org site, check the signature, and ship that. Rebuilding from source doesn't bring any additional security benefit unless you actually check that the binary matches the original build.

This sounds like the ideal solution for me.

@xmikos: What do you think?

mimi89999 commented 7 years ago

The signatures won't match, so an update would mean loosing all app data.

ilf commented 7 years ago

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.

https://whispersystems.discoursehosting.net/t/how-to-get-signal-apks-outside-of-the-google-play-store/808

mimi89999 commented 7 years ago

New OWS signatures won't match old Xmikos signatures. And a signature mismatch means no update.

ilf commented 7 years ago

Yes, the switch from @xmikos LibreSignal signatures to OWS Signal signatures cannot happen in one repository, it needs to be manually.

But since we all switched manually from OWS Signal to @xmikos LibreSignal, we know how do that.

There are many benefits to this, see https://whispersystems.discoursehosting.net/t/how-to-get-signal-apks-outside-of-the-google-play-store/808. This little hiccup is worth it IMHO.

anarcat commented 7 years ago

On 2017-04-05 13:36:39, Michel Le Bihan wrote:

The signatures won't match, so an update would mean loosing all app data.

At some point, users will have to bite that bullet or forever be stuck in that fork. We just need to document a clear way to make that transition.

That's what you get when you do a non-reproducible rebuild with arbitrary signing keys.

xmikos commented 7 years ago

I am actually reviewing commits in every new version of Signal before releasing independent build of it as LibreSignal. I don't want to use builds by OWS (who can be some day forced to include backdoor in it), but my own builds verified by myself. Eutopia.cz repository is primarily my own personal repo.

LibreSignal (in eutopia.cz repo) is not a fork, what I am providing in my F-Droid repository are simply independent builds of official Signal. Originally I didn't want it to be renamed to something else, but this is what moxie wanted and to avoid confusion of users I have renamed it.

xmikos commented 7 years ago

Btw. does Signal reproducible builds really work? I have tried to make LibreSignal reproducible in the past (following instructions on Signal GitHub wiki page), but there were several problems:

  1. prebuilt Docker image had to be used (and of course this prebuilt image can't be trusted). Building your own Docker image according to OWS specification didn't work (there were some unavailable dependencies).
  2. if I am not mistaken shared native libraries couldn't be made reproducible (only Java parts were reproducible). But I am not 100% sure about this, it has been some time since I have tried it.
  3. whole apk couldn't be made reproducible if name of independent builds has to be changed to something else than Signal (but this point is somewhat moot, because if Signal really could be made totally reproducible, I can just publish official Signal builds in my repo after comparing them with my own builds)

Does anyone know if these points 1 and 2 has been fixed?

xmikos commented 7 years ago

I have just tried it again and it is still the same:

E: Version '2.19-0ubuntu6.7' for 'libc6:i386' was not found
E: Version '4.8.4-2ubuntu1~14.04.1' for 'libstdc++6:i386' was not found
E: Version '8u72-b15-1~trusty1' for 'openjdk-8-jdk' was not found

There is pull request https://github.com/WhisperSystems/Signal-Android/pull/5731 from september 2016 which should fix it, but it is still not merged :-/ Reproducibility of Signal builds is unfortunately a joke.

ilf commented 7 years ago

@xmikos: I understand your POV that you want to verify OWS source and build the APKs yourself. But you do realize that most people using your repo "just" want Signal via F-Droid and for that delegate "trust" to both OWS and you. This is suboptimal.

Reproducible builds solve that problem. OWS builds their build from their source, you build your build after verifying their source - and they should be identical. So it's great to see you looking at it!

  1. You got feedback at https://github.com/WhisperSystems/Signal-Android/pull/5731. Maybe you could be convinced to re-try the docker image?

  2. If your build is identical to OWS build, you don't need to rename the App!

Thanks for all your work.

xmikos commented 7 years ago

@ilf I agree that it is not optimal, but I don't have better solution at this moment. But I am still trying, I didn't give up ;-)

  1. I did re-try, but there seems to be still problems with this changed Dockerfile. It apparently uses deprecated Docker java base image and also older version of Android build tools than official Signal Dockerfile. Also Signal APK built with this Docker image is not reproducible (it differs from builds published on Google Play by OWS). I am trying to fix it and will report it to original author.

  2. I would still have problems because of auto-update mechanism in Signal Website build flavor. I would preferably change update URL to my own server (so that users would not be susceptible to potential backdoored version pushed by OWS update server), but this would break reproducibility. Right now it seems that user has to click on notification for auto-update to start, but this could change in future and anyway user could inadvertently update to Signal version not reviewed (and checked for reproducibility) by me. Maybe best option is to build a Play flavor instead of Website flavor, because Play flavor has auto-update mechanism disabled (but nevertheless it still should work via WebSocket if you don't have Google Play Services installed).

xmikos commented 7 years ago

Also there is still big problem with native shared libraries, which are not rebuild when building Signal in Docker. Using prebuilt native shared libraries defeats whole purpose of reproducible builds (there can be hidden native malicious code).

fungs commented 7 years ago
  1. Out of curiosity: Isn't OWS putting any secret API codes into the binaries at building time?
  2. 4.5.3 is the most recent Signal version. Would be nice to see that in your repo.
xmikos commented 7 years ago
  1. There are no secret API codes
  2. I have now reviewed and published builds of version 4.5.3 and 4.6.0
fungs commented 7 years ago

Nice and thanks for keeping up this work (although I'm 60% migrated to Wire, which will hopefully offer fdroid.org builds in the future: https://github.com/wireapp/wire-android/issues/233). At least they seem to be very open to it.

hex-m commented 7 years ago

LibreSignal tells me that it's outdated and will stop working in 8 days. Do you plan to release a new version @xmikos?

ingerling commented 7 years ago

@xmikos , I'm also interested, will there be an update? Otherwise I finally have to switch to the builds from the ows website....

jomo commented 7 years ago

I'd love this as well. F-Droid provides a nice way of updating, so I don't need to manually download APKs. I don't want to lose my conversations, nor my key ("safety number"), and preventing that is a bit of a hassle and requires root access when switching to an app signed by another identity.

Please let us know if there's anything we can do to help!

fungs commented 7 years ago

I would also love this project to keep running, just lice GNU IceCat, which is a code-reviewed, little behind version of Firefox.

hex-m commented 7 years ago

@jomo migration is mentioned in the LibreSignal FAQ. Should be possible without loosing anything.

xmikos commented 7 years ago

I have updated LibreSignal in my repo to latest version 4.9.6. Sorry for the extra long delay, I am now using Wire primarily (and I can definitely recommend it instead of Signal) and have a lot of work-related projects, so too little free time. And I really don't want to release new builds before I manually review all code changes (which is time-consuming). But I will try to build next updates more frequently. @hex-m @ingerling @jomo @fungs

fungs commented 7 years ago

I also switched over to wire, so the question really is if and how long you are willing to maintain the reviewed free build, or if there is maybe another solution, @xmikos

Another thing is that the different repos are kind of confusing, why is it in fdroid/archive and not fdroid main? And why keep a private repo? I while ago I had troubles getting the latest version on my Jolla, so I had to manually download the apk.

xmikos commented 7 years ago

@fungs The best solution would be reproducible builds of Signal, but I have tried it multiple times (see e.g. https://github.com/xmikos/fdroiddata/issues/39#issuecomment-292957239) and it simply doesn't work :-( We can just hope that OWS will fix reproducible builds in the future...

ilf commented 7 years ago

Having started this issue, I feel like I should be the one to close it. I no longer use LibreSignal and I cannot recommend people to use it.

  1. It's lagging too far behind.
  2. I really appreciate @xmikos work, but I know him less than moxie, so delegating "trust" to him can actually "weaken" a users "trust" in the codebase used.

The official builds from https://signal.org/android/apk/ work well, without any Google or Play Store, upgrade themselves, have the correct signatures, and are up-to-date.

Reproducible builds would be awesome, but IMHO that should be another issue.