October 2014 - tbb-dev - lists.torproject.org

Tor Messenger and Certificates
by Sukhbir Singh 01 Dec '14

01 Dec '14

Hi list, We are thinking of including certificates for OFTC, CCC, etc. with Tor Messenger, since some of these popular chat servers use self-signed certificates. Quick questions about this: - Is this a good idea -- including these certificates by default? Or should we let the users click on "add exception" and then add the certificates themselves? - What is a good way of achieving this (adding these certificates) as part of the build process? I can't seem to find a "proper" way and documentation seems to be lacking. I think we have to update cert8.db as part of the default profile, but I was wondering if there is some documentation or a preferred way of doing this. Thanks, -- Sukhbir

5 7

TBB design doc updated for 4.0
by Mike Perry 07 Nov '14

07 Nov '14

Hello all, I've finally updated the design doc to cover TBB 4.0: https://www.torproject.org/projects/torbrowser/design/ In particular, the fingerprinting section saw substantial updates: https://www.torproject.org/projects/torbrowser/design/#fingerprinting-linka… I also added a build security section that could probably use more links and more details: https://www.torproject.org/projects/torbrowser/design/#BuildSecurity Feedback welcome! Patches are even more welcomer! ;) The source repo lives at: https://gitweb.torproject.org/tor-browser-spec.git/tree/refs/heads/master:/… -- Mike Perry

3 5

Two small patches against gitian-builder
by Lunar 07 Nov '14

07 Nov '14

Hi! Attached are two small improvements to gitian-builder. Hope that helps, -- Lunar <lunar(a)torproject.org>

2 1

Https Everywhere and custom rules
by Karel Bílek 04 Nov '14

04 Nov '14

Hello, sorry if I am posting it to a wrong place, but it seemed like the perfect one. I am using Chromium with "HTTPS Everywhere" and I love how easy is to add a new website rules there. I just click on the icon and basically click on "add". I am now trying Tor Browser, and it's more difficult by several factors. I have to go to a certain folder inside the very complicated Tor Browser folder, find one that seems like the correct one, manually (!) write XML rules, restart Tor browser, and hope that it works and that the next Tor Browser update won't delete everything. I realize that it's technically a fault of HTTPS Everywhere for Firefox, not you, but it's a giant usability letdown. Are there any plans to fix that, either in HTTPS Everywhere for Firefox itself or separately inside Tor Browser bundle? Karel

2 1

Need review for Tor Browser theming patch integration #10399
by Martin Häcker 30 Oct '14

30 Oct '14

Hello List, for Bug #10399: Tor Browser should be visually distinguished from Firefox to prevent user error. (e.g. accidentally entering deanonymizing information into Firefox which should go into Tor Browser or the other way around, when used side by side) https://trac.torproject.org/projects/tor/ticket/10399 I recently got a patch to integrate a theme to the point where I would really like some feedback about it and the way I integrated it into the build process. Specifically I'm seeking feedback about how I integrated the plugin that actually implements the theme into the build process. This is unfinished, as of yet, by being only integrated into the mac build process - as I can test that natively. Is the integration the way this is supposed to be? Is that the way to also implement this for the other platforms? If possible I would like to defer the discussion how the theme that is finally chosen should look like. For testing I included a theme that tries to be somewhat similar to the Tor website. BUT: I consider that a placeholder, @saint already created some alternative themes: http://imgur.com/a/qn6Ih This is implemented as a plugin that activates a lightweight theme (also known as Persona) so it is very easy to create such a theme, and all of the exiting firefox personas can be used if wanted. (https://addons.mozilla.org/en-US/firefox/themes/?sort=popular) So what do you guys think of the way I integrated the theme into the build process? Is that how it's supposed to be? Should that work differently? Should I continue to build the integration for the other platforms the same way? Many thanks, Martin Häcker

1 0

TBB in Tails: Release timing in general
by anonym 23 Oct '14

23 Oct '14

