Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Request: Google Play signed download alternative #127

Open
countrygeek opened this Issue · 149 comments
@countrygeek

I was about to suggest this before reading the infamous issue 53. It is sad to see that FDroid and WhisperSystems could not work together, I truly enjoy both projects. Needless to say a google alternative is required - google more and more frequently involves itself in privacy violations. I am opening this ticket in hopes that an alternative of some sort is made.

Possibilities:
1) WhisperSystems creates it's own official FDroid repository, as did GuardianProject:
https://guardianproject.info/2012/03/15/our-new-f-droid-app-repository/

2) WhisperSystems provides an APK somewhere out there for people to download with simple instructions on how to verify it's not been tampered with.

In the event this is not done users not wanting Google will have to compile it from source, which although can be done, is a major inconvenience especially to newbies. Just for reference, there seems to be a large interest in migrating away from google. e,g, the NoGAPPS project:
http://forum.xda-developers.com/showthread.php?s=a7bf27eb98e3bcefb7e58fb46d09710b&t=1715375

I hope you all come up with a resolution. Thanks and keep up the great work! :)

@moxie0
Owner

Hey @countrygeek, let me provide a little color on why I've been reluctant to distribute APKs outside of Google Play.

First, I'm concerned primarily with the security of our users, and am interested in targeting a demographic that does not know what a checksum or signature is. You might call them "newbies," but personally I think we're doing a good job if these are the bulk of our users.

It may be an unpopular opinion, but I think the two worst security moves that an average user can make are rooting their device, or ticking the "allow 3rd party APKs" box in Android's settings. As bad as Google is, I believe that these actions make users susceptible to something that is much worse.

We are reluctant to distribute raw APKs for a few additional reasons:

1) No upgrade channel. Timely and automatic updates are perhaps the most effective security feature we could ask for, and not having them would be a real blow for the project.

2) No app scanning. The nice thing about market is the server-side APK scanning and signature validation they do. If you start distributing APKs around the internet, it's a reversion back to the PC security model and all of the malware problems that came with it.

3) No crash reporting. We are able to react very quickly to crash bugs through exception reports.

4) No stats. We are largely dependent on Play for knowing how many users we have, what types of devices they're running, and what version of Android they have. This allows us to make decisions about where to prioritize development and which platforms we should be supporting.

5) Avoiding Play alone is not a privacy win. Many people seem to be under the impression that avoiding Play prevents their device from phoning home to Google, but that's not the case. On 2.2+, if you have the GSF on your device, it will phone home whether you have a Play account registered or not.

So that's where we are. I believe that the decision not to distribute prebuilt APKs achieves the following balance:

1) It does not encourage the average user to tick "allow 3rd party APKs" in Android settings.

2) It allows "power" users who can appropriately manage the risks to install TextSecure without Play by building from source.

The thesis essentially being, if you aren't able to build TextSecure from source, you probably aren't capable of managing the risks associated with 3rd party sources.

@jamesbeebop

FWIW I appreciate this posture. The usefulness of this app increases for me every time a friend or family member installs it ... most of whom aren't power users.

@countrygeek

@moxie0 Thanks for clarifying, it does help me better understand your thoughts on it.

However, I have some possibilities for what you mentioned.
1) No Upgrade Channel. Most Debian-based distros suffer the same, which is why they made PPA's. Further reason to offer a repository of your own which is only available via HTTPS and synced as soon as a build is made. It can be GPG signed for powerusers who are unable to compile the tool everytime a new build is made. This can be due to a number of reasons, slow connections or unreliable and censored connections while trying to download the entire Android SDK.

Don't forget the people in Arab Spring. A quick download of an APK from a trusted party vs. an entire tool-chain when Google Play is blocked is more practical.

2) No App Scanning - Agreed. Although Google does a fairly poor job as well, plenty of active malware is inside the market. The best defense a regular user can do is watch their Permissions and install an Anti-Virus. "Powerusers" could install PermissionBlocking software and firewall their applications, as well as hash check them and check their GPG signatures.

3) No Crash Reporting - I think Mozilla's Fennec project did an excellent job of this -
https://wiki.mozilla.org/Mobile/Fennec
They use their own crash reporter which doesn't require Google to function.

4) Stats - understandable, but I think users would prefer to opt-in to sharing statistical information. e.g. Cynanogen Mod asks if this "OK" before sharing. Google only asks if it's OK to share a crash report, the rest is fair game.

5) Definitely Agree, Google controls many facets of the phone - Oh and let's not forget CarrierIQ. That's why NoGAPPS and Replicant Project is definitely something to watch long-term.
http://replicant.us

I believe, as rightly communicated in your other tool, Convergence.io - there must also be decentralization in layers of security. If Google has complete central control, and if they ever become compromised the entire network and users are then compromised; additionally, if it fails or is blocked it becomes impossible to access. That's why there needs to be fallback nodes/mirrors whatever you want to call them.

Outside the scope of this project, I think there should be a repository which is peer-reviewed for security, as well having an established WebOfTrust, perhaps P2P based, that doesn't require users to uncheck "3rd party apps" and is open-source.

FDroid for example (as soon as more security measures are in place) could become the official repository on Replicant devices. Then users would not have to uncheck 3rd party apps. That's when tools like this should be included in the repository and updated regularly, as well as being system apps in ROMs. It would also need to regularly pull commits and updates like Arch so there was no delay that puts users at risk.
But that's for hopeful dreaming - until then we have we have.

@moxie0
Owner

1) No Upgrade Channel. Most Debian-based distros suffer the same, which is why they made PPA's. Further
reason to offer a repository of your own which is only available via HTTPS and synced as soon as a build is
made. It can be GPG signed for powerusers who are unable to compile the tool everytime a new build is made.
This can be due to a number of reasons, slow connections or unreliable and censored connections while trying to
download the entire Android SDK.

Generally speaking, comparisons to the PC world are not going to resonate with me. The security model for desktops (unix-based and windows-based) is completely broken, and I think the mobile environment should be a chance to rectify our past sins, not copy them.

The current situation is that it's not (rightly!) possible for a 3rd party app to automatically install an APK. This fundamentally prevents auto-updates from being a reality outside of Play.

Don't forget the people in Arab Spring. A quick download of an APK from a trusted party vs. an entire tool-chain
when Google Play is blocked is more practical.

Unfortunately, circumvention problems extend beyond the download. RedPhone depends on GCM, and soon TextSecure likely will as well. My sense is that other projects are better positioned to deal with circumvention in the general case.

2) No App Scanning - Agreed. Although Google does a fairly poor job as well, plenty of active malware is inside
the market. The best defense a regular user can do is watch their Permissions and install an Anti-Virus.
"Powerusers" could install PermissionBlocking software and firewall their applications, as well as hash check
them and check their GPG signatures.

Actually, the malware incidence inside of the Play Store is exceptionally low. Compare it to desktop malware, and it's nonexistent. The bulk of mobile malware (drudged up by AV companies to justify their existence) has been in 3rd party app stores and random drive-by downloads. And the problem with depending on mobile AV is that mobile AV is a complete joke, even more so than desktop AV. These apps have no system integration, so they literally can't do anything other than look at a 3rd party APK at install time. It's quite easy to evade any signature detection and then simply disable the AV app. This is already happening.

Again, I feel like we should be desperately trying to avoid what we inherited with the desktop paradigm, rather than reproducing it.

3) No Crash Reporting - I think Mozilla's Fennec project did an excellent job of this -
https://wiki.mozilla.org/Mobile/Fennec
They use their own crash reporter which doesn't require Google to function.

A good crash reporting solution is essentially a product in itself. There are entire companies built around mobile crash reporting, but as far as I've seen, none of them are as good as the default Play reporting. To ask that I develop and maintain my own is a big ask. I can't emphasize how important this is to the project.

4) Stats - understandable, but I think users would prefer to opt-in to sharing statistical information. e.g.
Cynanogen Mod asks if this "OK" before sharing. Google only asks if it's OK to share a crash report, the rest is
fair game.

Build me a high quality stats reporting solution with a nice web interface that displays graphs and trends of time. Then manage the server side hosting for me, and I'll use it. =)

I believe, as rightly communicated in your other tool, Convergence.io - there must also be decentralization in
layers of security. If Google has complete central control, and if they ever become compromised the entire
network and users are then compromised; additionally, if it fails or is blocked it becomes impossible to access.
That's why there needs to be fallback nodes/mirrors whatever you want to call them.

This is actually how the Play Store works right now. Google does not have complete control over all updates: I sign all APKs with my own code signing key that is kept offline. These signatures are enforced by the PackageManagerService on each user's device, not by the Play Store itself. The mechanics are very similar to TACK (http://tack.io), which is what we're currently advocating for the TLS world.

This is in huge contrast to how the bulk of apps on fdroid are distributed. Most are not signed by the developers, but by fdroid itself, with keys that they keep online. I believe this is a dangerous situation, and is one of the primary reasons (along with having to enable 3rd party sources) that I don't recommend using fdroid.

@Argafal

I am happy to see this issue discussed here and i would like to add another user requesting this app to be available from outside Google Play. I do not use Google Play since I do not wish to bundle my phone with a Google account. I do see your reasoning in why you are reluctant to support anything else, but I think you should reconsider this, at least for alternatives that actually care about security and open source software. I fully agree that decentralization is a vital requirement for secure designs and that monopolies should be avoided. History shows many examples.

For my daily use I use fdroid exclusively, since I see the need for a trustworthy source of applications and an update mechanism. Fdroid provides this for me at the level that I require. Yes, some details could be improved (such as statistics), but I think it's very much a step in the right direction. I do believe the fdroid folks are in general very open to suggestions.

