Get TorBrowser in Debian

added component::applications/tor browser owner::tbb-team priority::medium severity::normal status::new type::task labels

Something to keep in mind is that in the TBB setting, Vidalia launches Tor and assigns a controller password, and then Vidalia launches Firefox and passes the controller password (and control port) as environment variables. It's not strictly necessary, but it's how Torbutton can trigger a 'new identity' call.

If Torbutton does #3968 (closed) or #3967 (closed), it would be on its way to being able to play well with the Tor deb, which (as of 0.2.2.x) sets both of those but doesn't configure any hashedpassword auth.

Another (more hacky) option is that Vidalia uses controlsocket or cookie auth to connect to Tor, then setconfs a hashedpassword option and launches Firefox with it.

Replying to arma:

If Torbutton does #3968 (closed) or #3967 (closed), it would be on its way to being able to play well with the Tor deb, which (as of 0.2.2.x) sets both of those but doesn't configure any hashedpassword auth.

And by "both of those" I mean controlsocket and cookie auth.

Mike fixed #3968 (closed). How much closer are we now?

Replying to arma:

Mike fixed #3968 (closed). How much closer are we now?

We still need a configuration-update tool for Firefox profiles, and a program that knows when to run that tool. On Debian, we would also need to ensure that configuration-update instructions are left installed on the system for updates from every version which has ever been installed on the system to the latest configuration version, until every TBB profile kept by each user on the system has been upgraded. (In general, determining whether it is safe to discard a piece of update information kept on the system requires breaking every encryption algorithm in existence, as well as solving the Halting Problem.)

Trac:
Cc: lunar@debian.org to lunar@debian.org, g.koppen@jondos.de

One problem I can foresee with the idea of packaging TorBrowser for Debian is that the packaging of Firefox/Iceweasel usually lags behind upstream by several version numbers. This is particularly true of Debian stable. Thus it's likely that for most of the lifetime of each Debian stable release, the version of Iceweasel in stable will be considerably older than the version of Firefox that the upstream TorBrowser bundle is based on.

It is probably possible for an active attacker to detect the underlying version of Firefox by probing the level of javascript/css/html support that the browser provides (e.g. see the ecmascript compatibility tables at http://kangax.github.com/es5-compat-table/ ). Thus a Debian-packaged TorBrowser will have a different "fingerprint" to a recent upstream TorBrowserBundle, and an attacker who is trying to track users will be able to distinguish between the two.

If there are considerably fewer users of Debian-packaged TorBrowser than users of the upstream TorBrowserBundle on all platforms (which is likely), users of Debian-packaged TorBrowser would have significantly less anonymity than users of the upstream TorBrowserBundle.

Unassigning from myself. Someone else should feel free to take this.

Trac:
Status: new to assigned
Owner: erinn to N/A

Related to, but no duplicate: #5236 (moved) "Make a deb of the Torbrowser and add to repository". (It's a request, to add Tor Browser as a standalone to the Tor repository.)

Trac:
Cc: lunar@debian.org, g.koppen@jondos.de to lunar@debian.org, g.koppen@jondos.de, proper@secure-mail.biz

As it's not assigned to anyone, I change state to "Needs more information".

Trac:
Status: assigned to needs_information

Sorry, but this issue does not need more information than what is available. It just needs someone to do the work.

Unfortunately, the task is daunting and its been a while since I had several consecutive days to focus on this. There is hope, though, as I might be able to spend a day with Mike Hommey to work out the interactions with Iceweasel source and binaries in a not so distant future. We'll see what will come out of it.

Absolutely.

Trac:
Status: needs_information to assigned

Trac:
Cc: lunar@debian.org, g.koppen@jondos.de, proper@secure-mail.biz to lunar@debian.org, g.koppen@jondos.de, proper@secure-mail.biz, tails@boum.org

Why so complicated? Why do you want to go through the hassle, getting Tor Browser into Debian?

Getting Tor Browser into the Tor repository, should be an easier, more realistic task, which could be done in near future? I think it's also required preparation for Thandy. Tor/Vidalia/etc. are already in the Tor repository. I don't understand, why you want to go a special way for Tor Browser.

Leaving the distro packaging to the distros. They can pick it up, once it's in the Tor repository. If Debian wants it, they have to get interested themselves.

I also believe, that the following statement is true.

Replying to cypherpunks:

One problem I can foresee with the idea of packaging TorBrowser for Debian is that the packaging of Firefox/Iceweasel usually lags behind upstream by several version numbers. This is particularly true of Debian stable. [snip, see above...]

Replying to proper:

Why so complicated? Why do you want to go through the hassle, getting Tor Browser into Debian?

Because of the same reasons you'd usually want to use the native repository and bug tracker of a distro for most applications.

Getting Tor Browser into the Tor repository, should be an easier, more realistic task, which could be done in near future? I think it's also required preparation for Thandy. Tor/Vidalia/etc. are already in the Tor repository. I don't understand, why you want to go a special way for Tor Browser.

Leaving the distro packaging to the distros. They can pick it up, once it's in the Tor repository. If Debian wants it, they have to get interested themselves.

I also believe, that the following statement is true.

Replying to cypherpunks:

One problem I can foresee with the idea of packaging TorBrowser for Debian is that the packaging of Firefox/Iceweasel usually lags behind upstream by several version numbers. This is particularly true of Debian stable. [snip, see above...]

Hmm, maybe because of that it might make sense to try to get the patches of the TorBrowser upstream (I count 26 patches in src/current-patches/)? So that an 'iceweasel-tor' package could actually just provide a wrapper script, with no need for a modified Firefox/Iceweasel binary (which is probably easier said than done :), I obviously have no clue of the TorBrowser internals). This should greatly reduce long term maintance costs for an iceweasel-tor Debian package, shouldn't it?

