adrelanos:

Jacob Appelbaum:

...

Do you plan to download TBB over Tor that is provided by the system, say by adding a dependency on a system Tor?

There has been a bit discussion about this in https://trac.torproject.org/projects/tor/ticket/5236 already. (Search for "over Tor" to quickly navigate it it.)

I've seen the ticket.

I think downloading over Tor is desirable, but very difficult to implement.

It is as easy as adding a `depends: tor` line to the debian/control file. In modern Debian or recent Ubuntus, it is fine.

What about bridge users? They have to edit a system wide torrc and the TBB torrc?

You're over thinking it. Connecting to the Tor Project website often fails - far more than the Tor network being blocked.

What about users who don't want to ever connect to the public Tor network? -> https://trac.torproject.org/projects/tor/ticket/7197

Such users have a valid concern but I hardly think that this package is for such users - as it stands right now, that problem is made worse by both connecting to Tor's website *and* the public network.

...

A MITM may be able to replay an old valid signature for a package, does your code handle that case?

I am not Micah, but I don't know how he could. I think the Tor Project would have to finish Thandy for that purpose.

It is easy - never allow a valid signature with a lesser version number.

...

You may enjoy the paper and code on theupdateframework.com to look into those kinds of issues...

Yes, it's really good.

They also gave me a link to https://github.com/akonst/tuf (see docs folder).

Neat. All the best, Jacob

Hey, On 2013-02-18 18:33, adrelanos wrote:

Right, for such users it wouldn't work anyway, because downloading Tor Browser Launcher from the repository is unencrypted (but signed) anyway.

thats not 100% correct. You can use transport encryption (HTTPS) for the repository servers. You simply need to change your source.list to use https. Greetings Leo -- Leo Unglaub Nachreihengasse 39 / Top 7 A-1170 Vienna Austria Phone: 0650 / 6575103 Website: http://www.leo-unglaub.net Twitter: http://twitter.com/LeoUnglaub Send with Mozilla Thunderbird on Linux (Debian)

Leo Unglaub:

Hey,

On 2013-02-18 18:33, adrelanos wrote:

...

Right, for such users it wouldn't work anyway, because downloading Tor Browser Launcher from the repository is unencrypted (but signed) anyway.

thats not 100% correct. You can use transport encryption (HTTPS) for the repository servers. You simply need to change your source.list to use https.

Just checked again. Even if apt-transport-https is installed. # working deb http://security.debian.org/ wheezy/updates main contrib non-free deb http://ftp.us.debian.org/debian wheezy main contrib non-free # not working deb https://security.debian.org/ wheezy/updates main contrib non-free deb https://ftp.us.debian.org/debian wheezy main contrib non-free After the package managers have adapted to the TUF threat model, motivation is low for providing https mirrors. According the the older TUF papers only commercial linux distribution have SSL repositories. With known filesizes, the motivation could be running your own repository with proprietary software or distributing test/unsigned packages for testing on your distant test servers or such use cases. Debian / Ubuntu folks don't seem to be interested in https mirrors.

Citing: https://www.updateframework.com/wiki/Docs/Security#AttacksandWeaknesses

Arbitrary software installation. An attacker installs anything they want on the client system. That is, an attacker can provide arbitrary files in response to download requests and the files will not be detected as illegitimate.

No idea about this one.

Rollback attacks. An attacker presents a software update system with older files than those the client has already seen, causing the client to use files older than those the client knows about.

This would be a non-issue with Jacob's recommendation: "never allow a valid signature with a lesser version number".

Indefinite freeze attacks. An attacker continues to present a software update system with the same files the client has already seen. The result is that the client does not know that new files are available.

Not sure about this one. I think it gets somewhat circumvented by downloading over Tor, i.e. user <-> user ISP <-> Tor <-> torproject.org ISP <-> torproject.org MITM less likely for this route | mitm still possible Ok, if downloading over Tor... What about downloading form the torproject.org hidden service? http://idnxcnkne4qt76tg.onion/ It would never leave the Tor network and even an adversary in position to take down the torproject.org domain, couldn't stop updating.

