search

JavaJens / TextSecure

A secure text messaging application for Android.
GNU General Public License v3.0
72 stars 9 forks source link

Get determininistic builds working #45

Open patcon opened 8 years ago

patcon commented 8 years ago

Another issue reminded me that that OWS has with fdroid is that, by default, the APKs are signed by the buildserver rather than the developers. F-droid has a means to allow the developer to sign if the builds are byte for byte deterministic and repeatable:

https://f-droid.org/wiki/page/Deterministic,_Reproducible_Builds

Just creating this issue to track any efforts there, as that might make the OWS team more amenable to allow fdroid builds

Here's an example of an app built deterministically: https://github.com/guardianproject/lildebi#build-setup

h-2 commented 8 years ago

OWS was asked to just kindly provide their own f-droid repository, than they could have signed themselves, too, but Moxie did not like it. I don't think it makes much sense to try any convincing there right now.

patcon commented 8 years ago

Ah, ok, you're right that it might not be the actual solution, but I am of the firm believe that all package build systems should be deterministic, so I still wouldn't mind working on this. I want it to exist, as it's the only thing that guarantees public code reflects actual build artifact :)

relyt29 commented 8 years ago

This is a good idea and should be implemented. Especially with the fact that libtextsecure-java's sha512 hash differs during the build process for this fork in general, it will make the build process simpler from a trust perspective.

I also believe if this gets done and someone makes a post about the details of implementing it to the OWS mailing list it has a good chance of being implemented upstream as well

schachmat commented 8 years ago

I also agree that deterministic builds are needed, but not in the same context as the websockets branch. Considering the planned PR to the OWS repo, this branch should not be polluted by other features since it would only complicate the merge even more. Feel free to implement it an a separate fork or maybe @JavaJens wants to do it in a separate branch in his own repo.

JavaJens commented 8 years ago

I sadly don't have much spare time at the moment. But if someone makes a PR to upstream, I am open to merging that in here as well.