- tbb-dev - lists.torproject.org

Ubuntu 14.04, LXC, and TBB builds
by Mark Smith 10 Jun '14

10 Jun '14

Has anyone succeeded in building TBB on an Ubuntu 14.04 system using LXC? It seems like gbuild is not working correctly. But before I did deeper, I thought I would ask here in case someone else has already solved the problem I encountered. What I see if that commands such as the following (from gbuild) do not receive the input from stdin, so they hang waiting for input: system! "on-target setarch #{@arches[arch]} bash < target-bin/init-build.sh" Maybe lxc-start has been changed to re-attach stdin somewhere else? I don't know. -- Mark Smith Pearl Crescent, LLC http://pearlcrescent.com/

1 0

Bug 1506
by Arthur D. Edelstein 02 Jun '14

02 Jun '14

Hi All, I noticed a lot of references in torbutton.git to Bug 1506, with a P0, P1, P2, etc. I looked at https://trac.torproject.org/1506, but it isn't clear to me what these P-numbers refer to. Am I looking in the wrong place? In any case, four of the files, window-mapper.js torRefSpoofer.js tor-protocol.js tors-protocol.js have a first line with a comment like: > // Bug 1506 P0: This code is toggle-mode code and is unused. Kill it. and they seem to have been commented out from chrome.manifest as well. So should these files be removed? If so, I can write a patch. Also, "Bug 1506 P0" is mentioned with liberal uses of the word "Kill" in torbutton.js at the top of three functions. Should these functions be removed as well? Thanks, Arthur

1 1

jshooks?
by Arthur D. Edelstein 02 Jun '14

02 Jun '14

Hi All, I'm developing a patch for https://trac.torproject.org/5926, to stop the JavaScript Date object from leaking locale information. I was patching tor-browser.git C++ code, but then I noticed two files in torbutton, jshooks.js and jshooks4.js: https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/j… https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/j… These files seem to be relevant to the patch, and I have some questions about them: 1. In jshooks.js, the series of lines that re-define the window.Date prototype, as controlled by line 72, `if(window.__tb_hook_date == true)`, is never called, as far as I can tell, because __tb_hook_date is never defined. Indeed, if that code were called, then the bug I'm working on would already be mostly fixed. Is there a reason this section of jshooks.js is being retained? Should it be re-activated or is it better for me to continue with a C++ patch? 2. jshooks4.js doesn't seem to be in use at all. Is that correct? Would it make sense to remove this file from the master branch? 3. In general, what's the approach for deciding whether to patch Mozilla C++ code vs torbutton JS code for anti-fingerprinting and similar bugs? I understand there is a desire to move more toward C++, but I'm not sure what the overall plan is. Thanks for any insight! Arthur

3 3

Current thoughts on tb-manual presentation
by Matt Pagan 30 May '14

30 May '14