Endless data attacks. An attacker responds to a file download request with an endless stream of data, causing harm to clients (e.g. a disk partition filling up or memory exhaustion).

Slow retrieval attacks. An attacker responds to clients with a very slow stream of data that essentially results in the client never continuing the update process.

How to defend these two? Will pinning the SSL certificate do the job or should a timeout be added to the download? (I think it depends on if mirrors will be used.)

Extraneous dependencies attacks. An attacker indicates to clients that in order to install the software they wanted, they also need to install unrelated software. This unrelated software can be from a trusted source but may have known vulnerabilities that are exploitable by the attacker.

A non-issue for Tor Browser Launcher, dependencies are managed by the debian package manager, which isn't vulnerable to this. Tor Browser Launcher itself does not have dependency management. No action required.

Mix-and-match attacks. An attacker presents clients with a view of a repository that includes files that never existed together on the repository at the same time. This can result in, for example, outdated versions of dependencies being installed.

Wrong software installation. An attacker provides a client with a trusted file that is not the one the client wanted.

Not sure about these two, but according to the historic TUF papers, SSL (and pinning even more) defeats this. Thus, a hidden services, since also encrypted end-to-end should also defeat this. Thandy would be ideal again, but for now, pinning SSL or using the hidden service should be fine.

Malicious mirrors preventing updates. An attacker in control of one repository mirror is able to prevent users from obtaining updates from other, good mirrors.

Currently no mirrors are not being used. This itself isn't ideal and would welcome Thandy again, but for now, no action required.

Vulnerability to key compromises. At attacker who is able to compromise a single key or less than a given threshold of keys can compromise clients. This includes relying on a single online key (such as only being protected by SSL) or a single offline key (such as most software update systems use to sign files).

This can only be solved with Thandy, TUF or similar. I think it's a bit far fetched for now, so no action required.

extra by adrelanos: 'permanent takedown' threat described it here: https://mailman.boum.org/pipermail/tails-dev/2013-January/002396.html summary: an adversary takes the main repository offline. The TUF people said they are interested in this 'permanent takedown' threat, not sure if TUF defends it at the moment and want to answer me in a week or so if TUF

Also a bit far fetched for now, defeating this and using TUF/Thandy would be ideal, but for now, no action required. By the way, the TUF website (Contact) has also a mailing list with friendly people, which could be asked in doubt. Unfortunately, it does not seem to have public archive.

Micah Lee:

On 02/18/2013 12:15 AM, Jacob Appelbaum wrote:

...

Do you plan to download TBB over Tor that is provided by the system, say by adding a dependency on a system Tor?

I was assuming that making the launcher depend on a system Tor would be troublesome. However now that I'm looking at https://www.torproject.org/docs/debian again, it seems like it could totally work. What about for Ubuntu users?

For normal Debian GNU/Linux users, I believe it will work. For recent versions of Ubuntu, I also believe it will work. I would also say that the launcher could prompt them to actually *add* the Tor repositories that fix the problems Ubuntu users may or may not face in the future.

My workaround plan was to download TBB not over Tor the first time. After extracting it, copy a Firefox extension into the TBB profile, and then run it. From that point on, the extension would be in charge of checking for updates, downloading new updates, and telling the user when they should restart their browser.

I'm not sure I follow? You want to extend TBB to check for updates itself? In the long term, I think that is a fine plan - though in the short term, I think a simple script can be safer, easier and generally better. Imagine for a moment that there was a system wide cache of TBB downloads? One TBB to rule them all, or something. Such a thing wouldn't be easy inside of Firefox.

But I think I'll make a Tor dependency instead. It would make things way simpler and much less work.

Yeah, I totally agree. I'd also say that the code should be aware of the fact that Tor *may* not work - so you many want to look into using stem to either control it (eg: ask a user to enter a bridge) or simply to see the state.

...

...