I very much wish I could get the most recent TextSecure through fdroid as well rather than having the choice between running a version older than Methusalem or building from source. Avoiding the former should be in your very own interest as the author of the app. The latter requires me to constantly monitor for updates and bugs and is manual work which I wish I could avoid. Since most of my friends and family use cyanogenmod and fdroid as well I am very reluctant to suggest them to upgrade to TextSecure, since that would put me in the apk maintainer position.

For these reason I would greatly appreciate to see TextSecure back in fdroid, and I would very much hope you reconsider your position on this.

@mvdan

@moxie0 Might I give my five cents here?

I've gone through all the discussions on this, and this is my overall conclusion: Your concern here seems to be the safety of your users. You don't want them ignoring the availability of newer versions, or downloading APK's from sources that don't provide you with use/device statistics. Is that correct?

Now, here's my point of view - What about the users who do not want to use Google Play and do not want to follow your advice? Surely you can consider that as harmful to them - but that's their problem, not yours. And the amount of people who use F-Droid is in no way comparable to the amount of people who use Google Play.

Moreover, I would certainly not think that by keeping F-Droid from packaging your software you are getting more installs on Google Play. Most of the people who use it would never consider using Google, thus you're just making life harder for these people. Nor are you winning anything by that prohibition.

Please do tell me if I understood anything the wrong way. I just started packaging for F-Droid as a hobby, and I'd like to package your software in the following days. Hopefully there won't be a problem with that.

@Argafal

mvdan, thanks for adding this. Indeed I would never consider using Google Play, that was the point I was trying to make. I build it myself until I find an alternative way of getting the app in a recent version. Unfortunately my grandma can't do that (building it herself) so she can't use it. ;)

@dalb8

If the app uses GCM will it be usable without Google Play?

F-Droid admin does not keep the keystore online: how could one come to that conclusion?

He signs the apks, thus we know if updates are also signed by him; I don't see why this fact should upset the whole idea of sharing software as set out in the GNU GPL.

@moxie0
Owner

@Argafal

I am happy to see this issue discussed here and i would like to add another user requesting this app to be
available from outside Google Play. I do not use Google Play since I do not wish to bundle my phone with a
Google account. I do see your reasoning in why you are reluctant to support anything else, but I think you should
reconsider this, at least for alternatives that actually care about security and open source software. I fully agree
that decentralization is a vital requirement for secure designs and that monopolies should be avoided. History
shows many examples.

But I'm reluctant to distribute APKs outside of the Play Store precisely because I care about the security of TextSecure users.

Additionally, many folks seem to think that not adding a Google account to their device is a privacy win, when that's rarely the case. If your device has GSF installed, the privacy implications are the same whether you have a Google account associated or not.

For my daily use I use fdroid exclusively, since I see the need for a trustworthy source of applications and an
update mechanism. Fdroid provides this for me at the level that I require. Yes, some details could be improved
(such as statistics), but I think it's very much a step in the right direction. I do believe the fdroid folks are in
general very open to suggestions.

It's not just statistics. The problem is the security model. The bulk of applications distributed through fdroid are signed by keys that belong to the fdroid maintainers, and which are kept online. This means that the fdroid maintainers themselves, or any attackers who compromise fdroid, are capable of pushing malware to your device.

This is a huge contrast to Google Play, where every app is signed by keys that belong to the app's developers. Google, or attackers who compromise Google, are not capable of pushing rogue updates.

I very much wish I could get the most recent TextSecure through fdroid as well rather than having the choice
between running a version older than Methusalem or building from source. Avoiding the former should be in your
very own interest as the author of the app. The latter requires me to constantly monitor for updates and bugs and
is manual work which I wish I could avoid. Since most of my friends and family use cyanogenmod and fdroid as
well I am very reluctant to suggest them to upgrade to TextSecure, since that would put me in the apk maintainer
position.

Again, I know that this is probably an unpopular opinion, but if you've set your "less technical" friends and family up with cyanogenmod and fdroid, I believe that you've very seriously compromised their security. Both cyanogen and fdroid seriously compromise the security gains that we've made in the mobile environment and are a reversion back to the desktop security model:

1) Cyanogen runs things as root, completely circumventing the development of a fine grained permissions system. They've also made a number of tradeoffs that further weaken its security.

2) In order for your friends to run fdroid, they've had to tick "allow 3rd party sources," which is probably the single most effective malware prevention mechanism for less savvy users.

It's exactly this (setting less technical users up with things like fdroid) that I am afraid of.

For you, compiling and installing from source once a week is literally three commands: git pull && ant release && adb install -r bin/TextSecure-release.apk. For your friends who are not technically capable of doing this, I believe that this means they aren't savvy enough to tick "allow 3rd party sources" responsibly.

I totally agree that 3rd party app store alternatives seem cool, but until they're done securely and correctly, I'd prefer not to participate.

@moxie0
Owner

@mvdan

Now, here's my point of view - What about the users who do not want to use Google Play and do not want to
follow your advice? Surely you can consider that as harmful to them - but that's their problem, not yours. And the
amount of people who use F-Droid is in no way comparable to the amount of people who use Google Play.

Moreover, I would certainly not think that by keeping F-Droid from packaging your software you are getting more
installs on Google Play. Most of the people who use it would never consider using Google, thus you're just
making life harder for these people. Nor are you winning anything by that prohibition.

I can't willingly participate in something that I believe is a bad idea. I can't sign and distribute packages through fdroid, because I believe that fdroid is harmful, and I don't want to endorse harmful activity.

I understand that many of the people commenting here probably understand how insecure fdroid is, but value a full OSS stack more than the security of their device. That's fine, but I think anyone that completely understands the risks is also completely capable of building TextSecure from source themselves. It's the people that don't understand the risks that I'm worried about.

Please do tell me if I understood anything the wrong way. I just started packaging for F-Droid as a hobby, and I'd
like to package your software in the following days. Hopefully there won't be a problem with that.

It's my preference that you don't. I spend a lot of time on this project, and I'm certain that having APKs floating around which are signed by someone else will inevitably cause problems for me in the future.

I realize that everyone here likely has their own projects that they spend their time on, but before jumping straight to the high-level decisions for the direction of this project, I would recommend that people who are interested in this project's direction start by committing a little bit of code here first, in order to get a feeling for this codebase and its challenges.

@mvdan

@moxie0

You're not being asked to participate in F-Droid, nor are you needed to sign or distribute any packages for it.

And, as much as security seems to be quite subjective, I would not say F-Droid is insecure. Like @dalb8 stated, no keys are online, and the default downloads are through SSL. I see no big insecurity here. Even if there was, that's the risk the user is willing to take once he installs F-Droid and accepts the terms of service. Much like with CM - we are not bringing malware to the masses.

I see it is your preference that we don't package it. But I don't understand the reason. We can always add something like the following to the description:

Please make sure that you're running the latest upstream version before submitting any bug reports.

Would that suffice? It has been said before that you "forbid" us from packaging it, but that's not what I understood. You'd rather not have people install it from non-Google sources, but we can still package it as-is without a problem.

@moxie0
Owner

It's my preference that you don't. I would also reiterate that it might behoove you to commit even a single line of code before you jump straight to signing your own releases. =)

@mvdan

It's my preference that you don't. I would also reiterate that it might behoove you to commit even a single line of code before you jump straight to signing your own releases. =)

Although you might be right, I have never done any serious Java. Still getting started with C++. Perhaps someone else would be of some use to you. But so far all I've been doing is packaging.

@moxie0
Owner

The only secret is to begin. Pick one of the open issues, start working on it, and you'll figure it out as you go.

@tedks

@moxie0 -- As one of the former users of TextSecure via fdroid, and someone who values libre software and security, I'd like to say that I appreciate your points, and feel pretty good about my decision to keep using TextSecure as deployed by the Play store.

However, I'd still prefer to use fdroid for as many apps as I can, and I'd also like to have some sense of security when using it.

As a compromise, do you think you could outline, either on fdroid's bug tracker or here, exactly what would need to be fixed in fdroid before you'd consider allowing TextSecure on it? Then, the people who want TextSecure in fdroid can fix those bugs, or work towards fixing them. Either way, everyone benefits: you get a definitive end to these issues, and fdroid gets more secure.

As an FSF member, free software advocate, fdroid user, etc., I hope that if Moxie does this, it ends this discussion until those bugs are resolved. Moxie is the maintainer of a free software package; he's under no obligation to do even more work than he already has for our benefit; forcing him to repeat himself on bug reports like these is to no one's benefit.

(At least one of the things mentioned in this thread is not necessarily an issue: there are some packages in fdroid that have packages signed by the maintainers, including the Firefox build, I believe.)

@moxie0
Owner

This is the current list of things that we need before we can distribute an APK outside of the Play Store. Any help completing these missing pieces would certainly be appreciated:

  • A built in crash reporting solution with a web interface that allows us to visualize crashes and sort by app version, device type, etc. This is essential for producing stable software.

  • A built in statistics gathering solution with a web interface that allows us to visualize aggregate numbers on device type, android version, and carriers for our users. This has been crucial in shaping support and development direction.

  • A built in auto-update solution. Fully automatic upgrades won't be possible outside of Play Store, but we at least need something that will annoy the hell out of users until they upgrade. This is necessary for ensuring that new security features and bug fixes can be propagated quickly.

  • A build system that allows us to easily turn these features on and off for Play and non-Play builds. Gradle should make this easier.

@michalzxc

"1) Cyanogen runs things as root, completely circumventing the development of a fine grained permissions system. They've also made a number of tradeoffs that further weaken its security."