Hello tbb-devs. Here are a few divergent thoughts on presenting the Tor Browser manual in a sensible manner for Tor Browser users. Please provide feedback regarding whether any of these seem reasonable/feasible. &&&&&& 0) Include a pdf file in an easy to locate place in the Tor Browser directory. Con: As discussed a couble IRC meetings ago, the major obstacle here is that most Mac users do not know how to turn their Tor Browser app into a directory, and so they would never see it. Not so good. 1) Replace the help desk email label in tor-launcher with a button, which, when clicked, tells the user's system to open a local pdf file with the system's default pdf viewer. A con to this approach is that I don't know if it is even possible at all; that is, I'm not sure if JS is capable of detecting what the default application for a filetype is or, if it's not, I'm not sure it's capable of just "opening a file" that needs to be opened with a specific, local application. 2) The same as 1) but ship evince with Tor Browser and onClick, open a pdf file with something like an `evince tb-manual.pdf` command. A con to this approach would be that this might not work at all for various non-Gnome GNU/Linux users. Also the Tor Browser is that much bigger. 3) Replace the help desk email label in tor-launcher with a button, which, when clicked, opens a XUL window (like window.open) that contains nothing but an iFrame which loads the the local index.html file (from which the user can then navigate to all the other html pages because of the manual's design) con: ??. This seems like a pretty possible thing to do right now. Is it? I could not actually get my implementation of this idea even close to working, but I also introduced a lot of new moving parts at once, and I'm still getting the hang of debugging. This seems like it would be the most user-friendly workflow of these various approaches. 4) Make the Tor Browser manual prominently available for download on the Tor Browser download page as a pdf. cons: Now users have two things to verify to make sure they didn't just download malware. Who's really going to do that for a pdf file, anyway? I think most users are quite used to a download being one thing, and not two (or three). I'm not sure it's reasonable to expect that all users will download a separate manual. This is not a great workflow. Users could just open the pdf file in the browser they used to download Tor Browser, though. 5) Direct users to https://tb-manual.torproject.org/, which weasel just set up. This could either be done from the download page or a non-wired link in tor-launcher. cons: I think fewer users would actually see the manual this way, and this distribution method would probably be less effective at reducing load on the help desk for similar reasons to 4). We've had the the Short User Manual on our web infrastructure for some time and most users do not know it exists. Although maybe that was an advertising problem? ****** I'm not a huge fan of 4) or 5), as they don't actually solve the problem of distributing a manual with Tor Browser. I've included them for completeness, nonetheless. Also there are probably ways of getting the tor browser manual in the hands of users that I'm not thinking of. Any other ideas? Do you like any of the above ideas? The relevant ticket here is https://trac.torproject.org/projects/tor/ticket/11698 -- Matt Pagan PGP: 0xE9284418E360583C

6 20

Looking at tor browser connections
by Nicolas Vigier 16 May '14

16 May '14

Hello, While discussing during the IRC meeting last friday about mbox integration in the tests suite to monitor connections made by the tor browser, we noticed that it opens 2 connections to the dns server, and 2 to the default tor socks port even when it is set to an other port with the TOR_SOCKS_PORT environment variable: https://people.torproject.org/~boklm/tmp/tests/r/4mrXwR46_6/tor-browser-lin… So I have been looking at why it is doing this. I have been looking at the browser source code to understand why it does a dns request to resolve the hostname of the machine, and found this: https://gitweb.torproject.org/tor-browser.git/blob/90a58a42063dcd56e2943565… Before starting the browser it wants to create a lock file in the profile directory, which is a symlink pointing to the IP of the machine, so this is probably the reason why it's doing a dns request. Adding the hostname in /etc/hosts fixed the problem. Or for distributions that use libnss_myhostname (such as Fedora 20), editing /etc/nsswitch.conf to move 'myhostname' first on the hosts line. For the connections on port 9150, here is how to reproduce it: $ tar xvf tor-browser-linux64-3.6.1_en-US.tar.xz $ cd tor-browser_en-US $ sed -i s/9150/9550/ Data/Tor/torrc-defaults $ export TOR_SOCKS_PORT=9550 $ ./start-tor-browser Running 'tcpdump -i lo port 9150' in an other shell at the same time shows some connections on this port. Looking with wireshark shows that it is a connection to check.torproject.org. It only happens with a new profile on the first run (when Data/Browser/profile.default/prefs.js has not been created yet). If I create a file Data/Browser/profile.default/prefs.js to define extensions.torbutton.socks_port, there is no connection to port 9150:

1 0

Tor Browser Weekly IRC meetings moved to 15:00 UTC Fridays
by Mike Perry 24 Apr '14

24 Apr '14

Due to the EU "Summer Time" changes generating new conflicts for a few people, the Tor Browser team's weekly IRC meeting will now be on Fridays at 15:00 UTC in #tor-dev on irc.oftc.net, starting this Friday, April 25th. For details on our meeting format, see the original post: https://lists.torproject.org/pipermail/tbb-dev/2014-February/000000.html -- Mike Perry