And there are screenshots here: http://imgur.com/a/Mvpwl

These look pretty great. I'd say the wording needs a bit of work but generally, it seems reasonable. I'd suggest that if signatures don't work, I'd add a 'report' button rather than an exit button. I'd also suggest that you might want to ensure that version numbers are always increasing and other things that are outlined in the. A MITM may be able to replay an old valid signature for a package, does your code handle that case? You may enjoy the paper and code on theupdateframework.com to look into those kinds of issues...

That's a good idea about adding a report button. I just opened a bug for this:

https://github.com/micahflee/torbrowser-launcher/issues/6

Coolness.

What do you think the report button should do? What information should it send back to us, and how should it send it? If there is a real attack and the user can't successfully download TBB, how can we make sure they can successfully report the attack? You can post comments on the bug.

I'll add comments to the bug.

I'll read the paper on the update framework. As it stands, it would be possible for an attacker to replay an old valid signature to get someone to update to an old version. I just opened a new bug for this:

https://github.com/micahflee/torbrowser-launcher/issues/4

Great.

...

Do you pin SSL certs? Or fetch from known mirrors? Or...? :)

No. I assumed that if someone successfully did a MITM attack on the https connection to torproject.org, they wouldn't get their malicious software installed because of the signature verification. Also, I didn't realize urllib2 doesn't check certs automatically. It's a good idea to implement anyway. Thanks for opening the bug about it.

https://github.com/micahflee/torbrowser-launcher/issues/1

Sure - I find it hard to believe that Python's development community actually settled on that as the default behavior. It bites nearly everyone.

...

...

Before trying to get it in Debian I'd like to make it so it doesn't need to be updated each time TBB is updated. There are more details in the ticket, but this would require Tor to maintain a file on https://www.torproject.org/ that has the current version number of TBB in it and a timestamp, and possibly digital signature of this file too.

TBB has a version check built into it - have you seen how it works?

I haven't. Doesn't check.torproject.org tell you if your TBB is out of date? Can you link me to the file where it's implemented?

I'm not sure where it is - I'd ask Mike Perry or Erinn.

...

...

Do you think this is doable?

I think it is reasonable - I wonder though, can't you just fetch https://www.torproject.org/dist/torbrowser/ and parse it to look for files that match a given file pattern? As an example, https://www.torproject.org/dist/torbrowser/?C=M;O=D will sort by latest date, as will https://www.torproject.org/dist/torbrowser/linux/?C=M;O=D for GNU/Linux and so on for Mac OS X: https://www.torproject.org/dist/torbrowser/osx/?C=M;O=A

I'd thought about this, but I wasn't sure if this is a reliable way to know which version to download. For example, when I go to https://www.torproject.org/dist/torbrowser/linux/?C=M;O=D now, the first file is:

tor-browser-gnu-linux-x86_64-2.4.10-alpha-1-dev-en-US.tar.gz.asc

But when I go to the TBB download page, the version I'm presented with is 2.3.25-2, not 2.4.10-alpha-1. Maybe TBB's built-in version check will shed some light onto the best way to know what the latest stable version is.

Well, which should your users be using? From my perspective, I think you should give them the alpha and help them report bugs! :-)

...

...

I also want to get it localized into all the languages TBB is localized into. Any thoughts or suggestions?

Once the program is structured in a way that the strings are pretty much fixed, I'd suggest Transifex: https://www.transifex.com/ as it is what Tor uses for most every translation need.

Cool! I'll wait until this is closer to done and the strings are more fixed to do this.

Great.

...

I'm off to read the code and try it out! Thanks!

Thanks!

I pushed a code audit first pass to the git repo, did you see the branches that I added? All the best, Jacob

On 02/18/2013 12:29 PM, Jacob Appelbaum wrote:

...

I was assuming that making the launcher depend on a system Tor would be troublesome. However now that I'm looking at https://www.torproject.org/docs/debian again, it seems like it could totally work. What about for Ubuntu users?

