tbb-dev June 2019

tbb-dev@lists.torproject.org

5 participants
4 discussions

Nightly rebase experiment proposal
by Arthur D. Edelstein 03 Feb '20

03 Feb '20

Hi everyone, Here's a plan for experimenting with moving Tor Browser from ESRs to mozilla-central. Why try this? There are several reasons I can think of: * There is no mobile Firefox ESR. In order to keep mobile Tor Browser secure, we would either need to constantly monitor for security fixes and apply backports. It will be simpler to follow the Mozilla release cycle. * Tor Browser will receive all security patches and security features from Mozilla, not simply those deemed important enough to backport to the last ESR. * Closer collaboration between Mozilla and the Tor Browser team will be possible, because everyone will be focused on the same codebase. For example, non-urgent patches can land directly on mozilla-central, bypassing tor-browser.git altogether, and those patches will be deployed to Tor Browser faster than they would have been on an ESR-only schedule. Mozilla will provide expert review of patches. Also, some non-urgent patches by Tor Browser may be written by Mozilla engineers. * The Tor Browser development process will be smoother and more gradual. Instead of rebasing and patch-fixing sprints ahead of each ESR, we can automatically rebase patches every night, and fix any patch whenever its rebase fails. (The total rebase effort should be approximately the same as before.) * Patches that frequently break because they live on "hot code" can be identified and uplifted. * We'll need to continuously monitor the mozilla codebase for new features that could harm privacy. That's potentially difficult, but by focusing on Mozilla's current work, we can hopefully stop patches that affect privacy before they land. Here's how I envision the new rebase process: * An automated script rebases all tor browser patches every night against mozilla-central, mozilla-beta, mozilla-stable and mozilla-esr. An email alert will be sent if the rebase of any patch fails. (I have a prototype script that does the basic rebasing -- it found that ~40/140 patches from our ESR-52 branch could be auto-rebased onto mozilla-central without any intervention.) * Any failed patches will need to be manually fixed up promptly so that the automated rebase can resume. * Diagnostic Tor Browser bundles will be built against the latest rebase branches. We can also run regression tests. So how do we ramp up this experiment? 1. 2018-1-1 to 2017-2-22: Rebase tor-browser.git patches manually on top of Firefox 59-beta. (We have to do this anyway.) 2. 2017-2-22 to 2018-3-13: Activate a script that rebases Tor Browser patches nightly onto mozilla-(central, beta, stable, esr). 3. 2018-03-13 to 2018-05-07: Create nightly Tor Browser bundle builds based on nightly rebases. At this point, we can evaluate whether we would like to transition to releasing Tor Browser alphas based on the mozilla-beta branch. Switching Tor Browser stable to mozilla-stable can happen sometime after that. How does this sound? Interested to hear what you think. Thanks, Arthur

7 12

Debugging/Seeing the trace of an execution of WebGL code
by Rishabh Raj 26 Jun '19

26 Jun '19

Hello everyone, I am working on making some changes to the WebGL part of Tor Browser's source code. But each WebGL API goes through multiple files and functions in the browser's source code. So, before I can start changing them, I would need to know how exactly the transfer of data takes place. To be more clear, I start with a program which draws a rectangle (vertices have different colors, so interpolation takes place). Take for example the function `bufferData()`, which sends the data to the GPU. Once the shader code or vertices/indices data is sent to the GPU, I am helpless, isn't it? I need to be able to hook before this and analyze the various function calls in different source code files and the data parameters that are circulating through (of course it is not just one API, but a whole bunch of JavaScript API's that have to be executed before something is drawn). So, how do I figure this out? Initially, I had tried using a bunch of fprintf's, but I always get lost after, say `fBufferData()` [I noticed that many `API()` end up with `fAPI()` in the source code]. In addition, I couldn't figure out when the ANGLE part comes into the picture since I tried putting fprintf's in there as well, but nothing got printed. Basically I am trying to find the right place to hook, just after all calculations on the data are done and before the control is sent to the GPU. So, do I have to attach a debugger, say gdb, to a running instance of tor-browser (incidentally, there are three processes that commence when tor browser is run). Basically, I need some help figuring out how to put all of this together. I would really appreciate if you could provide me with some suggestions. Warm Regards, Rishabh

2 2

proposal for #10760 (Integrate TorButton to TorBrowser core ...)
by Alex Catarineu 13 Jun '19

13 Jun '19

A draft proposal for #10760 (Integrate TorButton to TorBrowser core to prevent users from disabling it) is attached. This should already address some review comments in https://trac.torproject.org/projects/tor/ticket/10760#comment:36. Feedback appreciated! -- Alex Catarineu Tor Browser Developer acat at torproject dot org gpg 3F5B D76C 2C9B D09B F4A8 0AB0 75DC D26C 3A21 2E9A

2 3

TargetPrincipalDoesNotMatch message from postMessage in JS Console even though target / recipient origins match.
by Dan Bryant 12 Jun '19

12 Jun '19

Is this an intentional veto of the windows.postMessage API? Understandable if it is, but I failed to see where it was implemented or how to override it (to re-enable postMessage). This error shows up when trying to use the TREZOR cryptocurrency wallet on https://www.MyCrypto.com (a popular ethereum wallet). The problem arises when www.mycrypto.com tries to authorize through connect.trezor.io. The authorization is performed through window.postMessage communication channel. The text of the error in the JS Console is obviously the TargetPrincipalDoesNotMatch message (ref1, line 249). There is only one spot that this message is presented in the postMessage workflow (ref2, line 128). This is only called in a failed equality check, which, according to the message text, shouldn't have failed (ref3). Since all origins mentioned match "https://connect.trezor.io" I'm curious as to why the equality check (ref3, line 96) would have failed. Anyway, I'll be happy to open this as a ticket, I just didn't know if this was a known exclusion that is somehow setup upstream of this call. ## JS Console Message --- Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘https://connect.trezor.io’) does not match the recipient window’s origin (‘https://connect.trezor.io’). --- ## Reference git: https://gitweb.torproject.org/tor-browser.git branch: tor-browser-60.7.0esr-8.5-1 ref1: /dom/locales/en-US/chrome/dom/dom.properties : 249 ref2: /dom/base/PostMessageEvent.cpp?h=tor-browser-60.7.0esr-8.5-1 : 128 ref3: /dom/base/PostMessageEvent.cpp?h=tor-browser-60.7.0esr-8.5-1 : 96

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev June 2019