1 0

TBB versions file
by Nicolas Vigier 14 Apr '14

14 Apr '14

Hello, We now have some automated tests run on TBB nightly builds, and also on new releases: https://people.torproject.org/~boklm/tbbtests/ For the new releases, the script needs to know the version number of that release to be able to download it. Currently, I am updating the version number in this file when there is a new one to be tested: https://gitweb.torproject.org/boklm/tor-browser-bundle-testsuite.git/blob/H… However, I think that maybe we should have a file somewhere on a git repository, where we write the version number of a new release that needs to be tested. This versions file could be also used by an other script to trigger new builds. So in addition to version numbers it can contain a commit hash, and build type (the makefile rule we need to use: normal build, beta or alpha). Later we can think about using it for other things too: upload of new versions to mirrors, removal of old versions, website update, update of recommended version file, etc ... I am thinking about a yaml file that look like this: ---- tbbversions: 3.5.4: type: release build_commit: ada623c4cbc145521980e6bce08611cff7e81cad 3.6-beta-2: type: beta build_commit: ada623c4cbc145521980e6bce08611cff7e81cad ---- We can put this file in a git repository where all commits are signed (with git commit -S), and the scripts that use it check the signatures when pulling (with git pull --verify-signatures). We can use something like this to do that: https://gitweb.torproject.org/boklm/tor-browser-bundle-testsuite.git/blob/H… Then it would work like this: - a script check this version file, and if there is a new version defined in the file that has not been built yet, starts a new build, and upload it to people.torproject.org if the build is successful. - the script that run automated tests check this version file, and when a version defined in this file is available from at least two builders on people.torproject.org, starts running the tests. What do you think about this ?

2 3

Plan for new TBBs re Openssl bug?
by Roger Dingledine 07 Apr '14

07 Apr '14

https://www.openssl.org/news/vulnerabilities.html#2014-0160 http://heartbleed.com/ Is TBB affected? Is there a plan for an update? --Roger

3 3

Tor unexpectedly exited
by Matt Pagan 29 Mar '14

29 Mar '14

Even though I missed the IRC meeting today (sorry), I wanted to share that there has been a noticeable increase lately in support requests regarding a "Tor unexpectedly exited. Please restart the application." message. Users will get this message over and over when trying to start their Tor Browser. At least some of these folks are already familiar with Tor Browser ("It worked fine before"). As a response, we will usually tell users to delete their current Tor Browser and download the Tor Browser again, which seems to usually clear up the issue. I have not opened a new ticket for this issue. -- Matt Pagan matt(a)pagan.io PGP: 0xE9284418E360583C

2 2

Tor Browser version strategy
by Mark Smith 26 Mar '14

26 Mar '14

Radical proposal of the day: Can we use the Firefox major version number in the Tor Browser version? This would mean that TBB versions would be 24.0, 24.1, 24.1.1, etc. Why consider making this change? Because doing so would allow us to greatly simplify the patches needed for bug #4234 (Use Firefox updater). For the Firefox updater to work correctly, it needs to be able to check the version of an advertised update against the version of the software that is currently installed. At the same time, for add-on compatibility the browser version itself must be close to that of the Firefox release it is based on. We already have patches for #4234 that modify our Firefox build process to pass the TBB version through and use it inside all of the updater-related code (and to use the 24.x Firefox version when we need to do so). However, the patches are messy and I don't think Mozilla could ever accept them; Mozilla has no need for a bundle version that is separate from the Firefox version. If we used a version number for TBB that was close to the Firefox version number, we would not need to patch anything; we would just use our version number as THE version number. Doing this would also allow us to eliminate the torbrowser.version hidden preference. And it might help end-users who want to figure out what version of Firefox the Tor Browser is based on. -- Mark Smith Pearl Crescent http://pearlcrescent.com/

4 7