For normal Debian GNU/Linux users, I believe it will work. For recent versions of Ubuntu, I also believe it will work. I would also say that the launcher could prompt them to actually *add* the Tor repositories that fix the problems Ubuntu users may or may not face in the future.

True. I'll start with just a normal Tor dependency, and if only add the deb.torproject.org repo if it becomes necessary.

...

My workaround plan was to download TBB not over Tor the first time. After extracting it, copy a Firefox extension into the TBB profile, and then run it. From that point on, the extension would be in charge of checking for updates, downloading new updates, and telling the user when they should restart their browser.

I'm not sure I follow? You want to extend TBB to check for updates itself? In the long term, I think that is a fine plan - though in the short term, I think a simple script can be safer, easier and generally better. Imagine for a moment that there was a system wide cache of TBB downloads? One TBB to rule them all, or something. Such a thing wouldn't be easy inside of Firefox.

My plan was to make the Firefox extension, and then after extracting the TBB tarball copying the extension into ~/.torbrowser/tbb/x86_64/tor-browser_en-US/Data/profile/extensions and doing whatever you need to do to enable it that profile. However, since I'm going to make Tor a dependency, it's moot.

...

What do you think the report button should do? What information should it send back to us, and how should it send it? If there is a real attack and the user can't successfully download TBB, how can we make sure they can successfully report the attack? You can post comments on the bug.

I'll add comments to the bug.

Thanks!

...

...

Do you pin SSL certs? Or fetch from known mirrors? Or...? :)

No. I assumed that if someone successfully did a MITM attack on the https connection to torproject.org, they wouldn't get their malicious software installed because of the signature verification. Also, I didn't realize urllib2 doesn't check certs automatically. It's a good idea to implement anyway. Thanks for opening the bug about it.

https://github.com/micahflee/torbrowser-launcher/issues/1

Sure - I find it hard to believe that Python's development community actually settled on that as the default behavior. It bites nearly everyone.

Python's development community also doesn't verifying anything downloaded by pip: http://www.reddit.com/r/Python/comments/17rfh7/warning_dont_use_pip_in_an_un... Hopefully it will get better soon.

...

I'd thought about this, but I wasn't sure if this is a reliable way to know which version to download. For example, when I go to https://www.torproject.org/dist/torbrowser/linux/?C=M;O=D now, the first file is:

tor-browser-gnu-linux-x86_64-2.4.10-alpha-1-dev-en-US.tar.gz.asc

But when I go to the TBB download page, the version I'm presented with is 2.3.25-2, not 2.4.10-alpha-1. Maybe TBB's built-in version check will shed some light onto the best way to know what the latest stable version is.

Well, which should your users be using? From my perspective, I think you should give them the alpha and help them report bugs! :-)

Interesting idea. Anyone else have opinions on this? I think I'd be fine giving people the alpha, but I also don't want to annoy people with too many bugs. Right now it would be easiest to just make it get the alpha. Or, alternatively, I could download https://www.torproject.org/download/download.html.en and parse it for the current version. However, this will break as soon as torproject.org updates it's web design.

I pushed a code audit first pass to the git repo, did you see the branches that I added?

