December 2017 - tbb-dev - lists.torproject.org

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 … [View More]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 [View Less]

7 12

Re: [tbb-dev] [tor-dev] RFC: porting torbrowser (was: Re: GNU Guix and Tor Browser Packaging)
by ng0 09 Mar '18

09 Mar '18

Hi, It seems as if tbb-dev(a)lists.torproject.org is the list which would be more appropriate. If the 7 days without a reaction are simply due to the holidays in some countries, it's my mistake. If you need internal discussion about this to respond appropriately, let me know that you are reviewing this message at all. I have no expectation for "neoliberal optimized" reply times. Thanks. ng0 transcribed 7.9K bytes: > Hi folks, > > as your trademarks team / person suggested to me I … [View More]get in touch with the > dev team of torproject. While I'm more involved in GNUnet, I work at the > intersection of projects. Currently this means I'm involved in system > integration. At Guix we are interested in working closer with projects > like tor, TAILS, Whonix and the like. Porting torbrowser is not only in > the interest of the Guix community but also in the interest of Wonix who > recently expressed interest in selectively using Guix for their work. > For me as maintainer of the system (in development) pragmaOS it also > means that we can decide between icecat OR torless torbrowser for > proxied GNUnet connections. > > I'm interested in your response to the actions listed below and wether > you think this will still qualify as torbrowser or what other option you > propose for us at Guix to use. "Option" here means that I am not sure > what other graphical theme you have for versions of the browser which do > not use the trademark when they can (logically) also not use the firefox > trademarks. > I would reflect in the description of the package that it is not > torbrowser but a reconstruction of the way torbrowser is build, tracking > upstream as closely as possible while removing (list of features which > were removed goes here). > This can be compared to what the inoffical Gentoo maintainer does in the > .ebuild file here: > https://data.gpo.zugaina.org/torbrowser/www-client/torbrowser/ > > My request here is just in the position as a contributor to Guix, not > for pragmatique (the project which works on pragmaOS etc), Whonix, > GNUnet or any other project I mentioned before. > > Thanks in advance. Now the content I've been talking about: > > It looks like the changes I need to make to torbrowser are not so > grave at all. Someone pointed me to the gnu-linux-libre(a)nongnu.org list > to reach out to other FSDG systems. > The thread can be reviewed here: > https://lists.nongnu.org/archive/html/gnu-linux-libre/2017-03/msg00002.html > > Basically: > > I will need to discourage Mozilla leftovers: > - the mozilla addon service will be overwritten, in other words: > Where you would find https://addons.mozilla.org/ at "Preferences > AddOns" > it will be replaced by the thing Icecat points to. Longterm plan is > to offer firefox extensions native through "guix package -i > youraddonnamehere". > > Privacy / Tracking reasons: > - Firefox "Sync" will be disabled. > - Google will be removed from the search plugins if I understood the > procedure correctly (at least it is not in Icecat) > > A question directly for torbrowser team: > - about:license does not list licenses the torbrowser project uses, only > firefox. Why? > > DRM > - Luke from parabola mentioned that drm has been enabled in recent > versions of torbrowser. This needs to be removed aswell. > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/vendor.js#n23 > https://git.parabola.nu/abslibre.git/tree/libre/iceweasel/mozconfig#n39 > https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/fire… > > ng0 transcribed 3.4K bytes: > > bancfc(a)openmailbox.org transcribed 1.9K bytes: > > > There is a serious Tor Browser packaging effort [3][4] being done by ng0 > > > (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports > > > > Eh, now that the cat is out of the bag (cat's don't belong into bags > > anyway), I think I have to do this now and not on my own conditions. > > > > Hi! > > > > As I told bancfc somewhere else, I've had a short contact with the > > trademarks team of torproject. I will get back to you when someone was > > able to identify issues in torbrowser which might lead to modifications > > of torbrowser (for more details I just hope trademarks(a)tp.o can > > communicate it to you) because all packaged software which is included > > in upstream of Guix (master) must follow the GNU Free System > > Distribution Guidelines. > > I hope that I have to make as little modifications as possible as I > > I am aware that the fingerprint of the browser could change depending on > > the kind of changes. > > > > I hope to get back to this task in about 3 weeks, right now I'm busy > > with getting more documentation done for another project. > > > > > transactional upgrades and roll-backs, unprivileged package management, > > > per-user profiles and most importantly reproducible builds. I have checked > > > with Guix's upstream and they are working on making a binary mirror > > > available over a Tor Hidden Service. [2] Also planned is resilience [2] to > > > the attack outlined in the TUF threat model. [1] > > > > > > Back to the topic of Tor Browser packaging. While there are good reasons for > > > Debian's pakaging policies they make packaging of fast evolving software > > > (and especially with TBB's reliance on a opaque binary VM for builds) > > > impractial. Both we and Micah have been doing a good effort to automate > > > downloading and validating TBB but I still believe its a maintenance burden > > > and Guix may be a way out of that for Linux distros in general. > > > > > > What are your thoughts on this? > > > > > > > > > > > > > > > > > > *** > > > > > > [0] https://www.gnu.org/software/guix/ > > > [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md > > > [2] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00192.html > > > [3] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00189.html > > > [4] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00149.html > > > _______________________________________________ > > > tor-dev mailing list > > > tor-dev(a)lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > _______________________________________________ > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > -- > PGP and more: https://people.pragmatique.xyz/ng0/ > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- PGP and more: https://people.pragmatique.xyz/ng0/ [View Less]