Sniffing phone communication, like motorola did?
http://www.beneaththewaves.net/Projects/Motorola_Is_Listening.html?source=hn

Or maybe you think about Trojans like Carrier iQ?
http://gizmodo.com/5864220/what-is-carrier-iq

Closed source (official) ROMs doesn't have weak security, there are completely compromised. Full of malware, trojans and backdoors.

2) In order for your friends to run fdroid, they've had to tick "allow 3rd party sources," which is probably the single most effective malware prevention mechanism for less savvy users.

If you have your official OEM ROM, you don't have to install any malware, you have all out of the box

@KaitoKito

I've read the whole conversation and I don't understand something : if someone want textsecure but don't want to use a google account and has better thing to do than learn how to compile an android software, he can either download a very very very old version or take an .apk compiled by someone on internet without knowing if the .apk he's downloading has been compromised or no. Do you really prefer these two insecure option for your users instead of releasing an official binary, compiled by your hands, right here ?

Also I don't understand why the fact of not knowing how to compile a source code make you not enough responsible to untick the "third party app". I know many guys who know how to program and compile codes but they still can't avoid stupid viruses on Internet and next to them some people who can't even read a source code but are enough intelligent to know which app is good and safe for them. Your argument is invalid.

"I spend a lot of time on this project, and I'm certain that having APKs floating around which are signed by someone else will inevitably cause problems for me in the future." If you really think this the most intelligent thing to do is to compile and sign yourself the .apk who will floating on internet. don't give the time to creepy black hats to do it before you.

@moxie0
Owner

@KaitoKito If you look at the number of open issues we have right now, we're substantially behind where we'd like to be in terms of providing support. We're at a place where raising our support load by even 1% would be really overwhelming, and my sense is that an official non-Play APK release without the 4 prerequisites I list above would have that impact.

So I'd love to get a non-Play APK distribution channel going, but we need to do some work in order to make that happen smoothly. If this is something you're interested in seeing, the best thing you can do to help is to take on some of the work listed here: #127 (comment)

@dalb8
@zak333

Hello moxie,

thank you for your discussion about this issue. There are many other developers out there, who close such issues very fast, avoiding the opinions and preferences of other users.

I recognize you think the "security model for desktops (unix-based and windows-based) is completely broken" and "believe that fdroid is harmful, and [you] don't want to endorse harmful activity."

As I understand it, your sense of security lies in the use of Google Play in combination with the deactivation of the ability to install 3rd party applications. The ability to create, sign and upload your app to the Playstore yourself gives you alone the full control of it. Nobody else should be able to provide any other (probably compromised) version of your app.

Although I can understand the positive implications of this, I nevertheless strongly want to disagree with this perspective. First: It's condition is to trust two involved parties.

  1. Google
    I do not know, what Google really does. Its main purpose of existence is the processing of data, our data. It can keep track of our phones, our contacts, our communication, our preferences, what apps we use when and how often and who knows what else. I do not allege Google to use this data against us (yet?) (maybe undeliberately?), but I simply do not want to create any account with Google just to be able to install some few apps I would like to use. And as you can see, there are many other users who think alike.
    I do not know if Google modifies your created package in some way, too. It may be unlikely, but I cannot be absolute sure they don't either. Who programmed the key-verification routines and how do they really work with all those Google Apps?
    In the end, if I would want to install something from Google Play, I will have to give Google my trust.

  2. (Please don't take this personally) You
    I do not believe you have any bad interests when providing us your software. (And I am of course grateful you provide it at all!) But the fact is, the way I see it now, you are the only one involved in creating this package, and I therefore need to trust you alone with it. It could be very easy for you to patch every version just before you compile it and add a few lines. No one would ever know. Maybe in a year or so, someone sends you a generous check, if you would be so nice to add some specific code. Maybe someone hacks your server/workstation and uploads a new version under your name. Again: I don't think this will happen and you are probably trustworthy, but in the end, the trust in you alone is mandatory.

Now, it is of course essential, that security is not possible without the trust to anybody. So second: The problem with your concept is, that we - the users - do not have the choice who we trust. If we want to install the app, we are forced to trust you with packaging and to trust Google with providing it.
(I leave the option to compile the source ourselves, because that is not the issue here. I believe the issue is to provide users an easy and secure concept of installing and using applications.)

If however, other people in an open community become involved in the distribution of applications and this distribution is transparent and replicable, the possibility of compromised software gets lower.

Why is that so?
a) The chances, that several people at once have malevolent intentions is lower. If only one person is involved, he/she can do whatever he/she wants without anybody else noticing.
b) If someone does something wrong (either intentionally or accidentally), there is a good chance that someone else recognizes this.
c) In case of a bigger project like F-Droid (or take Debian for example to mention one of your "faulty desktop security models"), the impact of something bad would fall back on the whole project. It is unlikely that people will risk losing their trust by risking something bad with a few apps/programs.

And finally, I cannot emphasize enough the most important thing I believe security should have: The freedom of choice! If I think Google is untrustworthy, I should have the possibility to get my app elsewhere. If I believe F-Droid sucks, I should be able to get the apk from maybe another distributor or on the webpage of the author. If I believe, even this apk is compromised, I should have the possibility of compiling it myself.
The attitude of someone who pursues the open policy of providing his software to other people using different channels raises in my opinion the credibility of that person and the project.

If people however need to trust one single instance, it gives this instance great power about them. And we all know: With great power comes great responsibility.
Unfortunately there were often times in the past, were great power was misused at some point sooner or later.

And in the end, security remains entirely with the user. If he does not care or understand what it means (or what kind of security he desires), not your and not my concept will completely help him.

By the way:
a) The "demographic that does not know what a checksum or signature is" will probably use Google Play either way.
b) The users who do not want to create a Google account will probably still not create one just to use your app.
c) It is very likely that someone will start a fork or create a new app instead. So your concern about the security of the users of your app may be honorable, but you will not really help them by restricting your software that way.

P.S.: I installed Cyanogenmod on my device and cannot find any GSF. If I am missing it I would be interested in how my device may still phone home to Google.

@moxie0
Owner

@zak333:

I do not know if Google modifies your created package in some way, too. It may be unlikely, but I cannot be absolute sure they don't either. Who programmed the key-verification routines and how do they really work with all those Google Apps?

You can be absolutely sure. PackageManagerService is OSS, so you (or anyone) can audit the code.

(Please don't take this personally) You
I do not believe you have any bad interests when providing us your software. (And I am of course grateful you provide it at all!) But the fact is, the way I see it now, you are the only one involved in creating this package, and I therefore need to trust you alone with it. It could be very easy for you to patch every version just before you compile it and add a few lines. No one would ever know. Maybe in a year or so, someone sends you a generous check, if you would be so nice to add some specific code. Maybe someone hacks your server/workstation and uploads a new version under your name. Again: I don't think this will happen and you are probably trustworthy, but in the end, the trust in you alone is mandatory.

If you don't trust the packager, I think your only option is to build it yourself. Fortunately, we've gone to great lengths to ensure that this can be done by typing a single command: gradle build

If you're concerned about trusting me to package the source, I'm not sure why you would be less concerned about someone random at F-Droid packaging the source. At least my signing keys aren't online!

And finally, I cannot emphasize enough the most important thing I believe security should have: The freedom of choice! If I think Google is untrustworthy, I should have the possibility to get my app elsewhere.

You don't have to convince me. I would love to distribute an APK outside of Play. Above, I've outlined the four missing pieces we need in order to do that. If this is something that you are interested in seeing happen, all it takes is helping us get those done.

@mvdan

If you're concerned about trusting me to package the source, I'm not sure why you would be less concerned about someone random at F-Droid packaging the source. At least my signing keys aren't online!

Just two quick comments:

  • You can be less concerned because the whole build process is public, verbose and reproducible by anyone.
  • Our keys are not online. Where did you get that?
@moxie0
Owner

You can be less concerned because the whole build process is public, verbose and reproducible by anyone.

As it is for me. If that's not good enough somehow, I don't see how someone else building it is any different.

Our keys are not online. Where did you get that?

So every time any one of your packages needs to be updated, someone hand carries the source to an airgapped machine, plugs in the HSM with the key specific to that app, runs the build, and carries the signed APK back over to the networked machine? How do you scale that process across all of the apps you distribute? How do you physically store all of your HSMs?

@mvdan

As it is for me. If that's not good enough somehow, I don't see how someone else building it is any different.

I'm not saying that our method is any better than yours or anyone else's. I'm just saying that argueing that it is less secure doesn't make sense either (edit: as far as I know or have been told)

So every time any one of your packages needs to be updated, someone hand carries the source to an airgapped machine, plugs in the HSM with the key specific to that app, runs the build, and carries the signed APK back over to the networked machine? How do you scale that process across all of the apps you distribute? How do you physically store all of your HSMs?

The process is similar to what you say. There is the web server holding the site and the repo over http and https, and there's a machine without any kind of remote access that holds the keys and runs the builds. All of this is to be done separately for each repo, in fact a single fdroiddata dir can only handle a single repo. Repos should never share their keys with any other repo, at least we won't do that with the main repo.

How do we physically store the sensible data? I don't have access to said machine (only one person does), so I'm guessing it is stored in a secure place in an encrypted file system. But that's only a guess following what I would do.

Just to clarify, the building machine uses ssh to provide the hosting machine with the apks, the icons, the index, etc. This is all public if you check the fdroidserver python source.

@dalb8
@moxie0
Owner

Just to clarify, the building machine uses ssh to provide the hosting machine with the apks, the icons, the index,
etc. This is all public if you check the fdroidserver python source.

If the keys are on a machine that's connected to a network, then the keys are online. Just because only one person is supposed to have access to the machine doesn't mean the keys are offline. =)