Yup. I merged in your doc-formatting, gpg-keys, and image-fixups branches into my develop branch. https://github.com/micahflee/torbrowser-launcher/tree/develop And I opened issues for most of things you brought up in the code review branch: https://github.com/micahflee/torbrowser-launcher/issues For the things I didn't open issues on, here are my thoughts: https://github.com/ioerror/torbrowser-launcher/commit/bfe97f49e53c1de5a69721... I think it's safe to overwrite whatever is in the version file here, since TBB isn't installed yet. Unless someone messed with their ~/.torbrowser/ folder, it shouldn't exist yet. The version file is supposed to represent the currently installed version, but I think I might refactor this stuff anyway since I'm going to make it check for updates rather than hard-coding the latest version. https://github.com/ioerror/torbrowser-launcher/commit/bfe97f49e53c1de5a69721... I'm not sure if arch is portable. I could easily switch it to uname -m, if that's more portable. https://github.com/ioerror/torbrowser-launcher/commit/bfe97f49e53c1de5a69721... If HOME isn't set, what should happen? Should tbb_data be set to /tmp/tbb-USER or something? https://github.com/ioerror/torbrowser-launcher/commit/bfe97f49e53c1de5a69721... Yeah, we should depend on tar I think. Originally I wasn't thinking of releasing this for OS X, since I was thinking it would know about updated versions of TBB when torbrowser-launcher gets updated from the deb repositories. But now it seems plausible to make this cross-platform. However, Windows TBB releases are .exe, which wouldn't work with this. Maybe this should be GNU/Linux only at first, and future releases could be for OS X and Windows. -- Micah Lee https://twitter.com/micahflee

On 02/18/2013 02:31 PM, adrelanos wrote:

Why not phrase https://check.torproject.org/RecommendedTBBVersions ? No updates planed for it even in long term as far I am following trac...

Oh cool, so Tor already has a file with the recommended TBB version! And this gets updated regularly when new TBB versions come out? -- Micah Lee https://twitter.com/micahflee

I followed the readme for dependency installing, building and installing from the develop branch. Running into two issues trying this... LC_ALL and LANG is not set on my system. develop ~/torbrowser-launcher/dist/deb_dist $ torbrowser-launcher Tor Browser Launcher https://github.com/micahflee/torbrowser-launcher Traceback (most recent call last): File "/usr/bin/torbrowser-launcher", line 352, in <module> app = TorBrowserLauncher(current_tbb_version) File "/usr/bin/torbrowser-launcher", line 13, in __init__ self.discover_arch_lang(); File "/usr/bin/torbrowser-launcher", line 65, in discover_arch_lang self.language = locale.getdefaultlocale()[0].replace('_', '-') AttributeError: 'NoneType' object has no attribute 'replace' Setting them, fixes this. I am not sure how many other people may not have these values set, so I think this should be fixed. Let's set them and try again. develop ~/torbrowser-launcher/dist/deb_dist $ export LC_ALL=en_GB.UTF-8 develop ~/torbrowser-launcher/dist/deb_dist $ export LANG=en_GB.UTF-8 Running into another issue. develop ~/torbrowser-launcher/dist/deb_dist $ torbrowser-launcher Tor Browser Launcher https://github.com/micahflee/torbrowser-launcher Traceback (most recent call last): File "/usr/bin/torbrowser-launcher", line 352, in <module> app = TorBrowserLauncher(current_tbb_version) File "/usr/bin/torbrowser-launcher", line 55, in __init__ self.build_ui() File "/usr/bin/torbrowser-launcher", line 124, in build_ui settings.props.gtk_button_images = True AttributeError: 'gobject.GProps' object has no attribute 'gtk_button_images' develop ~/torbrowser-launcher/dist/deb_dist $ Am I missing a dependency or?

Micah Lee:

On 02/19/2013 03:29 AM, adrelanos wrote:

...

I followed the readme for dependency installing, building and installing from the develop branch. Running into two issues trying this...

LC_ALL and LANG is not set on my system.

develop ~/torbrowser-launcher/dist/deb_dist $ torbrowser-launcher Tor Browser Launcher https://github.com/micahflee/torbrowser-launcher Traceback (most recent call last): File "/usr/bin/torbrowser-launcher", line 352, in <module> app = TorBrowserLauncher(current_tbb_version) File "/usr/bin/torbrowser-launcher", line 13, in __init__ self.discover_arch_lang(); File "/usr/bin/torbrowser-launcher", line 65, in discover_arch_lang self.language = locale.getdefaultlocale()[0].replace('_', '-') AttributeError: 'NoneType' object has no attribute 'replace'

Setting them, fixes this. I am not sure how many other people may not have these values set, so I think this should be fixed.

Strange. I thought that locale.getdefaultlocale() was supposed to be the cross-platform method for figuring out the default locale, without the LANG field.

