Hi!
We had another Tor Browser meeting yesterday in #tor-meeting. Here is the meeting transcript:
http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-01-29-18.59.log....
And the notes from the pad are:
Monday, January 29, 2018
Discussion: - Tor patch uplift plan - Sessions we want to have for the team meeting day
GeKo: Last week: 1) Finished design doc update (#21256) 2) Finally finished debugging (#22256) and posted a backported patch for review 3) Dealt with release and post-release work (going over blog comments/new tickets etc.) 4) Continued writing the "Redesign of Tor Browser's security controls"-proposal 5) Some reviews 6) tjr: do you have https://bugzilla.mozilla.org/show_bug.cgi?id=1392604 on your radar too? Or should we try to deal with it for ESR 60? (GeKo: We poke ourselves I guess) This week: 1) More reviews 2) Finish the proposal and post it to tbb-dev for further discussion 3) Get back to work on #21777 (new clang-based toolchain for Windows cross-builds) 4) Get back to get the sandbox running on Windows 64bit (#24197) 5) Work on exempting .onions from mixed content warnings (#23439) 6) Look at tor launcher proposal 7) Monthly team admin stuff
tjr:
mcs/brade: Can you explain https://trac.torproject.org/projects/tor/ticket/19121 / https://gitweb.torproject.org/tor-browser.git/patch/?id=a4341a6 to me?
from mcs: We reinstated a check that Mozilla removed. With the hash check in place, all MAR files that are applied must be "advertised" in the update.xml metadata. Mozilla views this check as unnecessary because all MAR files are signed. We were more comfortable keeping the check in case there is some kind of update attack that we did not think of that removing the check makes possible. gk and mikeperry might have something specific in mind (gk agreed that we should reinstate the check). GeKo: nothing specific, but with that check an attacker has to break more than the signing in at least a bunch of scenarios and given that automatic updates are pretty important to safeguard we felt having two independent systems in place makes more sense.
tjr: So we're protecting against an attacker than can a) send the wrong update files b) forge or bypass the mar signatures but can't c) send their own update.xml file (which isn't cryptographicly verified and only contains a list of hashes?) Why could they do (a) but not (c)?
Spectre Stuff
More timer stuff
Lots of JIT stuff landed
MinGW
Sandbox almost uplifted! (GeKo: I wonder whether we don't need to take care about the SANDBOX_EXPORTS or whether we want to have this uplifted as well)
Fixed several mingw build breaks that popped up
Wrote a (rudimentary) Binary Transparency auditor for Moz's in-progress BT stuff
Arthur, Richard and I quick-triaged ~200 tor bugs
Have some followup from this we will talk about in our Tuesday-same-time-as-this meeting
All P1 bugs we are trying to get into 60: https://mzl.la/2DyHp6B
All P2 bugs we are going to try and get into 61-62: https://mzl.la/2E7hzrH
(GeKo: I think I want to work on the remaining .onion mixed content bug and get both pieces upstreamed into ESR 60)
tjr: Is that https://bugzilla.mozilla.org/show_bug.cgi?id=1382359 ? I'll P1 it and assign them to you if so (GeKo: yes, that's the bug)
mcs and brade: Last week: - Did some testing of Tor Browser 7.5-build3 and 8.0a1-build3 on OSX (focused on the updater). - Looked at icons and branding some more: #10888 (Mozilla trademarks still remain in some about: urls) #24578 (about:tbupdate popup notification formatting error) - Posted a patch for #24159 (Torbutton version check does not deal properly with platform specific checks). - After Isis fixed a server-side problem, we were able to resume work on #23136 (Moat integration). We found a meek client/Tor Browser issue that dcf is helping us solve. We found a problem where BridgeDB is not returning any bridges which Isis will need to help us solve. Planned for this week: - More work on #23136 (Moat integration). - Work with dcf to solve the meek client/Tor Browser SOCKS optimistic data bug. - Assist Isis as needed with the "no bridges returned" bug. - Review and comment on some of "our" bugs that are listed in Arthur's Uplift Tracker. - Triage the Tor Launcher bug list (set priorities, close outdated tickets).
igt0: Last Week: - Sent patch moving Tor Button to Tor Browser repository (#25013) - Removed Tor Button from the Tor Browser build (#25013) - Continued work on Integrating Tor Button in the Tor Browser mobile version (#24855) This week: - Work in the (#24855) - I still need to investigate https://bugzilla.mozilla.org/show_bug.cgi?id=1415595
from tjr: While this would be nice, I think the protections provided by fortify source are small enough that it isn't a huge priority. Just my opinion.
pospeselr: Last Week: - continued work on #22794 (Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.) - Jury Duty - met with tjr and arthur re tor uplift This Week: - finish #22794 - begin work on tor uplift patches
sysrqb: Last week: Continued working on Orfox patches. - Running mochi, junit, etc tests take a painfully long time - Mochitests fail when the Android App is not the focused UI element - After running the mochitests on a headless server, I finally found why all the UI tests were failing: https://people.torproject.org/~sysrqb/screenshot3.png - Debugged and patched some failing tests Worked a little on TorLauncher on Mobile (thinking about how we should integrate it) Read about HTTP/2 (over the weekend) and started thinking about how we can evaluate it and enable pieces of it Also read about QUIC and started thinking about how Tor can prepare for that This week: Finally finish the Orfox patches and request review Work on a branch tor-browser-build for TBA (Tor Browser for Android) Review Tor Browser uplift patch list
tjr: Do you have mozilla try access? Might be useful/faster for unit tests, especially if you have n changes you want to test independently.
sysrqb: Nope, but that sounds extremely useful. GeKo mentioned that last week, too, but I don't know how I should go about requesting access (igt0 will probably appreciate having access too)
arthur: I got access following these instructions: https://wiki.mozilla.org/ReleaseEngineering/TryServer#Getting_access_to_the_...
Also I use https://github.com/mozilla/moz-git-tools which allows you to use git to push to the try servers. tjr: Yea, do that and send me the bug you file and I'll nominate you. sysrqb: sweet! thanks! I didn't actually think about looking for a doc about how to do it...will do!
boklm: Last week: - published the new releases - finished #6119 (FPCentral) and all sub-tickets - started fixing some testsuite issues This week: - Fix upload of nightly builds to https://nightlies.tbb.torproject.org/ and enable testsuite on nightly builds - Fix testsuite issues to have all tests passing - Start working on #18867 (Ship auto-updates for Tor Browser nightly channel) - Will be afk next monday (but should be there for the meeting)
arthuredelstein: Last week:
Opened lots of bugzilla tickets
Updated torpat.ch
Created uplift patches for 1433357, 1433507, 1433509. Working on 1432983
Continued to rebase patches for mozilla-central
This week: Uplift, uplift, and away! More rebasing Also want to look at HTTP/2 -- sysrqb: would be useful to chat about this
- from sysrqb: ack yes
isabela: - working with sponsor4 on extension - we got it, just need new contract to sign etc. also working with network team / isis on organizing their work for finishing this deliverable - sponsor8 report due wed - meeting with arthur and geko on wed 1900utc (confirmed? antonela said that works for her) on circuit display work (GeKo: works for me) (arthur: wfm too)
Georg