It also sounds like you're saying that you're not using HSMs, which means that an attacker could actually copy the keys and use them to sign APKs out of band.

@mvdan

If the keys are on a machine that's connected to a network, then the keys are online. Just because only one person is supposed to have access to the machine doesn't mean the keys are offline. =)

It's connected to the network, yes, but it's not that simple. The builds are done inside a virtualbox machine, and the keys are definitely not there. So I don't see the trouble in using keys that way. They would only be released if the admin did it on purpose.

It also sounds like you're saying that you're not using HSMs, which means that an attacker could actually copy the keys and use them to sign APKs out of band.

I'm curious, how would that be accomplished? No sarcasm intended, really.

@tedks

I'm curious, how would that be accomplished? No sarcasm intended, really.

  1. The hosting machine is compromised.
  2. The attacker compromises the build machine the next time the build machine connects to the hosting machine via SSH.
  3. The now-compromised build machine waits for the keys to be provided for a build, inserts them into a file, and pushes them to the hosting machine via SSH.
  4. The attacker downloads the keys and uses them to sign APKs out of band.

A machine that has network communication with other machines isn't "offline."

How are the keys actually stored? Are they just outside the virtualbox image or something? You could just as easily have step 2.5: the attacker compromises the virtualbox environment and then compromises the VM host.