What operating system are you using?

Debian Wheezy.

Maybe your getdefaultlocale() doesn't return a tuple or something. Here's what mine returns -- what about yours?

develop ~/torbrowser-launcher $ python Python 2.7.3 (default, Jan 2 2013, 16:53:07) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.

...

...

import locale locale.getdefaultlocale() (None, None)

...

Let's set them and try again.

develop ~/torbrowser-launcher/dist/deb_dist $ export LC_ALL=en_GB.UTF-8 develop ~/torbrowser-launcher/dist/deb_dist $ export LANG=en_GB.UTF-8

Running into another issue.

develop ~/torbrowser-launcher/dist/deb_dist $ torbrowser-launcher Tor Browser Launcher https://github.com/micahflee/torbrowser-launcher Traceback (most recent call last): File "/usr/bin/torbrowser-launcher", line 352, in <module> app = TorBrowserLauncher(current_tbb_version) File "/usr/bin/torbrowser-launcher", line 55, in __init__ self.build_ui() File "/usr/bin/torbrowser-launcher", line 124, in build_ui settings.props.gtk_button_images = True AttributeError: 'gobject.GProps' object has no attribute 'gtk_button_images' develop ~/torbrowser-launcher/dist/deb_dist $

Am I missing a dependency or?

Yes, sorry I haven't added the dependencies to the debian package yet. You need python-gtk2.

It is installed. develop ~/torbrowser-launcher $ sudo apt-get install python-gtk2 [sudo] password for user: Reading package lists... Done Building dependency tree Reading state information... Done python-gtk2 is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 27 not upgraded. develop ~/torbrowser-launcher $ ./torbrowser-launcher Tor Browser Launcher https://github.com/micahflee/torbrowser-launcher Traceback (most recent call last): File "./torbrowser-launcher", line 352, in <module> app = TorBrowserLauncher(current_tbb_version) File "./torbrowser-launcher", line 55, in __init__ self.build_ui() File "./torbrowser-launcher", line 124, in build_ui settings.props.gtk_button_images = True AttributeError: 'gobject.GProps' object has no attribute 'gtk_button_images' develop ~/torbrowser-launcher $

On 02/19/2013 06:39 PM, adrelanos wrote:

...

What operating system are you using?

Debian Wheezy.

Weird, that's what I'm running Wheezy too. But just to be safe, I decided I'd make a new Debian Squeeze vm and try to build it and run it in there. I found several small problems and fixed them.

develop ~/torbrowser-launcher $ python Python 2.7.3 (default, Jan 2 2013, 16:53:07) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.

...

...

...

import locale locale.getdefaultlocale() (None, None)

I haven't fixed this yet. But I did just open a bug for it: https://github.com/micahflee/torbrowser-launcher/issues/12

develop ~/torbrowser-launcher $ sudo apt-get install python-gtk2 [sudo] password for user: Reading package lists... Done Building dependency tree Reading state information... Done python-gtk2 is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 27 not upgraded. develop ~/torbrowser-launcher $ ./torbrowser-launcher Tor Browser Launcher https://github.com/micahflee/torbrowser-launcher Traceback (most recent call last): File "./torbrowser-launcher", line 352, in <module> app = TorBrowserLauncher(current_tbb_version) File "./torbrowser-launcher", line 55, in __init__ self.build_ui() File "./torbrowser-launcher", line 124, in build_ui settings.props.gtk_button_images = True AttributeError: 'gobject.GProps' object has no attribute 'gtk_button_images' develop ~/torbrowser-launcher $

I'm not sure why you're getting this error, but it's on the line that allows icons for buttons. Since it's not critical, I placed in a try block, so if it fails on your computer it shouldn't crash the program, the buttons just won't have icons. git pull origin master and try again, and let me know if you run into any other problems. -- Micah Lee https://twitter.com/micahflee

adrelanos:

Micah Lee:

...

...

...

