Security Notice – TextSecure

1) I say “secure” because one of the claims of your software is that “all text messages, regardless of destination, that are sent or received with TextSecure are stored in an encrypted database on your phone.” – this isn’t the case if they’re written in plain text to the log file.

2) 0.6.2 is totally relevant – the reason your application was removed is because there were security issues, and the source code for the latest version was unavailable. (I’ll assume by mistake, because you’ve now updated it, but we have no way of knowing that in advance). We can’t provide applications that have issues of this nature if source code is going to be unavailable.

3) I quoted the timeline from my perspective, but if that was inaccurate, the point stands bug was discovered at least 18 days before that and you didn’t mention it, despite knowing that we had large numbers of users who might be still running that version and needed updates. Instead you requested that we cut off their update channel. The only reason we complied with that request was the obvious prospect of not being able to update them to the current version, 0.6.2, let alone any future versions. There’s no freaking out involved.

1) Ok, so it was accurate but somebody (unspecified) misinterpreted it? I have completely replaced the brief paragraph with a much more detailed one, which is hopefully safe from that. I believe it’s still accurate, but if you have any objections I’m sure you’ll let me know.

2) and 3) You’re missing the point completely – this post is not about you or aimed at you. It’s not about *you* had a security flaw, it’s about *we’re* sorry, we can’t provide this software any more and you need to uninstall it – an unprecedented situation that deserved an explanation. At the risk of repeating myself: our users are running this software, and expect to get updated. (Not always as quickly as we’d like, admittedly – this is a small volunteer project, and people are aware of that). We can’t update them to the current version because there’s no source, we can’t ask the developer to correct that situation, because he’s decided to go back on his license, and declare that nobody can distribute the application except him, and we certainly can’t count on being able to provide any future versions of the software. Given the security-sensitive nature of the software, the only option is to remove it. This means that anyone who hasn’t updated to 0.6.1 yet doesn’t get the update, or even know that one exists. The point of the post is to communicate that situation to those users.

This has gone on far too long already, but I feel I need to add a couple more points that may or may not help you see the situation from a different perspective:

When you say “developers have no visibility into their projects on f-droid” you talk like that’s a bug. It’s a feature. By “visibility into their projects” you mean visibility into people’s devices. While that’s the situation in the Google Play world that you expect ALL users of your software to participate in, it’s not acceptable to people who use F-Droid, and it’s one of the key reasons they use it. In our opinion a developer has no right to know who has installed their software, and certainly Google has no right to know and track exactly who has installed exactly what software. I’m very surprised you don’t appreciate this.

Finally, you keep talking about “unverified builds”. The idea of a verified build is extremely important to F-Droid users – the verification being that the complete corresponding source code for the binary is available, and the build can be reproduced by *anyone* who so chooses. You haven’t said what your definition of verified build is, but it’s obviously a different one because nobody could have possibly built the 0.6.2 that you released to Google Play – the source code wasn’t published. Although you can say it was just a small AndroidManifest file change, you must also be able to see that only you knew that.

@Jacob: Thanks for the thoughtful comments on this.

So yes, we can easily bulld the code from github and push that apk out – this is what we were doing in the first place. There are issues with doing that though, which I’ll reiterate; Firstly, the author says the code is GPL licensed, but the author also says “nobody can build and distribute this code except me” – which takes priority legally?

Secondly, at the time the decision was taken to remove the app, the source code for the latest version wasn’t available from github or anywhere else. Although we already had a version with the bug in question fixed, we had no idea if there were even worse issues remaining in the version we had. At the same time, the author of the software deflects a user’s report of his bug by blaming it on F-Droid, labelling it malware, and stating that no build of the software except his is secure. Under those circumstances, would you take the code and build it anyway?

Regarding security, the F-Droid client uses SSL by default, but it doesn’t rely on that at all. The repo index itself is signed, by a specific key that the client has – not relying on a CA or any outside influence. Even if an individual apk download was subject to a MITM attack, or server compromise, the client would refuse to install it because it wouldn’t match what was in the index.

Side issue, but relevant: although Moxie has taken it upon himself to spread misinformation elsewhere that this key, and the keys used to sign the apks, “are being stored online”, that’s not the case at all and never has been. Although I’m sure Moxie could highlight some genuine security concerns if he chose to, this fictional one is the only one he’s expressed, to my knowledge.

Regarding the packages being available for manual download from the site via http or https, that’s a matter of user choice. Manual downloading is never going to be secure via either protocol, but if people want to do it they can. There’s a warning given above the links, and the apk download links are all https links – you would have to manually modify the url yourself to get the http download. For the client, again, both options are offered but the http one seems to be ‘the default’, and as you say, the QR code goes to http. I’ll get these fixed.

Don’t think for a minute I’m saying F-Droid is totally secure – it’s very much “USE THIS AT YOUR OWN RISK!” as stated in various places around this site. It’s a small volunteer project and should be treated as such. However, the best effort possible is made to secure things. Ultimately any delivery mechanism is flawed. Although you seem to have great confidence in Google Play, you can download malware from there any day of the week. I can create an account tomorrow and upload some in binary form. I don’t see it as any more secure than F-Droid, and in some ways it’s certainly less secure.

Additionally, and specifically relevant to someone who wants to use TextSecure, it will track your use of it. By restricting TextSecure distribution to Google Play, Moxie is saying that if you want to encrypt your SMS messages, you must also be on a centrally located database of people who want to encrypt their SMS messages, along with identity details and a complete record of whatever other applications you run. This state of affairs is totally incomprehensible to me,

You’re right, if I understand your last sentence correctly, that this situation could have been handled better by me. On top of that, we’re lacking the ability to send in-client notifications about important things like this, so unless you read the news here you could be still running the insecure TextSecure without knowing about it. This, many similar things, will be implemented in the client before we dare to call it 1.0.