In contrast, presumably Moxie has a hardware security module (https://en.wikipedia.org/wiki/Hardware_security_module) that stores key material in such a way that it is inaccessible to his operating system.

@dschuermann

Srsly moxie? Do you think your signing key is store more securely than the key of fdroid's main repo?
Besides the fact that I don't like HSMs, are you using one?

You are right with one thing regarding the fdroid client: there should be an auto update function. Okay, we can do that.
To accomplish this FDroids needs to be installed as a system app. This would also allow installation without enabling apks from unknown sources.
I started implementing unattended install for fdroid which will be the basis for auto update functionality: https://gitorious.org/f-droid/fdroidclient/merge_requests/37

@moxie0
Owner

@dalb8 :

Theoretically, it allows for bit-for-bit reproducible builds, which would allow anybody to verify that an apk was built as described, negating the need for HSMs and such.

Sort of. Reproducible builds allow us to verify what's happening in public. However, we have no visibility into what the f-droid administrator or any attackers who get access to that machine do with the keys outside of public view. Signing keys are an important part of the Android security ecosystem, and centralizing them feels like bad security hygiene to me. Particularly if those centralized keys are also kept online.

@mvdan :

It's connected to the network, yes, but it's not that simple. The builds are done inside a virtualbox machine, and the keys are definitely not there. So I don't see the trouble in using keys that way. They would only be released if the admin did it on purpose.

Nobody expects to be hacked. Comodo, VeriSign, and other CAs didn't expect to be hacked, but they were. They at least don't keep their root CA certs online. We have no way to measure the security of f-droid's centralized key database, but online vs offline keys is a good starting point.

@dschuermann :

Srsly moxie? Do you think your signing key is store more securely than the key of fdroid's main repo?

Yes. I don't think this is something that's possible for fdroid to avoid. There is simply no way to keep a centralized keystore that needs to run online automatic build/distribution tasks more secure than an individual developer can, when the latter has the luxury of scheduling their own offline builds.

It's a systemic security problem with the froid model. Distributed signing is one of the real strengths of Android, and I think there's a clear security cost to centralizing it. I'm sure you can make the case that fdroid is useful for many reasons, but in my view increased security isn't one of them.

@dschuermann

@moxie0
Yes, you can't keep a centralized keystore more secure than the keystore of an individual developer.
You did not answer to my other points, so I ask again: Is your keystore more secure than the keystore of fdroid? Are you using a HSM? Are you building on a seperate offline machine?
If that's not the case your security is likely the same as the security of fdroid.

If you weren't a known security researcher, I would even argue that the probability that your machine is somehow compromised is much higher than a compromised fdroid build server.
Most Android devs aren't that much security aware (just look at SSL hostname validation in android apps).

Additionally, I would like to know your opinion on https://gitorious.org/f-droid/fdroidclient/merge_requests/37
What if F-Droid is preinstalled like Google Play and would provide an auto update functionality?

@mvdan

I see @moxie0's point of view here, but I agree with @dschuermann in saying that f-droid is no less secure than the decentralized method that the Google Play uses. Mostly because our method isn't centralized at all. It just appears centralized as noone has taken the time to set up and maintain another repo yet, so only the main repo is used by most people.

But, like the security of one developer's build machine can be compromised when publishing to the Play store, a single repo's build machine can be compromised. That won't compromise any other repos, of course. I'm not saying that this method is perfect, but IMHO it does solve @moxie0's complaints regarding our repo. In other words, an f-droid repo will be more or less secure depending on the build/hosting servers behind it. By default it automates via sshfs, but you may do all of that manually too.

Before saying why, let me remind you that I said "I suppose the keystore is someplace in the hard drive, outside of the virtualbox VM". I don't know where it is kept in our buildserver's setup, it might even be in a separate storage unit. Because the signing takes place independently from the building, so you could very easily build all applications without the keystore, read the keystore manually from someplace like an HSM, and then sign all unsigned packages at once.

Usually, the building takes place inside the VM, and the signing (fdroid publish) and index updating (fdroid update) outside of the VM.

Regarding moxie's need of security: He could provide his users with non-Gplay downloads in different ways:

  • Setting up a binary f-droid repo (you build, you sign, f-droid only updates the index)
  • Setting up a binary f-droid repo with automated signatures (you build, f-droid signs and updates the index)
  • Setting up a source f-droid repo (f-droid builds, signs and updates the index)

Of course, all the f-droid steps can be done separately and triggered at independent times, so you could use a HSM if you wanted to.

Automatic updates aren't done yet, but like @dschuermann said we want to approach that possibility. I'm not sure that forcing updates on the users without opt-in/opt-out would be sensible on our side, but you could always just have the latest version of each app in your repo.

@moxie0
Owner

@dschuermann :

Yes, you can't keep a centralized keystore more secure than the keystore of an individual developer.
You did not answer to my other points, so I ask again: Is your keystore more secure than the keystore of fdroid?
Are you using a HSM? Are you building on a seperate offline machine?
If that's not the case your security is likely the same as the security of fdroid.

I'm glad we can agree on that point. Yes, our packaging process is entirely offline.

Most Android devs aren't that much security aware (just look at SSL hostname validation in android apps).

Even if an individual Android developer has an online signing practice, I believe there is qualitative security value in that being distributed, rather than centralized in a single machine (or organization) that can be compromised.

@mvdan :

Mostly because our method isn't centralized at all. It just appears centralized as noone has taken the time to set up and maintain another repo yet, so only the main repo is used by most people.

There is a substantial difference between a distributed system and multiple centralized systems. So long as an f-droid repo is signing packages with keys that don't originate from the developers of those packages, it isn't going to interoperate with other repos. My view is that the practice of f-droid repos signing packages with their own centralized keys undermines one of the core strengths of the Android security model.

Setting up a binary f-droid repo

This is essentially what I'd like to do, however I'd prefer not to have users install a separate app just so that they can install this app. And I'd be reluctant to recommend users install a separate app that could lead them to installing other packages which are signed with centralized keys.

So ideally we'd just bundle some code in the APK that does three things:

  1. Check for updates and notify the user when they're available.
  2. Provide analytics on Android version.
  3. Provide crash reporting.

If you're interested in seeing TextSecure distributed outside of Google Play, we just need help implementing those three things.

@dschuermann

I really like this discussion :+1: It gives me some other ideas and insights about android security.

I totally see your point about dezentralized signing, however I will not spend time developing another self-updating mechanism. This self-updating needs to be done sufficiently secure and it's not worth the time to implement something which already exists in form of binary F-Droid repos.
Due to security implications when everyone implements self-updating themself, Google banned those apps (http://arstechnica.com/information-technology/2013/04/google-bans-self-updating-android-apps-possibly-including-facebooks/).

I'd like to discuss some things regarding Google Play vs. F-Droid.
Lets assume that your and F-Droid's signing key is not compromised.
Google Play vs. F-Droid are both MitM services providing binaries to users, if you do not provide any side channel for verifcation of apks, like a OpenPGP signed hash (or verify the android way: http://nelenkov.blogspot.de/2013/04/android-code-signing.html), there is no way to tell if these binaries are really build by you.
Google Play could just deliver a different apk for specific users.
The same goes for F-Droid.
Conclusively it comes down to: How much do I trust these MitM services?
I would always choose F-Droid as it is driven by a community, not by a central organization.
What's your opinion about this?

A second similar problem: F-Droid's inclusion policy is very strict. No spyware/adware etc. is allowed and only open source projects are included. Thus, everything I install from F-Droid is free of crap that undermines my privacy.
Google Play is a totally different paving.
I need to do actual research to find out about if given software is indeed the software I was looking for.
There are hunders of rip offs of existing applications, just bundled up again with some spyware in it (e.g. N64 emulators, crazy example: http://www.reddit.com/r/Android/comments/ryzjk/n64_player_ripped_off_mupen64plus_ae_put/ )
Again, I would choose F-Droid.

@dalb8
@moxie0
Owner

@dschuermann :

This self-updating needs to be done sufficiently secure and it's not worth the time to implement something which already exists in form of binary F-Droid repos. Due to security implications when everyone implements self-updating themself, Google banned those apps.

It needs to be secure, but APK signing gets you most of the way there. Google banned self-updating apps because they want to maintain their central point of control (over eg. Facebook), not because of security concerns. We'd have to disable the self-updating channel in our Play Store builds, but now that we've moved to Gradle that should be easy enough to automate at build time.

Google Play could just deliver a different apk for specific users. The same goes for F-Droid.

The big difference is that Google (or attackers who compromise Google) can only do a targeted attack the very first time someone installs an APK. F-Droid (or attackers who compromise f-droid) can do a targeted attack at any time. Put another way, Google is employs a TOFU ("trust on first use") trust model while f-droid employs a CA trust model. TOFU has proven pretty effective in practice, while CAs have had repeated problems.

@dalb8 :

F-Droid is as much a central organization as Google, except it's a non-profit company based in England with a couple of servers in Europe. Sure, people work on it for free, unlike at Google, and that presumably keeps it honest.

The big difference between the two organizations is that f-droid has a centralized signing system and Google has a distributed one. I really don't understand why f-droid went with the former.

@mvdan

Just as a heads up, I hadn't noticed this bit of information on our FAQ:

The building and signing is done in an secure offline (i.e. inaccessible from the internet) environment. Every package is built in a completely fresh isolated virtual machine environment which is discarded once the build is complete. Additionally, that build environment is completely separated from the signing environment.

@moxie0:

The big difference between the two organizations is that f-droid has a centralized signing system and Google has a distributed one. I really don't understand why f-droid went with the former.

What alternative is there, given that most developers don't care whether their apps are in F-Droid or not? (Some even convinced us to remove their apps from the repository after continuous nagging)

@EricJ2190

Building from source is not an acceptable option, even for "power users." As you say, it is important to keep the software up-to-date. If I build from source, I am not notified of updates, and I can't update until I am at my PC. On F-Droid, I am notified about updates automatically and can immediately install them.

I think it is in the best interest of security to provide an alternative to Google Play. Otherwise, users without Play will be forced to obtain TextSecure binaries from another less trustworthy source.

Since this is a GPL project, F-Droid should be able to distribute TextSecure without anyone's permission, and I think that they should do so. However, it sounds to me like the F-Droid people are uncertain about this after @moxie0 told them to remove TextSecure.

Can you clarify that this project is in fact intended to be GPL, and it therefore can legally be redistributed freely by F-Droid?

@moxie0
Owner

Hey @EricJ2190, because of F-Droid's centralized trust model, it is our preference that they don't distribute TextSecure. Anyone is free to do what they wish with the software so long as they abide by the terms of the license, but I hope you will consider spending some time contributing to the project before you make a decision that increases our support overhead.

The good news is that we have a non-Play distribution framework in development that should be available by around January 12th.

@ghost

As someone who doesn't run any of Google's apps on my Android phone, add me to the list of users that want a Google-free APK made available. Simply providing the APK on your site and signing it with your public key would be sufficient.

Even if the developers have an inherent distrust of the web-of-trust model, it's still an improvement over having to run Google's proprietary apps on your phone.

@octosquid

I use Cyanogenmod without any apps from google, including play store. All my apps come from my rom, f-droid, or are self-developed.

In the past, on my computer, I had windows. Every time I downloaded software from the Internet, I had the slight fear that it might include {bloat,spy,mal}ware, just like this very nice java updater with this great ask toolbar.
I switched from windows to linux also because there were huge lists called Application repositories full of software that wasn't written so that I grant root rights to it so that it can spy, but to work and respect my will not its developer's.
As I got a phone, I searched on the Internet for exactly such a filtered list for my phone. And I found such: f-droid.

The play store model where the developer signs the builds fits very well for the closed source blob-commit world.
But for open source, relying on the developer to build the app from the source code he publishes violates the many-eyes-principle I think. Who verifies that the blob matches the source?

Mobile app ecosystem is full of developers not knowing what open source is. They publish something, but it may still contain closed-source blobs. The fact that the build gets made by f-droid people guarantees the app is open source, and matches the source code. For this, it is very good to not to rely on the developer's word that its open source, but the app repo to build the application.

Many developers also want to track their users without their consent. The application may be open source, but it can contain spyware features. AFAICT F-droid considers everything except of opt-in stats as spyware. It is good to have an app repo saying to you whether the app does tracking, displays ads, and so on. One might say, the developer should choose which spyware features to add. I think, the users should have the control over such features, just like all features of the application. The best is if they help the developer by submitting statistics, but they should be abled to choose.

@moxie0 You don't want your apps added to f-droid only because of the centralized signing system, or also because of the optional apk download feature on the app's website, or because you can't track users?

Would it be sufficient for you to allow adding the app to fdroid when f-droid would ship with dual signing both from developer and repo? You do a deterministic build of the app, and the f-droid server verifies that the binary matches the source by re-building.
This is exactly what reproducible builds are about. Apparently you already have it implemented for your app? If yes, then only f-droid needs to be improved so that it matches both your and their needs, both verified blob-source matching and distributed security.
Of course, the client should only accept updates, when the apk is signed by its dev and f-droid, and only accept new apps, when the apk is signed by fdroid, then remembering the dev key.
With that, we have that developer certificate pinning feature android offers, and know also (however centrally verfified), that the source matches the apk blob.
With additional modification, we could also make this last verification decentralized, but when you allow distribution on play store, then you would also allow this minor flaw for f-droid.

You also didn't like the need to tick the "allow 3rd party APKs" checkbox.

I would really like an easy way in CM to add f-droid to my system rom without having to build cyanogenmod by myself, so that I don't have to tick this "allow 3rd party APKs" checkbox. I would also want to remove google's signing keys, so that the playstore can't install applications without the checkbox ticked. It would be really great when cyanogenmod allowed me to set what a "3rd party APK" is and what not.
Because, from my perspective google is 3rd party.

@moxie0 If these changes were applied to CM / F-Droid, would you then recommend CM + F-Droid to people not experienced with technology? And, more important, would you then 'allow' (you can't forbid but you know what I mean) distribution of your apps on f-droid?

Please note, I'm no developer of f-droid, so @f-droid people: Would you implement such changes? It improves security, small downside is the dev becomes limited veto power for app updates.

@rhodey
Collaborator

Lets first accept that what we are comparing here is open source apps on the Play Store vs open source apps on F-Droid. Unless an app is deterministically built we must also accept the following:

1) If it is distributed on Google Play we are trusting the app developer's build process.

2) If it is distributed on F-Droid we are trusting the F-Droid build process.

This is the distributed vs centralized (albeit by awesome, friendly people) bit. Note that until we have deterministic builds we can't even benefit from "many eyes" in either case. Now, hypothetically if all open source apps were built deterministically by app developer and F-Droid alike we would have the following choice:

1) Trust Google Play with an app install on your Android device and download related metadata.

2) Trust F-Droid with an app install on your Android device and download related metadata.

In this case I'd much prefer option two, especially if the F-Droid app was also open source and deterministic. However, I believe the question for now is fundamentally: would you rather have a distributed system of trust and a Google app on your phone, or a centralized system of trust and an F-Droid app on your phone? Note that for now, neither app can be trusted more than it's people, open source or not.

@octosquid

Now, hypothetically if all open source apps were built deterministically by app developer and F-Droid alike

Also note that we don't have an all-or-nothing case. We can roll out deterministic builds gradually for every app. However I admit, when the first app has deterministic builds, its easier for other apps as the compiler is already ready for deterministic builds.

@mar-v-in

@moxie0 You stated above, that Google's system is TOFU, but from my perspective it's not. While you're true, that they can't update apps using a different key (assuming that they did not modify this between AOSP and release - what is not sure either), you seem to totally ignore the fact that they may just backup your data, uninstall and reinstall the app and restore data to install a modified version to your device. Due to their push nature, they could even do this transparently without notifying the user.

I personally also don't like the centralized system of F-Droid, but one should not pray Google to be better in any way

@moxie0
Owner

Maybe people didn't see my comment earlier, but we have started the development process for a solution that provides non-Play distribution. You don't have to continue demanding that we do something for you, it's happening.

@dschuermann

Your last sentence is a little bit rude.
Many of us are working on free software and there are only sparse contributions to these projects.

It's sad to see that you are developing your own updater. You could have just setup a F-Droid server shipping your signed blob, everyone could still use F-Droid while you have your own signature.
If everyone does this, it will lead to broken updaters like existing on Windows. This is the "not invented here" strategy instead of "cooperation" strategy.

@moxie0
Owner

We have been harassed, called names, threatened with a lawsuit, and been the subject of ridiculously inflammatory blog posts. All for something that an (extremely vocal) tiny minority of our users want (%0.05 would be generous), while we are drowning in work to do that is critical to the bulk of our users.

But now that we're doing it, even when we really should have prioritized critical work on other things, the response we get for our efforts is typical of this thread: you're doing it wrong. Before you've even seen anything about it or know anything about what it will be!

So yes, I apologize, but I've started to lose my patience.

@dschuermann

I am truly sorry that you were been harassed and threatened with a lawsuit, haven't read this.
Thanks for your work on security protocols and open sourced Android apps.

You are saying F-Droid is doing it wrong. I understand your criticism and am actively trying to solve some points by cooperating with F-Droid (unattended installation without "unknown sources": https://gitorious.org/f-droid/fdroidclient/merge_requests/37).
I am saying that you are doing it wrong because you seem to implement your own updater instead of working with F-Droid. My criticism is not targeted against the technical foundations of the updater; I don't know how this updater will be implemented.
You say that F-Droid's model is fundamentally flawed (centralized signing), so I think we have to deal with your decision, though we have other opinions. So sry for taking your time, I appreciate that you answered most questions in this thread.

@EricJ2190

Thank you for working on this. I am glad to see that this is coming soon, and I apologize if I came off as "demanding."

@mitar

Thanks for working on it!

@devurandom

Any progress?

@monreal

While I personally use the app from google play I know a few potential users who do not even have a google account. Providing a way to install the app for those people would be great.

@moxie0
Owner

Here's the update:

First, I wrote most of the client and server side for updates and crash reports. So that's almost ready to go. However, now that TextSecure also relies heavily on GCM, distributing it outside of Play doesn't really make sense, given that it won't function without Play Services Framework.

We have websocket support server-side, so we'd need to add that into TextSecure as a fallback option for users without Play. At that point, we can distribute it outside of Play. It won't really work well for all the reasons push messages exist, but that's the best we can do.

If anyone wants to take that on, pull requests are welcome.

@mvdan

Yup, I agree that using textsecure without Google is useless at the moment.

@Argafal

"However, now that TextSecure also relies heavily on GCM, distributing it outside of Play doesn't really make sense, given that it won't function without Play Services Framework."
Do you need a Google account to use the GCM framework?

@ghost

I was under the impression that it was possible to run TextSecure without Google's services. Has that changed? If so, unfortunately, an alternate distribution mechanism won't work for me or anyone else who runs a pure Android phone. Personally, installing Android without Google integration is step one in obtaining more privacy and security on my phone, and it seems like a step backwards to integrate privacy software with Google's services.

@moxie0
Owner

@Argafal You don't need an account, but you need to have Play installed.

@moxie0
Owner

@DKoestler TextSecure uses GCM for push messages. We'd be glad to support an alternate push message network, but there aren't any. Building, deploying, and maintaining a worldwide push messaging network that scales to hundreds of millions of users for free is a lot of work!

We can include websocket support in our Android client as an alternative (any volunteers?), but it won't work well.

@hillbicks

@moxie0 First of all, thanks for your work and patience on this. I really appreciate this, but I'm curious about something and I'd like to get your input and assessment.

I'm trying to give away as little information as I possible can, by either using encryption and/or hosting the server part myself. Another approach to getting control over my data back, was to install the custom ROM again without the gapps package.

Now, I read your concerns about statistics, security when distributing outside the playstore and fdroid itself, but that isn't my concern or question.

What do YOU think of gapps/google? Since you clearly know more about security than probably all of us in this thread combined, what is your take on google? What is your motivation for programming an app whose main purpose is privacy but relies on google for getting it done. For me, this is a contradiction and don't get me wrong, I don't want to be rude, I want to understand your point of view. Is google not a concern for you? Again, I'm trying to understand if my reasoning for not installing any gapps actutally makes sense (I haven't seen any requests to google in my firewall logs since then) or is just something that doesn't really make much of difference.

Thanks for taking the time and explaining all of this :)