Well, which should your users be using? From my perspective, I think you should give them the alpha and help them report bugs! :-)

Interesting idea. Anyone else have opinions on this? I think I'd be fine giving people the alpha, but I also don't want to annoy people with too many bugs.

No, please no alphas by default. This defeats the purpose of alphas. As a fast solution: stable only. As a medium solution: allow choosing stable or alpha. As an ideal solution: allow both to coexist.

This is all alpha software, no?

...

Right now it would be easiest to just make it get the alpha.

Or, alternatively, I could download https://www.torproject.org/download/download.html.en and parse it for the current version. However, this will break as soon as torproject.org updates it's web design.

Why not phrase https://check.torproject.org/RecommendedTBBVersions ? No updates planed for it even in long term as far I am following trac...

That is probably an alright way to do things. All the best, Jacob

Micah Lee:

On 02/18/2013 12:29 PM, Jacob Appelbaum wrote:

...

...

I was assuming that making the launcher depend on a system Tor would be troublesome. However now that I'm looking at https://www.torproject.org/docs/debian again, it seems like it could totally work. What about for Ubuntu users?

For normal Debian GNU/Linux users, I believe it will work. For recent versions of Ubuntu, I also believe it will work. I would also say that the launcher could prompt them to actually *add* the Tor repositories that fix the problems Ubuntu users may or may not face in the future.

True. I'll start with just a normal Tor dependency, and if only add the deb.torproject.org repo if it becomes necessary.

That seems fine as a start.

...

...

My workaround plan was to download TBB not over Tor the first time. After extracting it, copy a Firefox extension into the TBB profile, and then run it. From that point on, the extension would be in charge of checking for updates, downloading new updates, and telling the user when they should restart their browser.

I'm not sure I follow? You want to extend TBB to check for updates itself? In the long term, I think that is a fine plan - though in the short term, I think a simple script can be safer, easier and generally better. Imagine for a moment that there was a system wide cache of TBB downloads? One TBB to rule them all, or something. Such a thing wouldn't be easy inside of Firefox.

My plan was to make the Firefox extension, and then after extracting the TBB tarball copying the extension into ~/.torbrowser/tbb/x86_64/tor-browser_en-US/Data/profile/extensions and doing whatever you need to do to enable it that profile. However, since I'm going to make Tor a dependency, it's moot.

I think a Firefox extension is a fine idea generally but specifically, an out of TBB solution seems most expedient.

...

...

What do you think the report button should do? What information should it send back to us, and how should it send it? If there is a real attack and the user can't successfully download TBB, how can we make sure they can successfully report the attack? You can post comments on the bug.

I'll add comments to the bug.

Thanks!

...

...

...

Do you pin SSL certs? Or fetch from known mirrors? Or...? :)

No. I assumed that if someone successfully did a MITM attack on the https connection to torproject.org, they wouldn't get their malicious software installed because of the signature verification. Also, I didn't realize urllib2 doesn't check certs automatically. It's a good idea to implement anyway. Thanks for opening the bug about it.

https://github.com/micahflee/torbrowser-launcher/issues/1

Sure - I find it hard to believe that Python's development community actually settled on that as the default behavior. It bites nearly everyone.

Python's development community also doesn't verifying anything downloaded by pip: http://www.reddit.com/r/Python/comments/17rfh7/warning_dont_use_pip_in_an_un...

Hopefully it will get better soon.

Yeah, I'm unimpressed to say the least. I know it has been that way for a while. I'm pretty amazed that someone hasn't just tossed up an SSL mirror with some look-aside code.

...

...

I'd thought about this, but I wasn't sure if this is a reliable way to know which version to download. For example, when I go to https://www.torproject.org/dist/torbrowser/linux/?C=M;O=D now, the first file is:

tor-browser-gnu-linux-x86_64-2.4.10-alpha-1-dev-en-US.tar.gz.asc

But when I go to the TBB download page, the version I'm presented with is 2.3.25-2, not 2.4.10-alpha-1. Maybe TBB's built-in version check will shed some light onto the best way to know what the latest stable version is.

