In my spare time I've been working on a way to make the Tor Browser Bundle easier to use for GNU/Linux users. I've mostly been talking about it with other people on tor-talk and in this bug: https://trac.torproject.org/projects/tor/ticket/5236
I decided to write Tor Browser Launcher, a completely separate program that's in charge or adding a "Tor Browser" .desktop file (so you can open it from your desktop environment's menu), downloads the latest version for you, verifies it's signature (making it more secure than how much GNU/Linux users get TBB), and installs it in your home directory. I think that Tor Browser Launcher can get in Debian and Ubuntu.
I just finished a first version of it. The code is here: https://github.com/micahflee/torbrowser-launcher
And there are screenshots here: http://imgur.com/a/Mvpwl
You can read details about how it works on my latest comment on that bug: https://trac.torproject.org/projects/tor/ticket/5236#comment:32
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.
Do you think this is doable?
I also want to get it localized into all the languages TBB is localized into. Any thoughts or suggestions?
Micah Lee:
In my spare time I've been working on a way to make the Tor Browser Bundle easier to use for GNU/Linux users. I've mostly been talking about it with other people on tor-talk and in this bug: https://trac.torproject.org/projects/tor/ticket/5236
Thanks for documenting so much on that bug!
I decided to write Tor Browser Launcher, a completely separate program that's in charge or adding a "Tor Browser" .desktop file (so you can open it from your desktop environment's menu), downloads the latest version for you, verifies it's signature (making it more secure than how much GNU/Linux users get TBB), and installs it in your home directory. I think that Tor Browser Launcher can get in Debian and Ubuntu.
Do you plan to download TBB over Tor that is provided by the system, say by adding a dependency on a system Tor?
I just finished a first version of it. The code is here: https://github.com/micahflee/torbrowser-launcher
Awesome, I've forked it and if I see anything, I'll send you a pull request.
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...
Do you pin SSL certs? Or fetch from known mirrors? Or...? :)
You can read details about how it works on my latest comment on that bug: https://trac.torproject.org/projects/tor/ticket/5236#comment:32
Seems straight forward.
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?
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 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.
I'm off to read the code and try it out! Thanks!
All the best, Jake
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 think downloading over Tor is desirable, but very difficult to implement.
What about bridge users? They have to edit a system wide torrc and the TBB torrc?
What about users who don't want to ever connect to the public Tor network? -> https://trac.torproject.org/projects/tor/ticket/7197
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.
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).
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
Jacob Appelbaum:
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.
Ok.
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.
Right, for such users it wouldn't work anyway, because downloading Tor Browser Launcher from the repository is unencrypted (but signed) anyway.
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:
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.
While it is correct, that there is an apt https package, last time I checked, not much more than a month ago, no Debian or Ubuntu repositories supported https nor are willing to do this in future. Did this change?
Even if using https, there are known file sizes, so it wouldn't really hide what has been downloaded?
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.
You can't even download Ubuntu off Ubuntu.com via SSL. Only HTTP.
On 02/19/2013 01:06 AM, adrelanos wrote:
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. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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.
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?
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.
But I think I'll make a Tor dependency instead. It would make things way simpler and much less work.
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
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 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
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
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?
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.
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.
I'm off to read the code and try it out! Thanks!
Thanks!
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:
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:
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.
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
Jacob Appelbaum:
Well, which should your users be using? From my perspective, I think you should give them the alpha and help them report bugs! :-)
maybe give the user the choice, with stable as the default? after all, this project aims to make it easier for non-powerusers to get TBB running, right?
thanks a bunch for working on this. you folks are awesome :) -krugar
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.
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:
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.
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...
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:
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?
I haven't found any guidelines for creating new builds used by the maintainer, but as far as my experience tells, it was always reliably updated. Each time there was an announcement on the Tor blog, also check.torproject.org reported an update. As far as I learned from trac, Tor Button code fetches that page, locally phrases it and decides to open the "up to date" or "there is a security update" page afterwards.
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?
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? Maybe your getdefaultlocale() doesn't return a tuple or something. Here's what mine returns -- what about yours?
[micah@spock] ~$ python Python 2.7.3 (default, Jan 2 2013, 13:56:14) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import locale locale.getdefaultlocale()
('en_US', 'UTF-8')
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.
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 Wed, 20 Feb 2013 02:39:10 +0000 adrelanos adrelanos@riseup.net wrote:
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
According to http://wiki.debian.org/Locale#Standard they should return None but you can do some other steps to get useful values in there.
Another advice i've seen is just to run dpkg-reconfigure locales
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:
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.
Works for me. Looks great!
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
Jacob Appelbaum:
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?
No.
I know, it's not your voice, but the Tor blog frequently talks about "New Tor Browser Bundles" and different "Alpha Bundles Available for Testing"
https://blog.torproject.org/category/tags/tor-browser-bundle
"2.4.7-alpha-1-Linux-i386" https://www.torproject.org/dist/torbrowser/linux/tor-browser-gnu-linux-i686-...
is "more Alpha" than
"2.3.25-2-Linux-i686" https://www.torproject.org/dist/torbrowser/linux/tor-browser-gnu-linux-i686-...
From a user perspective accustomed using the default download from
torproject.org (for my os) of TBB, I think the logical course of action for a download automating tool (Tor Browser Launcher) is also using the default download.
I enjoy that there is some testing of the ("more") alpha bundles before I get it presented as the "more stabilized but still alpha" bundles - even though all anonymity tools are in their overall nature still alpha.
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.
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
Thanks for all this feedback!
On 02/19/2013 02:56 PM, Jacob Appelbaum wrote:
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.
I'm now using os.uname(). This seems like the right way to do it.
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.
I opened a new bug for handling empty HOME env variable:
https://github.com/micahflee/torbrowser-launcher/issues/15
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.
I didn't know about libtarfile. That seems like a much better solution. I opened a bug for that too:
https://github.com/micahflee/torbrowser-launcher/issues/14
If you want to git pull, I've made it so everything just automatically starts now, rather than waiting for the user to press the Start button. The only exception is if the signature verification fails, this still gives the user a choice.
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.
-
adrelanos -
Douglas Lucas -
Jacob Appelbaum -
k e bera -
krugar -
Leo Unglaub -
Micah Lee