PS: What do you think of the nogapps project?

@moxie0
Owner

@hillbicks I would like to distribute software that doesn't depend on Play, but there's currently no way to use push messages without Play. Now that we've written a distribution and update mechanism, that's the remaining obstacle.

@mitar

But TextSecure still works without GCM if one does not use push messages and only SMS as a transport, no?

@countrygeek

@mitar Yes, I use TextSecure without any piece of Google on my phone and it works fine.
One easy way of doing this is via this excellent project: http://apps.evozi.com/apk-downloader/

@SchwarzwaldFalke

@moxie0
Just out of curiosity:
I thought about using a self hosted push service e.g DEACON for me and some friends.
What would be the best way to connect this service to the current infrastructure?

e.g. add functionality to the textsecure client and server so they support additional push services and then let the client decide which service (self hosted or gcm) he prefers? I saw the server already supports APN, so maybe it's not that difficult to add more services.

Thanks for your great work, hopefully it's some day useable without gapps!

@Wikinaut

And it would be nice to see a short page with

instructions how to build TextSecure clients from the source

On my page https://github.com/Wikinaut/utils/wiki I have some examples for compiling

  • Enigmail
  • Mailvelope ; and
  • GnuPG

from the sources. Every project should have such a page.

@Wikinaut

@mitar Thx, but "Ich brauche mehr Details." I need more details.... Can you (please) improve this ?

@mitar

Maybe, but this issue is definitely not about that.

@KaitoKito

Hi again. I just wanted to give my own point of view, no matter what you think.

When I discovered textSecure it was on Fdroid. An amazing way to secure my SMS with my friends. After that I didn't see any updates. When I finally came here and ask why the answer I got was that Fdroid whas less trustable than Google Play.

Google is well known for leaving a giant door on their servers to the NSA, CIA and others acronym who had no other purpose that spying everyone.

Fdroid is a nonprofit organisation who had the rule of giving access to the source code of all available apps.

And still the devlopers of textSecure trust more Google.

So I said let the time pass, maybe they will see they were fool.

Time passed and now textSecure needs a server AND google Play libs. You not only you force 100% of your users who don't know/want to compile your app to go on google play to download it, you also force them to install google play, a source closed app, on their phone. It's like a locksmith install a fingerprint system on your door but don't give you the possibility of knowing who is registered in.

Every good security expert knows that only 100% open source code can be trusted. Your software use a closed source code therefore it's shit. And I'm not talking about the shitty server idea.

I was hoping you'll release your app on Fdroid. Now I only hope that someoneelse will take your sourcecode, remove the play libs and server shit, and release it on Fdroid. I'm hoping someoneelse will do your job !

You are maybe a great developer but either you work for google/NSA or you are the stupidest person ever.

@Wikinaut

@mitar @countrygeek "Yes, I use TextSecure without any piece of Google on my phone and it works fine. One easy way of doing this is via this excellent project: http://apps.evozi.com/apk-downloader/ "

and we could post he current MD5, and SHA1, hashes here, somewhere.

@forteller

Would Aptoide be a suitable alternative for Play? It is Free Software, scans software with three different anti virus systems, nags users about updates, and gives publishers statistics: http://www.aptoide.com/page/publishers

@geileszeuch

There is no need to look out for an alternative store, because @moxie0 already is almost done creating his own solution for providing his software outside of the Play Store. Please read the thread if somebody missed that. The only thing left now is a fallback method for users without Play. This method can for example be built into the android client using websocket technique which the server already supports. Although @moxie0 believes that this won't work well, I am still optimistic. It clearly won't be 100% equal to push, but I could live with little delayed notifications ( hopefully less than 5 minutes). So if somebody is going to make this real, we will have a Google free Textsecure app for everyone who wants it that way. And @moxie0 is also going to provide it outside of the Play Store.

So if somebody out there is experienced with websockets and Android than please don't hesitate implement this in Textsecure. I and a bunch of other people will be more than thankful and donations surely won't stay away, neither to Whisper systems nor to the contributor.

There is a project called autobahn, which implements a websocket client in android I believe. Maybe this can be helpful.

@moxie0
Owner

@v-0-d We already have websocket support on the server and that suits us better for desktop clients. I don't think it'd be any less or more work on the Android side, someone just needs to make it happen.

@v-0-d

@moxie0 How does websockets stand compared to GCM in terms of delay and battery usage?

good read about websockets and energy efficiency on mobile phones:
http://nordsecmob.aalto.fi/en/publications/theses2013/thesis_estep/

@moxie0
Owner

@v-0-d Substantially worse than GCM. It won't work well, but it's the only option short of building a worldwide push network.

@geileszeuch

@moxie0 What library suits best for this purpose? Do you have a good suggestion? What about this one: https://github.com/TooTallNate/Java-WebSocket

Is this guide here good enough?
http://www.elabs.se/blog/66-using-websockets-in-native-ios-and-android-apps

I probably won't be able to do this. I am just trying to help by taking away trivial obstacles. This definitely should be done by someone experienced.

@JavaJens

Out of curiosity: wouldn't a WebSocket implementation create some form of worldwide push network?

@Gnarfoz

On the contrary, it sounds like it would be a centralized model, using WebSockets to talk to the(ir?) server(s).

@generalmanager

@Gnarfoz it's a federated server model, which means that (in theory) everybody can run his/her own server, as with XMPP/Jabber. Currently there are only two servers: WhisperSystem's and CyanogenMod's. If you want to start your own: grab the server source, get an SMS gateway (for the verification) and ask WhisperSystems to add your machine to the server network, as this is not yet automated.

@Gnarfoz

I see. Then the answer to @JavaJens 's question is "no, but you could look into adding a server of your own to the network". :+1:

@JavaJens

@Gnarfoz The WebSockets part is desired to have an alternate PUSH mechanism besides GCM or APN, the federation is using plain-old HTTP between the servers' APIs as far as I see.

My question was more like the following: If you use WebSockets to push to the devices, that means for each device you have an open connection and this seems to me to be no different than GCM except it is worse for battery, data and costs for the server, but the idea is the same.
I wanted to know if using WebSockets over any other TCP connection presents a benefit.

@kmindi kmindi referenced this issue
Open

Introduce Threat model #782

0 of 4 tasks complete
@Hugoz12

The reason for me to have something like this is that my Play Store tells me that Textsecure is not compatible with my tablet (Android 4.1.1). (Same with WhatsApp but not Telegram for whatever reason). I try to compile it myself later or can I trust http://apps.evozi.com/apk-downloader/ and save myself some work?

@ncruces

@JavaJens the benefit is the possibility of future JavaScript, desktop clients.

@Hugoz12 to register on the TextSecure network your device needs to be able to receive SMS messages. If your tablet has a 3G connection with a phone number capable of receiving texts, you might be able to use TextSecure. Otherwise, you won't, for now.

@scruloose