Well, which should your users be using? From my perspective, I think you should give them the alpha and help them report bugs! :-)

Interesting idea. Anyone else have opinions on this? I think I'd be fine giving people the alpha, but I also don't want to annoy people with too many bugs.

I don't think there are too many bugs - I use the alpha all the time and it seems fine.

Right now it would be easiest to just make it get the alpha.

Or, alternatively, I could download https://www.torproject.org/download/download.html.en and parse it for the current version. However, this will break as soon as torproject.org updates it's web design.

Well, we have wml files as well - so you can just look at those rather than the published site.

...

I pushed a code audit first pass to the git repo, did you see the branches that I added?

Yup. I merged in your doc-formatting, gpg-keys, and image-fixups branches into my develop branch.

Cool, thanks!

https://github.com/micahflee/torbrowser-launcher/tree/develop

And I opened issues for most of things you brought up in the code review branch: https://github.com/micahflee/torbrowser-launcher/issues

Great - I'll comment on each respective bug.

For the things I didn't open issues on, here are my thoughts:

https://github.com/ioerror/torbrowser-launcher/commit/bfe97f49e53c1de5a69721...

I think it's safe to overwrite whatever is in the version file here, since TBB isn't installed yet. Unless someone messed with their ~/.torbrowser/ folder, it shouldn't exist yet. The version file is supposed to represent the currently installed version, but I think I might refactor this stuff anyway since I'm going to make it check for updates rather than hard-coding the latest version.

Are you sure that it is always ~/.torbrowser/ though? :)

https://github.com/ioerror/torbrowser-launcher/commit/bfe97f49e53c1de5a69721...

I'm not sure if arch is portable. I could easily switch it to uname -m, if that's more portable.

My guess is that uname -m is more portable; though I bet that os.uname or sys.platform in Python would be the most portable.

https://github.com/ioerror/torbrowser-launcher/commit/bfe97f49e53c1de5a69721...

If HOME isn't set, what should happen? Should tbb_data be set to /tmp/tbb-USER or something?

Well, I think that is an interesting question too. Are we sure that if HOME is set that we want to write to the disk? If so, I guess we should make a directory with mktemp or a similar Python call.

https://github.com/ioerror/torbrowser-launcher/commit/bfe97f49e53c1de5a69721...

Yeah, we should depend on tar I think.

I'd suggest libtarfile rather than tar - it is written in pure Python.

Originally I wasn't thinking of releasing this for OS X, since I was thinking it would know about updated versions of TBB when torbrowser-launcher gets updated from the deb repositories. But now it seems plausible to make this cross-platform. However, Windows TBB releases are .exe, which wouldn't work with this.

I wrote the original .exe for a different use case and while I generally agree with you - I don't think there is any reason that we can't make native win32 UX that matches the flow of this gtk app.

Maybe this should be GNU/Linux only at first, and future releases could be for OS X and Windows.

I think that is a fine idea - though I suggest pure Python like things to make it portable between GNU/Linux and *BSD from the start. All the best, Jake

Jacob Appelbaum:

Micah Lee:

...

On 02/18/2013 12:15 AM, Jacob Appelbaum wrote:

...

Do you plan to download TBB over Tor that is provided by the system, say by adding a dependency on a system Tor?

I was assuming that making the launcher depend on a system Tor would be troublesome. However now that I'm looking at https://www.torproject.org/docs/debian again, it seems like it could totally work. What about for Ubuntu users?

For normal Debian GNU/Linux users, I believe it will work. For recent versions of Ubuntu, I also believe it will work. I would also say that the launcher could prompt them to actually *add* the Tor repositories that fix the problems Ubuntu users may or may not face in the future.

Just a implementation suggestion: Drop a file inside /etc/apt/sources.list.d/, i.e. /etc/apt/sources.list.d/torproject.list. Perhaps you already knew about the awesome .d magic, just in case.