4 8

Cloudflare's OPRFs
by Jeff Burdges 08 Jan '18

08 Jan '18

I wrote to the Taler list <taler(a)gnu.org> about certificate concerns with CloudFlare's OPRFs but never informed you guys. https://blog.cloudflare.com/privacy-pass-the-math/ I'll re-edit the relevant email from 10 Nov 2017 below: There are shades of a "bug door" in [CloudFlare's] no certificates arguments : - "The only thing edge to manage is a private scalar. No certificates." - The edge's public key xG is "posted publicly [similar] to a Certificate Transparency Log [and] "… [View More]

2 1

Fwd: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine
by Tom Ritter 23 Dec '17

23 Dec '17

---------- Forwarded message ---------- From: Sylvestre Ledru <sylvestre(a)mozilla.com> Date: 20 December 2017 at 09:42 Subject: Fwd: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine To: "dev-platform(a)lists.mozilla.org" <dev-platform(a)lists.mozilla.org>, mobile-firefox-dev <mobile-firefox-dev(a)mozilla.org> Hello, Earlier today, we announced on the enterprise ML several changes to ESR. First, as Dave Camp mentioned during the Firefox … [View More]All Hands, we are started some developments to improve our support for enterprise users. More information can be found on the wiki: https://wiki.mozilla.org/Firefox/EnterprisePolicies Second, we will branch ESR from 60 instead of 59. This will give us more time to work on the Enterprise policies. Also, In parallel, this means that we will have more time to delete old/dead code before branching. As a disguised advertisement, I am using this email to remind that Marco Castelluccio's tool https://marco-c.github.io/code-coverage-reports/ is your best friend to find dead code [1]. Last but not least, we also warned our enterprise users that ESR52.9 (EOL August 28th) will be the last release supporting legacy add-ons. The wiki and the ESR FAQ have been updated: https://wiki.mozilla.org/RapidRelease/Calendar https://www.mozilla.org/en-US/firefox/organizations/faq/ Sylvestre PS: Also, for people on these two MLs who are still using Windows XP, you'll get a few more weeks to update ;) [1] meta bug https://bugzilla.mozilla.org/show_bug.cgi?id=1415819 -------- Forwarded Message -------- Subject: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine Date: Wed, 20 Dec 2017 14:06:57 +0100 From: Sylvestre Ledru <sylvestre(a)mozilla.com> To: enterprise(a)mozilla.org <enterprise(a)mozilla.org> The Firefox ESR (extended support release) is based on an official release of Firefox desktop for use by organizations including schools, universities, businesses and others who need extended support for mass deployments. Since Firefox 10, ESR has grown in popularity and many large organizations rely on it to let their employees browse the Internet securely. We want to make customization of Firefox deployments simpler for system administrators and we’re pleased to announce that our next ESR version, Firefox 60, will include a policy engine that increases customization possibilities and integration into existing management systems. What is the policy engine? The Policy Engine is a project to build a Firefox desktop configuration and customization feature for enterprise users. The policy engine will work with any tool that wants to set policies and we intend to bring Windows Group Policy support soon. We’ll be initially supporting a limited set of policies but this will be evolving through user feedback. More details on the policy engine can be found here. <https://wiki.mozilla.org/Firefox/EnterprisePolicies> Bug reference <https://bugzilla.mozilla.org/show_bug.cgi?id=1419102> What’s the plan? In order to accommodate the group policy implementation, we are making Firefox 60 our next ESR version and will be following this plan: * May 8th - ESR 60.0 released (we’d love feedback from early adopters at that point and will be sharing a feedback form through the enterprise mailing list) * July 3rd - ESR 60.1 released * August 28th - End of life for ESR 52 and release of ESR 60.2.0. No further updates will be offered for ESR52 and an update to ESR60.0.2 will be provided through the application update service Also please keep in mind that Firefox 57, released last month, supports only add-ons built with theWebExtensions API <https://developer.mozilla.org/en-US/Add-ons/WebExtensions>. This means that Firefox 52 ESR is the last release that will support legacy add-ons. If you developed an add-on that has not been updated to the WebExtensions API, there is still time to do so.Documentation <https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Porting_a_legacy_…>is available, and you can ask questions by emailing dev-addons(a)mozilla.orgor joining the #webextensions channel atirc.mozilla.org <http://irc.mozilla.org>. If you are supporting users who use add-ons, now is a good time to encourage them tocheck if their add-on works <https://support.mozilla.org/en-US/kb/frequently-asked-questions-firefox-add…>with Firefox 57+. Erin, Felipe, Jeff, Kev, Mike Kaply, Romain, Shell & Sylvestre _______________________________________________ dev-platform mailing list dev-platform(a)lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform [View Less]

3 3

XUL Tor Launcher EOL?
by anonym 13 Dec '17

13 Dec '17

Hi, Basically, when do you plan to remove the XUL-based Tor Launcher from the stable Tor Browser series? Background: since Tails likely won't be able to switch to the WebExtension version easily [0], my hope is that you will continue to ship the XUL version throughout the 7.0-series, based on 52esr, and only switch to the WebExtension once Tor Browser is based on 59esr (which I suppose will happen either with 59.0 in March or, or 59.1 in May). I.e. that we in Tails still have plenty time to … [View More]

2 3

update
by Richard Pospesel 12 Dec '17

12 Dec '17

Hey Browser Devs, Flew into Austin yesterday for the Y'all Hands. This past week I've been investigating the root cause of #17933 and #15599 (pdf loads going to the default circuit rather than the first party domain). Technically speaking #17933 is now no-repro as it dealt specifically with the download button which now doesn't make any network requests. As explained in the comments of #15599 the default circuit is being used by XMLHttpRequests made by pdf.worker.js. The offending requests … [View More]

1 0

status report
by Arthur D. Edelstein 12 Dec '17

12 Dec '17

Hi Everyone, Here's what I worked on over the past week: I tracked down and wrote a patch for https://trac.torproject.org/18859 Not strictly a TBB bug, but should improve performance for users, I hope. Also on the subject of performance, I did a small manual test to try to understand the benefits (if any) of enabling HTTP2: https://trac.torproject.org/projects/tor/ticket/14952#comment:24 Indeed it seems the multiplexing feature of HTTP2 can offer us some useful speedups. So at Mozilla I … [View More]

1 0

missing meeting
by Arthur D. Edelstein 11 Dec '17

11 Dec '17

Hi Everyone, I'll be missing the meeting today because I'm flying to the Mozilla meeting. I'll send a status report this evening. Arthr

2 1

Tor Browser proxy settings
by Tom Ritter 07 Dec '17

07 Dec '17

Hey folks, nmago is continuing work on the crash reporter, and ran into some proxy problems. He's trying to get the proxy settings inside the crash reporter tool but the crash reporter tool can't read Firefox's proxy settings! Upstream this is talked about in https://bugzilla.mozilla.org/show_bug.cgi?id=1388897 https://bugzilla.mozilla.org/show_bug.cgi?id=1333125 and he asked here: https://groups.google.com/forum/#!topic/mozilla.dev.platform/opiD1Rz-e68 I'm wondering if in Tor Browser we … [View More]

3 3

New scheme for weekly Tor Browser IRC meetings
by Georg Koppen 07 Dec '17

07 Dec '17

Hi all! As discussed recently on our Monday meetings we want to try a different meeting format for the future. That's mainly due to scalability issues but I've also made good experiences with the proposed scheme. Here it is: 0) We'll be using a pad for meeting notes which can be found on https://storm.torproject.org/shared/tHoN4Ii7rLSjPE0OP4gydX4cMGadsXmRQNc-6lw…. 1) Everyone is writing their updates on the pad before the meeting starts including what they want to work on in the coming week. … [View More]

1 0