Tor Messenger 0.1.0b5 is released
We are pleased to announce another public beta release of Tor Messenger. This release features important security updates to libotr, and addresses a number of stability and usability issues. All users are highly encouraged to upgrade.
The initial public release was a success in that it garnered a lot of useful feedback. We tried to respond to all your concerns in the comments of the blog post but also collected and aggregated a FAQ of the most common questions.
OTR over Twitter DMs
Tor Messenger now supports OTR conversations over Twitter DMs (direct messages). Simply configure your Twitter account with Tor Messenger and add the Twitter account you want as a contact. Any (direct) message you send to another Twitter contact will be sent over OTR provided that both contacts are running Tor Messenger (or another client that supports Twitter DMs and OTR).
Facebook support dropped
Facebook has long officially deprecated their XMPP gateway, and it doesn't appear to work anymore. We had multiple reports from users about this issue and decided that it was best to remove support for Facebook from Tor Messenger.
We hear that an implementation of the new mqtt based protocol is in the works, so we hope to restore this functionality in the future.
Before upgrading, back up your OTR keys
Before upgrading to the new release, you will need to back up your OTR keys or simply generate new ones. Please see the following steps to back them up.
In the future, we plan to port Tor Browser's updater patches (#14388) so that keeping Tor Messenger up to date is seamless and automatic. We also plan to add a UI to make importing OTR keys and accounts from Pidgin, and other clients, as easy as possible (#16526).
The secure updater will likely be a part of the next release of Tor Messenger.
Please note that Tor Messenger is still in beta. The purpose of this release is to help test the application and provide feedback. At-risk users should not depend on it for their privacy and safety.
sha256sums.txt file containing hashes of the bundles is signed with the key
3A0B 3D84 3708 9613 6B84 5E82 6887 935A B297 B391).
Here is the complete changelog since v0.1.0b4:
Tor Messenger 0.1.0b5 -- March 09, 2016
- All Platforms
- Bug 13795: Remove SPI root certificate because Debian no longer ships it
- Bug 18094: Remove references to torbutton from start-tor-messenger script
- Bug 18235: Disable Facebook as they no longer support XMPP
- Bug 17494: Better error reporting for failed outgoing messages
- Bug 17749: Show version information in the "About" window
- Bug 13312: Add support for OTR over Twitter DMs
- Bump libotr to 4.1.1
- Bug 17896: Add Edit menu to the conversation window on OS X
- GH 65: Support Unicode paths on Windows
Yes, it could and that's something we've considered (and are still considering). We went with libotr because it's correct and constant time and audited, but these memory safety issues are indeed troubling.
Even though I don't yet really understand all of the design decisions you explain briefly, I think one of the most promising things about TM is the fact that you are trying to explain design decisions in response to queries from technically able users. That's very important because it helps less able users to trust that you are thinking hard about all these things. I think most less able users (like me) are at least capable of understanding that everything is tradeoff, and that all we can reasonably ask is that you make careful choices and continually reexamine them. (I hope TM will be able to remain sufficiently nimble to undo a bad decision in the event of some possible future revelation in BlackHat etc. which changes expert opinion on the relative hazard of various different vulnerabilities affecting TM's reverse dependencies.)
I'd love to see an Ars article by one of their intrepid journalists which tries to explain the design decisions you have defended in more detail. Even better if Tor Project can get a sizable fraction of journalists who write about tech to help us all beta test TM.
We can certainly do better and one of the things we want to get across is who can see what in a typical Tor Messenger conversation. Can your ISP or the server see what you are talking about (no)? Can the server see who you are talking to (yes)? We need to get this information across to users, in a simple "yes" "no" "maybe" tabular format. We are tracking this in https://trac.torproject.org/projects/tor/ticket/17528.