November 2015 - tbb-dev - lists.torproject.org

Using topic branches for Tor Browser patches
by Nicolas Vigier 14 Dec '15

14 Dec '15

Hello, Currently on tor-browser.git, each Tor Browser release has a single branch that includes all our patches. This is simple, however it makes it difficult to test each patch individually, and see which patch is responsible for which test failure. For instance, the patch to add preference overrides causes many tests to fail, probably because many tests don't expect the default preferences to change: 31.7.0esr pass all tests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5bbe47119ac0 31.7.0esr + preference overrides patch fails many tests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=fdc349fbbf5f After discussing about this quickly with intrigeri last week, I have been thinking about a different way to organize the patches: maybe we could use one branch for each topic, and merge all those branches in a single branch when we prepare the release. The naming of the branches could be: - ${firefox_version}/base: the commit for the firefox version we are using. - ${firefox_version}/${topic_name}: A branch containing patch(es) on a specific topic. $topic_name can be a bug number and/or a short description. We can submit those branches to Mozilla Try to see if they break some unit tests. - ${firefox_version}/${tbb_version}/${topic_name}: The same as the previous one, but for a topic that we only want to include in a specific Tor Browser version. - tor-browser-${firefox_version}-${tbb_version}-1: The branch that we use to build Tor Browser. This branch is based on ${firefox_version}/base, and includes merges of all branches matching ${firefox_version}/[^/]* or ${firefox_version}/${tbb_version}/[^/]*. As an exemple, I have converted a few patches from tor-browser-31.7.0esr-4.5-1 to this new naming in this git repository: https://github.com/boklm/gecko-dev/branches/all With all topic branches merged to this tor-browser-31.7.0esr-4.5-1 branch: https://github.com/boklm/gecko-dev/commits/tor-browser-31.7.0esr-4.5-1 I also started submitting some of them to Mozilla Try: 31.7.0esr/2874-Block-Components.interfaces-from-content: https://treeherder.mozilla.org/#/jobs?repo=try&revision=91cd13cf0ac7 (some mochitest tests failing) 31.7.0esr/2950-Make-Permissions-Manager-memory-only: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3f8cb0c1984e (tbb-tests/browser_tor_bug2950.js failing) 31.7.0esr/2949-Make-Intermediate-Cert-Store-memory-only: https://treeherder.mozilla.org/#/jobs?repo=try&revision=139538724d04 (no test failing) 31.7.0esr/3547-Block-all-plugins-except-flash: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c75fb4685994 (some xpcshell, mochitest, mochitest-chrome, reftest failing) 31.7.0esr/3229-Make-content-pref-service-memory-only-clearable: https://treeherder.mozilla.org/#/jobs?repo=try&revision=344873ae1513 (1 xpcshell test failing) 31.7.0esr/TB2-Provide-an-observer-event-to-close-persistent-connections: https://treeherder.mozilla.org/#/jobs?repo=try&revision=93af45d5111a (no test failing) 31.7.0esr/2875-Limit-device-and-system-specific-CSS-Media-Queries: https://treeherder.mozilla.org/#/jobs?repo=try&revision=32244f089736 (still running at the moment) 31.7.0esr/2872-Limit-the-number-of-fonts-per-document: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4abfb45bba86 (still running at the moment) We could also have some helpers scripts to make management of all those branches easier: - a script to merge / list all topic branches that have not yet been merged into their tor-browser-${firefox_version}-${tbb_version}-1 branch. - a script to push / list all branches that need to be pushed for a firefox or tbb version to a remote git repository. - a script to rebase all patches from a previous firefox version to a new firefox version. What do you think about this idea ? Nicolas

1 7

Fwd: [tor-project] UX Mailing List Announcement
by Nima Fatemi 28 Nov '15

28 Nov '15