Also another stupid question: I'm one of the Debian users who'd run a Debian iceweasel-tor next to a non-tor iceweasel. For the use-cases I'd have for the iceweasel-tor, I think I could live with an immutable, default profile. Actually, I think I'd feel much safer on a non-live-CD OS, if the Iceweasel profile for the Tor version were immutable (don't know if that makes sense). An immutable default profile should postpone the problems mentioned by lunar for now, right? It should postpone the need for a 'configuration-update tool for Firefox profiles' as rransom mentioned, shouldn't it?

Hmm, for the javascript/css/html support probing attack mentioned by cypherpunks, I guess an option to disable some of them in iceweasel would be needed, to unify iceweasel-tor fingerprint?

Trac:
Username: tux

With both Tor and Debian on ESR probing and "outdated versions" is no longer an issue - till Mozilla drops support for 10.* and Debian stable doesn't follow. But for that there's http://mozilla.debian.net/ and backports. No reason for a iceweasel-tor not to be available the same way.

Replying to tux:

Hmm, maybe because of that it might make sense to try to get the patches of the TorBrowser upstream (I count 26 patches in src/current-patches/)?

Great idea! Adding them upstream is the way to go. Not sure if that is realistic...

Source: https://lists.torproject.org/pipermail/tor-talk/2012-June/024572.html Relevant quote:

- Camilo Viecco, who now works for Mozilla on adding privacy features to
Firefox. He has been frustrated so far at getting his commits in: he has
buy-in from the security team, but other teams block his commits with
statements like "it's an arms race we can't win, so don't even bother
trying to make things better". I encouraged him to get his mid-level
manager to play the politics game better on his behalf.

Iirc, there was also a socks bug, where patch existed and mozilla still needed no less than 5 years until they finally merged it.

Please ask Mike on how difficult/realistic it is, to get the patches merged upstream. Since he hasn't replied to this thread, I'll mail him about it right away. Feel free to contact him as well by mail or ask about the patches thing on irc.

Replying to tux:

Hmm, maybe because of that it might make sense to try to get the patches of the TorBrowser upstream (I count 26 patches in src/current-patches/)? So that an 'iceweasel-tor' package could actually just provide a wrapper script, with no need for a modified Firefox/Iceweasel binary (which is probably easier said than done :), I obviously have no clue of the TorBrowser internals). This should greatly reduce long term maintance costs for an iceweasel-tor Debian package, shouldn't it?

TorBrowser contains patches against Firefox only because getting upstream to include the needed privacy fixes and improvements has always been painful until now.

On the Debian side, Mike Hommey said he did not want to be accountable for issues related to the TorBrowser patches and so he does not want to include them in the main 'iceweasel' package.

What he his willing to support and provide (and Debian security team is supportive as well) is an 'iceweasel-src' package that would contain Iceweasel source code. Another package could be built using it to create the TorBrowser.

I still would like to do that part of the work. Life has been an issue, though. If people with enough Debian knowledge have enough free time on their hands, they should go ahead!