Hi, For years Tails has shipped with an Iceweasel with the (relevant) Tor Browser patches applied. It has worked ok, but it's been high maintenance, and keeping the preferences synced with TBB was a bit of a chore, among other issues. Since Tails 1.2 we've migrated to installing the Tor Browser from the actual (32-bit Linux) TBB tarballs you distribute. We're very much interested in your comments on how we do this, so please have look at our design page: [1] [1] https://tails.boum.org/contribute/design/#index40h3 The main source of *potential* issues this has introduced is the added dependency on the timing of your TBB releases (rather, when the tarballs are made available). We aim at releasing Tails with a browser based on Firefox X.Y.Zesr on the same day as Mozilla officially releases it, i.e. every sixth Tuesday. Due to the time required for Tails' release process (including QA) that means that we need the final TBB tarballs based on that Firefox release *at the very latest* 24 hours before the planned Tails release. Just to get an idea, let's have a look at TBB's release history. Below I'll list the last -buildX tag for a given TBB release that upgrades to a new Firefox ESR (but I'm skipping exceptions outside the 6-week cycle) and the timing of when the tag was made vs the "ideal" time of a Tails release, which we say is at 18:00:00 (UTC) on the Firefox ESR (official) release day. Just to be clear, a high timing value is good for Tails. TBB release tag Tag date (UTC) Timing vs ideal Tails release tbb-4.0-build1 2014-10-13 17:34:22 +24 hours tbb-3.6.5-build1 2014-09-01 05:48:33 +36 hours tbb-3.6.3-build1 2014-07-24 08:58:10 -39 hours tbb-3.6.2-build6 2014-06-11 13:30:06 -19 hours tbb-3.6.1-build1 2014-05-06 12:19:26 -138 hours tbb-3.5.3-build1 2014-03-17 23:05:35 +19 hours tbb-3.5.2-build5 2014-02-07 18:14:41 -72 hours So, now we assume that the "Tag date" above also is the time when the tarballs are made available for download (and preferable announced on tor-qa@). Given that we want at least a +24 hours, this history doesn't look super promising for our (Tails') plans. I'm not sure the above assumption is very sound, though; for instance, the initial 4.0 tarballs (before the rebuild for POODLE but we're ignoring such exceptions) was announced on tor-qa@ on 2014-10-13 10:19:08 (UTC), which was 7 hours before the tbb-4.0-build1 tag. In any case it's true that if Tails had migrated to using the TBB in the beginning of 2014, we'd have trouble with several of our releases due to late TBB rebuilds. Of course, I'm not complaining that you have misbehaved. :) So far you haven't been working as an upstream for other projects so that they get a time window to include TBB and then do a same-day releases with you, e.g. like how Mozilla is an upstream to you, and was an upstream for Tails prior to our TBB-migration. However, do you think you can become such an upstream for Tails by trying to provide the time window detailed above? If you believe that window is too narrow, I suppose Tails could drop the "same-day release" goal and adopt a "day-after release" goal or possible even later. What do you think is possible? How can we help? To get a more concrete understanding of what exactly I'm proposing, let's use the next Tails release, 1.2.1, as an example: It's aimed to be released at 2014-11-25 18:00:00 (UTC), the same day as Firefox 31.3.0esr will be officially released. We'd need the (final) TBB (32-bit Linux) tarballs based on that Firefox version at the latest 24 hours before that, i.e. 2014-11-24 18:00:00 (UTC). Does that seem reasonable? I'm actually genuinely interested in an answer to this specific question, since I'm writing the Tails 1.2.1 release schedule as we speak and may have to adjust it if this turns out difficult for you to "promise". Cheers!

2 3

Tor Browser updater behavior
by Mark Smith 11 Oct '14

11 Oct '14