FYI. Because this wouldn't mean anything without having Tor Browser devs on board :) PS: Sorry if you've gotten this email too many times. There have been some people overlapping on lists... -- Nima -------- Forwarded Message -------- Subject: [tor-project] UX Mailing List Announcement Date: Sat, 28 Nov 2015 03:41:17 +0000 From: Nima Fatemi <nima(a)torproject.org> Reply-To: tor-project(a)lists.torproject.org To: tor-project(a)lists.torproject.org Hello friends, I'm writing this email to let you know we've just created a new mailing list at Tor Project, for discussions about the user experience of various products at Tor. This mailing list was one of the outcomes of our initial UX team meeting on Nov 16th, which took place on #tor-project IRC channel. This list is going to be a place for UX researchers, designers, developers and whoever else who cares about the usability of security software. Please feel free to subscribe and/or invite whoever you think might be interested. https://lists.torproject.org/cgi-bin/mailman/listinfo/ux Sometime next week I will send an email about upcoming meetings and we can work together to see how we can move this team forward, together. Your involvement is strongly encouraged. Best, -- Nima 0XC009DB191C92A77B | @mrphs "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall

1 0

Missing IRC meeting today
by Nicolas Vigier 17 Nov '15

17 Nov '15

Hi, As I'm a little sick today, in addition to being very tired after not enough sleep and spending too much time reading about depressing things in the last 3 days, I think I will be missing the meeting today and try to sleep early instead. Next days should be better. During this week I'm planning to work on #16009 (moving away from Mozmill to Marionette), and try to write a PoC extension that cause the same crash as mozmill on the ASAN build, to be able to reopen the Mozilla bug[1] with more details. Nicolas [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1223302

2 2

weekly status report
by Mark Smith 02 Nov '15

02 Nov '15

Unfortunately, Kathy and I will miss today's Tor Browser team meeting due to a conflict. Here is the our status report: This past week, Kathy and I created a new patch for #16620 ("Transform window.name handling into Firefox patch") that closely mimics the behavior of the old JavaScript implementation. We then revised it again (and added another automated test case) after Georg found a problem. The fix made it into 5.5a4 at the last minute. A big "thank you" to Georg and Arthur for their reviews. We also completed some code reviews in support of the pending Tor Browser releases. We filed #17442 ("adjust or remove updater cert pinning"). We need feedback; please comment in the ticket. This week, we plan to start working on these tasks: - Review patch for #9659 "Optimistic Data SOCKS variant leads to loop" - #16940 "Load (only) local change notes after a Tor Browser update" - #17344 "language prompt should enumerate available langpacks" - #17313 "Crash in Canvas patch seen on OS X Tor Browser" We will also help with any issues that arise with the releases that are planned for this week. -- Mark Smith Pearl Crescent, LLC http://pearlcrescent.com/

1 0

Memory Allocator #10281 write-up
by Tom Ritter 02 Nov '15

02 Nov '15