I've been following this bug, and think I came up with a workable solution. I don't think it could end up in Debian, however, because it does include shipping the result of the TorBrowserBundle build.

But I think it would be great to get this in the deb.torproject.org repository, and have Debian people put in the effort if they want it in the main repository.

Basically, we can make a deb package that contains a launcher script and the TBB tarball. When you run the launcher script, it checks if the current user has ~/.torbrowser/

VERSION. If they don't, it extracts the TBB tarball to that folder. Then it runs ~/.torbrowser/

VERSION/start-tor-browser.

Updated versions of the package would just include the new TBB tarball and the $VERSION variable would be changed.

Since this uses the same TBB that others use, it avoids problems with browser fingerprinting recognizing Debian users. It also allows you to have a changable Firefox profile like people are used to, however it will get reset with each upgrade.

I went ahead and made a proof-of-concept that works great: https://github.com/micahflee/torbrowser

Here's the launcher script: https://github.com/micahflee/torbrowser/blob/master/torbrowser-bin

This package I made also includes a "Tor Browser" application launcher that uses the TBB icon to show up in the desktop manager application menu. Could this work?

I posted about this to tor-talk but haven't heard any feedback: https://lists.torproject.org/pipermail/tor-talk/2013-January/027090.html

Trac:
Cc: lunar@debian.org, g.koppen@jondos.de, proper@secure-mail.biz, tails@boum.org to lunar@debian.org, g.koppen@jondos.de, proper@secure-mail.biz, tails@boum.org, micahflee@riseup.net

It is great to see any kind of progress on this ticket. Since it can't go into Debian but into torproject.org deb repository it should perhaps be better discussed in:

#5236 (moved) "Make a deb of the Torbrowser and add to repository"

In case you're following this bug but not the related #5236 (moved) bug, I just posted an update that affects this bug: https://trac.torproject.org/projects/tor/ticket/5236#comment:32

I've written a launcher program called Tor Browser Launcher that I think can get accepted into Debian without a problem, that hands downloading TBB for the first time or downloading updates, verifying signatures, extracting it, and running it.

Replying to micahlee:

I've written a launcher program called Tor Browser Launcher that I think can get accepted into Debian without a problem, that hands downloading TBB for the first time or downloading updates, verifying signatures, extracting it, and running it.

I'm sure your launcher program will be useful to some users, but it's not a substitute for a proper torbrowser debian package. In particular, it's useless to users on architectures other than x86.

Trac:
Username: emorris

Replying to emorris:

Replying to micahlee:

I've written a launcher program called Tor Browser Launcher that I think can get accepted into Debian without a problem, that hands downloading TBB for the first time or downloading updates, verifying signatures, extracting it, and running it.

I'm sure your launcher program will be useful to some users, but it's not a substitute for a proper torbrowser debian package. In particular, it's useless to users on architectures other than x86.

Why is that? TBB for Linux is only released in x86 and amd64, and Tor Browser Launcher works great for both.

It's been a couple weeks since I've had time to fix the final bugs (I'm hoping to dig out a solid hack day soon), but it already works well enough to download TBB for your architecture, in your language, verify signatures, and auto-update.

Go ahead and git clone it, and follow the readme to build a deb: https://github.com/micahflee/torbrowser-launcher

Replying to micahlee:

Why is that? TBB for Linux is only released in x86 and amd64, and Tor Browser Launcher works great for both.

I'm sorry, I certainly didn't mean to denigrate your work, your launcher program makes it very easy for users on i386 and amd64 to download the official TBB.

As you say, TBB is only built for i386 and amd64 (I was referring to both collectively when I said x86), and Debian supports many other architectures. However, there's nothing really architecture-specific about Tor Browser; a proper debian-packaged Tor Browser would be built for every architecture that debian supports.

Also, packages that download binaries as torbrowser-launcher does, generally can't be distributed in Debian main. Moreover, torbrowser-launcher won't work when access to the tor project website is being blocked; a proper debian-packaged Tor Browser would be distributed via the standard debian mirrors.

In the absence of such a package, torbrowser-launcher is certainly useful for users on x86.

Trac:
Username: emorris

FWIW, it seems that Tails now maintains a version of the iceweasel package with the torbrowser patches applied, see https://tails.boum.org/todo/replace_iceweasel_with_Torbrowser/#index2h3

Trac:
Username: emorris