First off, I'd like to say thank you to Moxie and the Whisper Systems team both for all the work going into TextSecure and RedPhone, and also for this discussion. It's obvious that you are taking users' concerns seriously, even when you don't agree with their perspective. Moxie, I'm truly sorry to hear that the response to this issue has escalated to harassment and threats. While I have grave doubts that trusting Google, the hardware manufacturer, AND my cellular carrier (all of whom have financial interest in undermining my privacy) with root on my device is more secure than running a rooted pure-F/OSS ROM that allows me the option to grant superuser to apps, I certainly respect your view that the PC security model is completely broken and no example to aspire to.

This thread seems to have become the catch-all for discussion about alternate distribution channels as well as GCM dependency... my apologies if it's not the right place for my suggestion.

Moxie, I see from upthread comments that an outside-of-Play-Store distribution channel is well underway using Gradle, and that using websockets as a fallback for data-channel messaging (for those who want to avoid having the privacy-invading Play Services installed) is ... underway and looking for contributions. Sadly, I'm no programmer, so I can't offer any code toward that. Also, while I do understand that the non-GCM fallback will be slower and more battery-intensive, I think it's really valuable to give users that option, so thanks for that. I do wonder about one thing, though: given that the primary draw of TextSecure for many people is the simple ability to encrypt your SMS/MMS messages, the strong emphasis on data-channel messaging seems like it might be a form of "mission creep". I wonder whether a low-effort way to satisfy those who want to avoid the Play Store, Play Services, and GCM altogether might be to split off an SMS/MMS-only version of the app, which could be done through Gradle, as you mentioned. Then, if and when the websockets fallback is implemented, you might (or might not) want to phase out that SMS/MMS-only app. I do realize that you think using SMS is the greater evil, due to the carrier having access to the metadata, but don't you think that's a choice the user should have the right to make for herself?

Also, I have a couple of privacy-related questions that I couldn't find any answer to:

  • When using the current GCM data-channel messaging, I assume that the server has access to the metadata... ie who I message and when. Is this correct?
  • When using the current GCM data-channel messaging, who controls the server? Are they Google hosted servers, or does Whisper run their own servers? Are they federated, and if so can other servers in the network see the metadata? In short, how do I know who does and doesn't have access to my metadata?

These questions have thus far prevented any of my friends who are privacy-conscious enough to install an encrypted-messaging app in the first place from signing up for the data-channel messaging service. It might be good to have some info about that on-screen when prompting users to sign up.

@SecUpwN

Just for my own clarification: Has anyone tried to install Google Play and restricting it with Xprivacy so that it cannot do anything except enabling TextSecure push messaging? Another question to this: Would I have to be signed in when using the Play Store (I'm not even registered there and refuse to do so)..

@generalmanager

@SecUpwN

Has anyone tried to install Google Play and restricting it with Xprivacy so that it cannot do anything except enabling TextSecure push messaging?

I haven't tried to restrict GCM with Xprivacy yet.

Another question to this: Would I have to be signed in when using the Play Store (I'm not even registered there and refuse to do so)..

With the newer Android versions you don't need to be registered, you just need to have it installed.

@bungabunga

@SecUpwN

never tried with TextSecure but i had general issues with Xprivacy. it sucked up my battery when restricting system and google stuff. also, if you restrict Google framework accsess to the internet, then push messages won't work and if you don't, then you did nothing. ;)

@SecUpwN

@bungabunga, main question is: Do I have to be registered with Google Play?

@bungabunga

no. as generalmanager said.

@SecUpwN

@generalmanager, I just reflashed my AOKP-ROM which features KitKat 4.4 to test if TextSecure enables push messages when Google Play is installed - it doesn't. I did not restrict anything. What's wrong there?

@generalmanager

@SecUpwN That's strange. There are some tickets if you search for kitkat, but they don't seem to match your description.
Could you open a new ticket and describe exactly what you expect, what you did and what TS does?
I'm on 4.4 as well, without any problems. Afaik you should only use one of these packages if you are on kitkat.
If you modified the zip, you may have removed a necessary component. If you use other Gapps, it's probably not going to work at all.

@SecUpwN

Ah, wait a minute. All I did was to install Google Play, not the whole GApps package. I will not, not even for testing purposes, cripple my ROM with Spyware by Google. Now I know the reason why TextSecure still complains when it is installed. But if TextSecure really shall be an alternative to other instant messengers, it should work without GApps or any Google stuff involved. I still love TextSecure for what it is and also completely removed my WhatsApp-Account, but once TextSecure is able to connect to people like in WhatsApp, you bet I'll use it as instant messenger. I'll be honest with you: I have high hopes that TextSecure shall find a replacement for GCM soon. Recommending it to my friends will be easier then, too.

@generalmanager

@SecUpwN

I have high hopes that TextSecure shall find a replacement for GCM soon.

If you read this whole thread, you'll find out that they have a non-play distribution channel lined up and will use websockets as an alternative transport. The server already supports it, but somebody has to implement it for the client.

@SecUpwN

@generalmanager, simply awesome. I'll keep waiting until @moxie0 has completed it. ;-)
Rest assured that BitHub of WhisperSystems will definitely receive my donation then!

@eighthave

@mvdan just let me know about this thread, so I thought I'd throw my belated two bits in.

@moxie0 I'll be interested to see what you come up with for the updater. One concern is that you said you require any distribution system to track its users (stats, etc). Those stats will never be offline, so they are a vulnerable target for attack. In many places, users of TextSecure will be a very interesting target to some highly skilled hackers. There are so many stories about giant data leaks and thefts I don't feel the need reference them. Storing stats also leaves you vulnerable to subpoenas, NSLs, secret court orders, etc.

Another concern is that you plan on making separate APKs for Play and outside Play. They should be clearly marked as distinct to avoid confusion (like separate version codes), and should be upgradeable either way (Play to non-Play, or vice versa). Putting your Google Play APKs in your own FDroid repo already allows for this.

And some points related to various parts of the thread:

@dalb8
@SafwatHalaby

@moxie0:
For the safety of your users, you should distribute an official APK or publish it on F-droid.

You should consider the fact that the current situation is actually either driving those who don't have Playstore away from TextSecure to other less secure apps, hence compromising their privacy, or forcing them to resort to dangerous alternatives such as using one of dozens of unofficial APK websites.

Your intentions are good, but by not providing a Playstore alternative, the result is less security for the minority which you are trying to protect.

Look at it that way, you have only two choices:
1. The current situation, in which desperate users get the App from, say... http://www.appsapk.com/textsecure-private-sms-mms/
Or use a different app altogether.

2 . A situation where you have an official APK / F-droid App.

In both situations, things aren't optimal in regards to software updates, crash reports, and statistics. But situation 2 is a lot more secure.

By sticking to situation 1 you aren't resolving any of the issues related to a non Play Store distribution of the app, but you are adding extra non security on top of it.

In other words, people will always download Textsecure from places other than Playstore regardless of your actions, but you have the choice of channeling those downloads towards a single, official, safer source.

Also, 99% will use Playstore anyways, so this should not have a big impact on statistics, Google Play download counts, crash reports, etc...

@rdsqc22

Actually, I disagree.

6 hours ago, I thought as you did- I have been setting up my phone without any Gapps, and when the time came to install Textsecure, it was nowhere to be found. I was frustrated at the least, and went to their website to complain. I found the many existing posts and threads on teh issue, and read them.

And, moxie0's reasoning made sense to me. Furthermore, despite having never built an android APK before in my life, I cloned the git repository and went from start to having a working, signed app in about 20 minutes. It was a great learning experience for me, and frankly, if you're the sort of person who's trying to have an Android phone without Gapps, you're probably computer competent enough to figure out how to spend a quarter hour building the APK, especially considering the quite thorough documentation. Not to mention, again, if you're building a phone without Gapps, then you're probably somewhat security-conscious and building your own apps from source is something you should know how to do anyway.

It would be nice if the source had some sort of in-app notification of when the main branch is updated, so that I don't have to necessarily subscribe to the git through email. But I don't begrudge the choice to not distribute the apk.

@SafwatHalaby

@rdsqc22, My post was based on the (true) assumption that most people are too lazy to build from source, even if they're enough security aware to use Cyanogenmod + F-droid.

I never built an APK in my life too, and I think I will try this, I have no other option.

This is slightly off-topic, but I'm wondering: How would push notifications work if I build from source and I have no Playstore?

Edit: One proof of the claim in my first paragraph is the fact that many people ARE using F-droid instead of building from source.

@rdsqc22

I suspect that if you go that route, you (like me) will be surprised at how easy it is. Let me know if you need a hand.

Push notifications? I have a pebble and pushing notifications to the pebble works fine- is that what you mean? Or are you referring to something else, like Pushbullet?

@SafwatHalaby

Perhaps we could provide an automated build script as an alternative?
Which basically downloads Android SDK Bundle, clones the repository, etc...

And then executes everything in https://github.com/WhisperSystems/TextSecure/blob/master/BUILDING.md

Edit: I know it's a "lazy path", but people are like that.

@SafwatHalaby

Regarding Push notifications, I assumed that Textsecure relies on Google's Push service. Is that incorrect?

@rdsqc22

Not a bad idea, considering that a) it doesn't require root, and b) should only be ~10 commands long.

Heck, I could write it myself, except I'm not sure how to install Android Support Repository and the correct version of Build-tools from command line.

As far as push notifications go, I misunderstood you at first- you are correct, Push does not currently work without Gapps. I believe that once Websocket support is complete, this will be fixed.

@mvdan

For what is worth, what you are doing of building your own self-signed APKs from source is precisely what F-Droid could automate for you.

@SafwatHalaby