Firefox has a feature where you can build a memory allocator library and shim it into Firefox - this is called building a memory replacement library. It requires an additional build-time configuration option. Our first investigation was with PartitionAlloc being built as a memory replacement library. This mostly worked, except we could not replicate the implementation of memalign, which required editing the core internals of PartitionAlloc. It's also important to note that our use of PartitionAlloc did not actually partition the allocations based on any intelligent design. This is an ongoing problem. Currently, when Firefox performs an allocation, it will snake its way through the layers of abstraction until it arrives at our replacement library. The only information that has been passed into our replacement library is the size of the allocation. We do not have any context about what the allocation is for, and therefore which partition we would like to place it in. (We theorized about walking the call stack in assembly and binning allocation based on that but this was an untested idea.) The work with PartitionAlloc paused. After some time, Firefox began investigating partitioning allocations using jemalloc3's partitioning capabilities. jemalloc3 is a new version of the currently used allocator, jemalloc. Mozilla's migration process is first to move to jemalloc3, and then to start partitioning allocations. Currently, their move to jemalloc3 is paused because <actually I'm not entirely sure why. I think "performance" and "mobile".> However the code for jemalloc3 is present, and making use of it is only a configuration change away. jemalloc3 solves one of the problems of PartitionAlloc - the allocator actually, completely works. Mostly. There is at least one issue which I believe is <an outstanding bug in jemalloc causing mismatched VirtualAlloc/Free calls - but this may be fixed now>. We did some performance comparisons of jemalloc vs jemalloc3 and it was reasonable: http://imgur.com/a/A6TV9 To actually partition allocations we can implement a replace library that makes use of jemalloc3's partitioning capabilities. But we run into the same problem as before - we don't have any context to know what partition to put an allocation into. One thought was that we could use memory tags, but after investigation, that did not seem feasible. We _can_ go through the Firefox codebase and change the allocation call to include an arena constant, but this patch will be difficult to maintain, we are likely to miss some allocation situations, and eventually Mozilla will do this themselves. References: https://lists.torproject.org/pipermail/tbb-dev/2015-May/000269.html was my most-recent message on this topic. It references a github issue that is now closed. The patch referenced below should not be needed if this patch solves Mozilla's issue. Does it? Was jemalloc's fix merged? Questions I don't know the answer to. https://lists.torproject.org/pipermail/tbb-dev/2015-May/000272.html Was my followup. Future Directions and Open Questions: - Do we have a clear picture on why mozilla isn't shipping jemalloc3? - Is the jemalloc3 code in ESR38 considered bug-free, or did the known github issue not get patched in it? - Is there concern over switching TBB's allocator over to jemalloc3? - Is there concern over enabling the replace-malloc switch in TBB? - If both of those are done, any TBB distribution can, at start-time, choose to use a randomizing allocator in the form of a replacement library. The beginnings of one is attached. The library does not need to be used by default, but can be included in every install.

2 1

Re: [tbb-dev] Bug 1205598 - Print preview doesn't honor Private Browsing Mode and writes to /tmp
by intrigeri 02 Nov '15

02 Nov '15

Hi there, I'd like to hear about your gut feeling on https://bugzilla.mozilla.org/show_bug.cgi?id=1205598 so that we can adjust the strategy we'll choose at Tails to deal with it: * Any clue what are the chances that Mozilla fixes it say, within 3-6 months? I see that the Private Browsing component has 175 open bugs, most of them unassigned, so I'm personally not very hopeful. * If it's hopeless to just wait for Mozilla, is it something you think the TBB dev team will want _and_ be able to work on any time soon, as a somewhat important violation of the TBB design goals? If yes, what would be a realistic ETA? Note that as far as Tails is concerned, honoring $TMPDIR would be good enough, even if it wouldn't fix the real PB bug. Perhaps just mentioning it here will somehow let our dear anonym come up with a patch, but this one seems quite harder, so let's not count on it :) [Internal tracking: this is about Tails bug #10141] Cheers, -- intrigeri

2 1

"Open with" vs. confinement of Tor Browser
by intrigeri 02 Nov '15

02 Nov '15

Hi, when we've started confining Tor Browser with AppArmor in Tails, we introduced a usability regression: when downloading a file, we let the user choose between "Save as" and "Open with", while we know that "Open with" will always fail. Note that we currently set extensions.torbutton.launch_warning to false, because the text in that warning dialog is no good fit for Tails. I see two main options: 1. Add an option to Tor Browser to never propose opening a downloaded file with an external application. I suspect this is quite involved, and probably not worth the effort. But you know the codebase, and I don't, so I'm all ears :) 2. Display a custom pre-download dialog that makes users aware of the limitations ("the next dialog window lies ⇒ don't even try choosing 'Open with'") E.g. set extensions.torbutton.launch_warning back to true, and patch the torbutton.popup.external.* strings to tell users that "Open with" won't work. Can we do that ourselves without modifying Torbutton? If not, could we add a pref (off by default) that uses alternate strings when turned on? I guess we can provide a patch, and have the strings go through our own tech writers / UX people, if you think it's acceptable. 3. Other ideas? [JFTR this is about Tails ticket #9285.] Cheers, -- intrigeri

3 4