I want to share a couple of updater-related things with everyone: 1) There is a minor user experience change in ESR31-based browsers: an update check is performed as soon as the about dialog is opened (there is no longer a need to click a "Check for Update" button). I think this is OK. With the preference settings that we ship with, users will then be told if an update is available and then they will need to click a button to download and install it. 2) Once someone is on a particular update channel, they will stay on that channel unless they download a new browser package (outside of the update process) that is built for a different channel. We could modify code to change this behavior, but it is what Mozilla does and I think it makes sense (MAR file generation skips the files defaults/prefs/channel-prefs.js and update-settings.ini). This means that when we release 4.0 (which will be on the "release" update channel) we could, if we want to, also upgrade alpha users to that same set of builds. Then, as soon as we deliver a new alpha release, we can upgrade only those users who were and remain on the alpha channel to the new alpha. -- Mark Smith Pearl Crescent http://pearlcrescent.com/

1 0

TBB 3.6.6 and self-signed certificates
by Bram de Boer 08 Oct '14

08 Oct '14

Hello, I am having trouble using TBB 3.6.6 to connect to a website that uses a self-signed certificate. In the previous 3.6.5 version I was presented the usual warning, but after double checking the certificate fingerprint I could click the [Confirm Security Exception] button and TorBrowser would connect. However, in the 3.6.6 version after I click the [Confirm Security Exception] button, the dialog window disappears, a spinner is shown and TorBrowser starts trying to connect. However the page will never load. I have searched the preferences panel but could not find any option that might be useful. I read that 3.6.6 contained some changes with respect to saving intermediate certificates to disk. Could it be this has affected the use of self-signed certificates? Any suggestion? Thanks, Bram

3 8

problem with ESR31 TB build (binutils/gold)
by Mark Smith 06 Oct '14

06 Oct '14

I am trying to build an ESR31-based Tor Browser bundle via gitian. The error below occurs while building the gold linker. Has anyone else seen this? I am building on an Ubuntu 14.04 LTS system using KVM. -Mark g++ -DHAVE_CONFIG_H -I. -I. -I./../include -I./../elfcpp -DLOCALEDIR="\"/home/ubuntu/install/binutils/share/locale\"" -DBINDIR="\"/home/ubuntu/install/binutils/bin\"" -DTOOLBINDIR="\"/home/ubuntu/install/binutils/i686-pc-linux-gnu/bin\"" -DTOOLLIBDIR="\"/home/ubuntu/install/binutils/i686-pc-linux-gnu/lib\"" -W -Wall -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=archive.o -g -O2 -MT archive.o -MD -MP -MF .deps/archive.Tpo -c -o archive.o archive.cc In file included from /usr/include/c++/4.6/ext/hash_map:61:0, from system.h:92, from gold.h:35, from archive.cc:24: /usr/include/c++/4.6/backward/backward_warning.h:33:2: error: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Werror=cpp] cc1plus: all warnings being treated as errors make[2]: *** [archive.o] Error 1 make[2]: Leaving directory `/home/ubuntu/build/binutils-2.24/gold' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ubuntu/build/binutils-2.24/gold' make: *** [all] Error 2

2 3

TBB in Tails 1.2: Release timing with TBB 4.0 release?
by anonym 06 Oct '14

06 Oct '14

Hi, Recently we've decided to migrate Tails' browser from our home-built Iceweasel (with all relevant Tor Browser patches applied), to the actual TBB (i.e. fetch and extract your TBB tarballs (plural because we want all langpacks), then do some Tails-specific configuration) [1]. Tails 1.2, currently scheduled to be *built* on 2014-10-15, is planned to be the first Tails release with this change. Work is already on the way in the feature/tor-browser-bundle branch in Tails' Git [2]. As I believe it's in everyone's interest that Tails uses the TBB, and does so in the right way, I'm going to send an RFC detailing how we do this later. However, right now there's a more pressing issue, namely the timing of your release vs ours. Quite simply put, do you think that an esr31-based TBB 4.0 worthy to be shipped in Tails 1.2 will be out on 2014-10-15? Cheers! [1] https://labs.riseup.net/code/issues/7953 [2] http://git.tails.boum.org/tails/log/?h=feature/tor-browser-bundle

3 2