That's completely true, but it's a viable alternative as long as F-droid and Textsecure will not cooperate. I still believe F-droid is the way to go.

@SafwatHalaby

@rdsqc22: My build was successful, but I have no idea where the resulting APK is. Any clue?
My assumption is that an APK should be the result, is that correct?

@rdsqc22

I believe that the reasoning here is that since Fdroid forces you to allow unknown app installations, that itself is a larger security risk than Gapps, in the hands of someone who does not know what they are doing. By forcing one to build their own app, this selects for the people who know what they are doing to be the ones to open that hole.

I believe I read somewhere that they would happily put it on Fdroid if it did not require unknown apps to be allowed.

@wiseoldman95 Your APK will be in ./TextSecure/build/apk/
You will have to self-sign TextSecure-release-unsigned.apk to install it.

@mvdan

@wiseoldman95: If you think of F-Droid as the main repository, sure. But I meant it as the software, with which you can set up a repo on your own. Even without a repo, you can use 'fdroid build' and 'fdroid install' to automate it.

@rdsqc22: True that "unknown sources" is required now, but a fix for that is currently in the works.

@kaimi

I cloned the git repository and went from start to having a working, signed app in about 20 minutes. It was a great learning experience for me, and frankly, if you're the sort of person who's trying to have an Android phone without Gapps, you're probably computer competent enough to figure out how to spend a quarter hour building the APK, especially considering the quite thorough documentation.

My main problem with that approach is having to rebuild the app with every release, aka updating hassle.

I believe that the reasoning here is that since Fdroid forces you to allow unknown app installations

You have to allow that in order to install self-built APKs as well.

@SafwatHalaby

True, I don't see the logic in abstaining from F-droid. It's leading to 3 possibilities, 2 of which are less secure, and the last one is less convenient:

  1. Using another app.
  2. Getting it from an unofficial source (And highly likely getting a malware) Lots of these can be found: https://www.google.com/#q=textsecure+apk
  3. Building from source.
@jensschulz
@Strubbl

+1

@SafwatHalaby

@jensschulz: Some people do not trust Google Play though.

@dalb8

@wiseoldman95 I haven't used Blank Store but at least with Raccoon or the APK Downloader app there is simple way of downloading an APK from Google Play without giving the Play Store strong permissions to install whatever it wants on the device. These apps work well as long as you use an Android ID corresponding to similar capabilities to those of the device you currently use.

At least Google leave the signatures alone, unlike Amazon.

@SecUpwN

Since no Open Source download alternative to the shitty PlayStore exists, I strongly recommend everyone to use the awesome APK Downloader - just paste the Package name or Google Play URL and directly download the latest APK to your device. Sad to see that TextSecure, an Open Source App, has not (yet) made it into a much more Open Source friendly store like Fdroid. Still hoping for this to come.

@SafwatHalaby

Are the APK's distributed by Google digitally signed by the developers?

@SecUpwN

@wiseoldman95, yes, as to my knowledge they must be.

@cjeanneret

Heya! just a small remark: why don't you create an f-droid compatible repository we can add to f-droid client app? This would:

  • allow you to still sign the apk with your key
  • allow people to get updates automagically
  • allow people who don't use gapps at all to have a convenient way to get OWS apks, without all the toolchain/build process

my 2cents.

@rdsqc22

@cjeanneret The reason for this is Fdroid forces you to allow apps from other sources, which opens up a huge number of possible security problems.

@cjeanneret

@rdsqc22 true, still offering this possibility would be nice, and keeps the app signature.

anyway, going to build some APK, as there are some updates for TS, Flock and others ;).

@eighthave

@rdsqc22 that is no longer true. You can install FDroid as a system app, or let it use root, and it no longer requires "Unknown Sources" to be allowed. This is true starting with FDroid 0.69-test, and will be included in the upcoming 0.71 stable release (any day now).

@patcon

That's awesome @eighthave! Thanks! didn't realize.

@patcon patcon referenced this issue from a commit in patcon/mission-impossible-update.zip
@patcon patcon Install F-Droid as system app for more security.
No need for allowing apps from "Unknown Sources" under security.
See: WhisperSystems/TextSecure#127 (comment)
13b7c82
@countrygeek

Would anyone mind posting the latest version of TextSecure? I'm currently running cynanogen without gapps and didn't feel like installing them to upgrade. Thanks!

@Wikinaut

@countrygeek Do you have a Linux box? Then you could build it by yourself (it's not too complicated). Pls. contact me by mail if you need help (your github account has no e-mail address connected for direct feedback).

@agrajaghh

@countrygeek Without gapps you can't use push messages, you'll be only able to send encrypted and unencrypted SMS

@Wikinaut

@agrajaghh @countrygeek You can use TextSecure without having an Google Play account. For some reasons, I can use my self-built version on all my phones and tablets without any problem.

My devices however have Google Play Store installed, but as said, without an associated account ‒ the devices are not running CyanogenMod.

@agrajaghh

I think you don't need an google play account, but you need the google play services to be installed for push messages...

@Wikinaut

@agrajaghh wrote

I think you don't need an google play account, but you need the google play services to be installed for push messages...

@countrygeek : yes

@generalmanager
@patcon

Thanks for the pointer on that thread @generalmanager :)

@countrygeek While it's not particularly helpful here, I find this helpful for getting apk's for essentials not yet on F-Droid. (You can install with adb install /path/to/app.apk if you have USB debugging set up.)

http://apps.evozi.com/apk-downloader/

@countrygeek

@patcon : Thanks, I actually had tried using that but the site was down - appears up again now. It's definately the easiest way, vs. trying to get the ADT bundle up and running just to run TextSecure without Gapps. I have an unlimited data plan so I don't care about SMS charges. :)

@Zeriuno
@Wikinaut

@Zeriuno this could be done by @Moxie on the release page https://github.com/WhisperSystems/TextSecure/releases see this → example https://github.com/schildbach/bitcoin-wallet/releases

Moxie could simply additionally publish ‒ parallel to the publication in Google Play Store ‒ the release apks and their corresponding signature files in the TextSecure https://github.com/WhisperSystems/TextSecure/releases page. Currently, there is only the source code. But there's no room for discussion, because AFAIK, he wants a secure channel for automatic updates, and only Google Play Store can do.

@Wikinaut

@Zeriuno I published checksums for versions < 2.0.8 on my TextSecure Wiki page https://github.com/Wikinaut/TextSecure/wiki/History-of-changes

This not-so-well-known gpg command/option lists all avaliable message digests:
gpg --print-md "*" org.thoughtcrime.securesms.apk

@CHEF-KOCH

I also vote for an F-Droid repo and a alternative direct link which provide sha1 and gpg. To publish it on the github release page would be also an interesting idea, we generally should as less as possible from google.

@cyl-us

Where there is no transparency, there cannot be any hope of either security *or* privacy. Seeing a privacy application depend on nonfree software to function is therefor a very sad thing to me, as its dependences undermine its purpose. A system is only as secure/private as its least secure/private component, so anything that has Google Play Services installed is already compromised.

You also mention that a user has to enable third-party application installation to install outside the Google Play Store. While I'm not sure it will sway you, it's worth noting that for us Replicant users, we have to have that box unchecked to install anything outside of *F-Droid's* repository, meaning that by not offering it on F-Droid, you *require* us to enable third-party application installation.

@SecUpwN

@jtrig, maybe it's time to move on to more open alternatives like Tinfoil-SMS?

@rdsqc22

@SecUpwN No, because that's also not on Fdroid. Google Play only, so it's no better.

@SecUpwN

@rdsqc22, the developer of that App is extremely open to open source. Feel free to open up an Issue on his GitHub for that, I am sure this App will be available there sooner than you think.

@rdsqc22

@SecUpwN It looks like it used to be on Fdroid, but then got removed because the developer started using non-free binary blobs. https://f-droid.org/wiki/page/com.tinfoil.sms

@WhiteHatTux WhiteHatTux referenced this issue in WhisperSystems/RedPhone
Closed

No incoming calls without Google Play Services #296

@justjanne

Source, what is still limiting progress with this issue?

  • F-Droid allows nonfree apps, but will display a bold warning against them I seem to be mistaken here, but this still holds: (And TextSecure is implementing sockets instead of GCM anyway),
  • F-Droid now allows to distribute a developer-signed version of the app, if the build is reproducable by their build server,
  • F-Droid now allows installation of apps without enabling third-party support

In other words, every single of @moxie0’s complaints has been fixed, so why is this still not happening?

@fwalch

In other words, every single of @moxie0’s complaints has been fixed, so why is this still not happening?

Maybe just because no-one told him yet ;-)

I guess distributing TextSecure on F-Droid while Google Play Services are still required for it to run doesn't make too much sense. You could check out #1000 resp. the fork at https://github.com/JavaJens/TextSecure to help with that.

@brumsoel

F-Droid now allows to distribute a developer-signed version of the app, if the build is reproducable by their build server

Interesting. Could you point me to some information / docs on how this is supposed to work?

In other words, every single of moxie0’s complaints has been fixed

I don't think there is a solution for automated crash reporting without Google Play yet.

@fwalch

@brumsoel See https://f-droid.org/wiki/page/Deterministic,_Reproducible_Builds. For background on reproducible builds in general, see e.g. this talk at the 31C3 (slides on this page).

@eighthave

The reproducible build stuff is quite new and still a bit raw, but it does work. I'm happy to help get TextSecure integrated using this process for anyone who wants to take it on.

As for automated crash reporting without Google Play, you can use ACRA then choose which backend you want it to upload to.

@moxie0 moxie0 locked and limited conversation to collaborators
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Something went wrong with that request. Please try again.