18:00:48 #startmeeting tor browser 18:00:48 Meeting started Mon Jun 5 18:00:48 2017 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:48 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:00:54 hi all! 18:00:58 hi 18:01:08 o/ 18:01:08 as usual let's get started with the status updates 18:01:09 hi 18:01:23 who wants to go first today? 18:01:55 * mcs will go first 18:02:03 Last week, Kathy and I worked some more on #22471. 18:02:14 We then switched to working on #22459 and produced a patch. 18:02:20 We reviewed several patches. 18:02:24 Also, we spent some time preparing and participating in the Tor Launcher automation meeting. 18:02:31 This week, we will focus on updater testing for Tor Browser 7.0. 18:02:35 We will also work on #22496, and if we have time we will return to #22471. 18:02:43 That's all for us. 18:03:27 thanks. who is next? 18:04:16 nobody wants then i'll go 18:04:21 I sent more e-mail. 18:04:24 the end 18:04:34 thanks 18:04:46 sorry 18:04:56 np 18:05:16 last week i assembled all the necessary for the 7.0 release (i hope) 18:05:32 and started builds 18:05:48 we encountered some small missing pieces in build1 which are fixed in build2 18:06:04 build2 is uploaded into my build dir and signed 18:06:25 i did the begin-of-the-month-admin-work 18:06:43 and i started to look at changes coming in firefox 52.2.0esr 18:07:07 i'll start a build later today to check that we won't be surprised by build issues 18:07:30 this week i'll probably busy with releases/release preparations 18:07:37 that's it for me 18:08:24 * arthuredelstein can go 18:08:38 Hi everyone -- over the past week, 18:08:44 I wrote patches for #22452 and #22343 18:08:52 tracked down and backported a fix for #22462, 18:09:00 did some investigation of #21617, 18:09:14 reviewed some Tor Browser tickets as well as https://bugzilla.mozilla.org/show_bug.cgi?id=1039069 18:09:28 and I also started more work on #21762 issues. 18:09:37 This week I will try to finish that ticket and look at #16341 and #21999. 18:09:53 what's left in #21762? 18:11:17 arthuredelstein: ^ 18:11:21 There are three things mentioned in the original description. At least two of them require no action. The third I am still investigating. 18:11:49 okay, cool. 18:11:54 That one being blob favicons. I think it's actually safe, but I'm not 100% sure. 18:11:55 who is next? 18:12:02 * boklm can go next 18:12:04 I also hope to work more on #21617 and #21448 18:12:12 that's it for me :) 18:12:22 I made a patch for #21704, which needs testing on a non-SSE2 Windows machine if we can find someone who has one. 18:12:28 I helped build the new release, fixed #22328, #22003, #22479, and fixed some tests on #21982. 18:12:42 I synchronized the tor-browser-build.git repo with the latest changes from tor-browser-bundle.git, closed #17380 and opened #22499. 18:12:58 This week I'm planning to work on the panopticlick setup, and help with publishing the new release if we release it this week. 18:13:04 That's it for me. 18:13:36 so, the errors that are still shown in the tests are in fact test errors? 18:13:53 are you working on fixing them as well this week? 18:14:04 yes, I will fix them this week 18:14:14 cool, thanks 18:14:33 who else is here for a status update? 18:15:09 I can go (sorry) 18:15:16 hi! 18:15:19 I've been workign on the MinGW build and have made some progress 18:16:20 Most notably I've got a almost-working build in TaskCluster: https://bugzilla.mozilla.org/show_bug.cgi?id=1330608 18:16:41 It needs a couple peices of love, firstly the toolchain build grabs random tarballs and binaries and trusts them implicitly. 18:16:59 The hard part there will be getting the zlib part of nsis to build without downloading a compiled zlib-for-windows 18:17:17 The other piece is finishing the patches for -central 18:17:35 The most concernign of which is this new one: https://bugzilla.mozilla.org/show_bug.cgi?id=1365859 which uses a VS binary 18:17:58 And then the other concerning one(s) would be the one that prevents the successful compilation of the browser from running 18:18:08 ugh 18:18:18 Whichever that is! (Might be Skia, since I randomly just commented out assembly...) 18:19:39 Aside from that I reviewed some windows hardening patches for little-t tor, which you saw GeKo 18:19:48 yep, thanks 18:20:40 Mozilla turns that flag on, but I just realized it won't be turned on for TB 18:21:07 I should figure out how to confirm that flag's effects, confirm it in little-t tor, and then we can enable it in TB 18:21:14 That's all I have 18:21:21 that would be neat 18:22:11 tjr: did you get some responses to my "how can we get notified of tagged firefox releases"-mail? 18:23:04 another thing you might be able to help with: if you have access to a really old windows machine to test the SSE2 requirement that would rock 18:23:10 So I haven't prodded poeple on it because I think I have figured out the answer (in general) and need to solve it specifically for me as well 18:23:20 maybe mozilla has one still around? (see #21704) 18:23:29 I believe that https://wiki.mozilla.org/Auto-tools/Projects/Pulse/Exchanges will do it 18:23:38 in comment:14 is a test bundle fwiw 18:23:39 (will alert us on releases I mean) 18:24:11 aha 18:24:48 if you come up with a solution that works for you (and could work for us) i'd love to hear it :) 18:24:57 I have to solve this problem for myself now for https://bugzilla.mozilla.org/show_bug.cgi?id=1361058 which is unrelated to Tor 18:25:12 The goal for that is this month, so if that fits your timeframe I'll just plan on that 18:25:40 sure 18:25:46 that's fine 18:25:52 I asked in #releng about a non-SSE2 machine. I do not have one. 18:26:07 ok. 18:26:19 In theory I know one could emulate it by hooking the SPUID instruction in a Bochs emulator but.... that is not a straightforward solution hah 18:26:39 woah, i think we should try to keep it simple here :) 18:26:55 alright, anybody else for the status update? 18:27:25 okay, let's move on to the discussion part 18:27:31 i have three items i guess 18:27:39 1) the 7.0 release 18:28:18 so far i have not heard about a show stopper. so, i am inclined to get the bundles out on wednesday before/around noon UTC 18:28:28 does that sound reasonable? 18:28:37 boklm: would that work for you? 18:28:48 yes 18:29:00 ok. could you prepare the changelog tomorrow? 18:29:15 the html changelog for the blog? 18:29:19 i'll be mostly offline due to a public holiday but i'll look over it 18:29:20 yes 18:29:23 ok 18:29:59 hearing no objections, so let's go with that plan 18:30:06 2) future work 18:30:48 i think we might be busy this month with getting the switch to esr52 properly done and with fixing the remaining issues/new ones 18:31:15 but longer term there are some things from our roadmap to keep in mind 18:31:41 arthuredelstein: you can start focusing on upstreaming our new patches and writing new ones for tracking/fingerprinting defenses 18:31:57 (after the 7.0 dust settles down) 18:32:11 mcs: i think for you are the tor launcher changes coming 18:32:25 GeKo: yes 18:32:27 basically the stuff we talked about on friday 18:33:06 boklm: you'll have the pantopiclick as the item with the highest prio and then we need to finish the rbm switch and start working on 64bit windows builds 18:33:22 ok 18:33:26 there a other parts like testing hardening options etc. as well 18:33:44 i think i can help with some of those, so that not all of it is on your plate alone 18:34:03 Ooooh boy. We're going for 64bit on Windows? I guess I knew it was coming eventually.... 18:34:24 does this big picture look reasonable? or am i missing something? 18:34:30 yes, we do! 18:34:39 GeKo: Yes, I can work on those things. But these days I also feel a big sense of urgency on defenses against exploits. 18:35:31 yes, me too. 18:35:45 for that i'll try to get #16010 somehow fixed 18:36:07 that seems to be the most pressing item i think 18:37:13 arthuredelstein: there are things on our deliverable list that might intereest you then 18:37:27 Yes, that will be great to have. My thoughts have been about such things as ubsan, cfi, build flags, partitioning allocator and the chromium sandbox. 18:37:34 Not sure which of these fit with our deliverables 18:37:46 let me look 18:38:27 we have https://trac.torproject.org/projects/tor/wiki/org/roadmaps/TorBrowser 18:39:02 arthuredelstein: if you want to work on objective 3.2 go for it 18:39:50 Test impact and viability of hardening options: A) using Intel's MPX (memory 18:39:50 protection extension) for hardened builds, B) deploying STACK, which checks for 18:39:51 optimization-unstable code, C) SafeSEH (secure exception handling) 18:40:10 and activity 3 is 18:40:11 Test Undefined Behavior Sanitizer (UBSan) support for either hardened 18:40:12 standard builds or special QA builds, in order to identify critical compiling problems early 18:40:58 Cool, thanks. Where's the part about MPX? 18:41:05 arthuredelstein: but please don't drop the other stuff i talked about :) 18:41:07 Is that in the final deliverables doc? 18:41:13 No, for sure I want to do those other things too! 18:41:17 #16352 18:41:24 arthuredelstein: yes 18:41:52 if you look at the text in the final otf proposal it is mentioned there 18:42:08 Thanks, will do. 18:42:20 okay my item 3 is sandboxing 18:42:38 ! 18:42:41 we had some good discussion about it on tbb-dev thanks to yawning and others 18:42:55 now the question is how do we keep the momentum and move things forward 18:43:04 "start paying for it" 18:43:16 >.> 18:43:26 yes, that's a good plan. 18:43:29 hehehe 18:43:29 Alex_Gaynor: ^ 18:43:55 i think my point was and is that we need some kind of document 18:44:01 tjr: where should I start reading? 18:44:11 to organize the budget and be able to do so, it would be helpful for me at least to have the work that needs to be done organized in a pad or some place and then also be able to figure out how many ppl/for how long we estimate 18:44:17 outlining the stuff we want to do 18:44:20 yes 18:44:25 Alex_Gaynor: hi and welcome! 18:44:30 👋 18:44:31 Just now. For Windows, I think Alex and I's conclusion was that we could support either architecture (meta process or not) but that either would be hard 18:44:46 "Rewrite tor-launcher to be an external process that can handle downloading, installing, and updating firefox, without trusting it" 18:44:53 "with a better ui, and support for containerization" 18:45:52 i think that could be the abstract, yes :) 18:45:55 On Linux, there's nothing in theory that prevents firefox for forking/execing itself in a sandbox 18:46:00 beyond "I don't trust it to do so" 18:47:06 Yawning: i guess you thought about that the most. do you feel you could come up with a document of your idea 18:47:08 is whatever happens on linux will be the same for macos? 18:47:08 but my tinfoil hat doesn't seem to keep the chemtrails out of my drinking water or whatever 18:47:23 GeKo: I'm busy because I need to pay rent 18:47:30 and all the folks knowing things about windows, osx or android could add to that 18:47:31 so, "no"? 18:47:43 ok. 18:47:45 I said what I think should happen in the thread :/ 18:48:16 i can start a pad and try to copy and paste things from the tbb-dev discussion there - maybe try to organize it by platform 18:48:18 The pre-fork environment shouldn't process untrusted input though.... 18:48:48 isabela: that would be neat. we could then nag people about adding "their" content 18:49:00 or fixing my wrong copy and paste 18:49:00 hehehe 18:49:03 *fix 18:49:26 Really, the only odd thing out is android I think 18:49:39 and iShit phones 18:49:45 if we support those or are planning to 18:50:34 maybe. 18:50:36 hmm i think iphone will take longer to be consider 18:51:24 i think it is fine planning without it for the time being 18:51:33 would make sense to have it planed for android after drl project is done? 18:52:02 no 18:52:14 architecturally it doesn't make sense to plan for android at all in this 18:52:21 because it's Just That Different 18:52:41 imo 18:52:46 people are free to disagree 18:53:03 (this is also in the thread) 18:53:19 isabela: if we want to plan for it then it won't happen before the drl work anyway 18:53:28 I think all platforms are worth doing so maybe it's good to plan for them all in any case. 18:53:34 yes 18:53:37 it's not that it's not worth doing 18:53:37 ok 18:53:43 i will start the pad with it all 18:53:53 there's Good Reasons why, it will be a nightmare to do on android and sort of pointless 18:53:56 :/ 18:54:10 Yawning: Even that's worth fleshing out in a document though :) 18:54:20 I wrote an email flishing it out 18:54:37 anyway, the document should separate concerns between the UI/UX 18:54:48 (which are mostly irrelevant beyond, it needs to happen, and it needs to not suck) 18:54:52 arthuredelstein: yes, i want to have limits in that document too 18:55:06 and all the actually important things that this will do 18:55:17 like being able to spawn /configure tor 18:55:25 install shit, update stuff, use containers/sandboxing 18:55:28 etc etc etc 18:56:12 and I guess patching tor button to talk to a meta process (though that should be fairly easy) 18:56:41 (at least I thought of a way to do it, when doing the linux stuff, but ran out of time before I implemented it) 18:57:11 also I assume that we want to do this once and only once 18:57:20 and not like, once per platform 18:57:34 which probably rules out stuff like "write something in python" 18:57:43 if possible, yes, i think 18:58:07 because packaging that for windows would be a huge shitfest 18:58:14 if obfsproxy (python) is anything to go by 18:58:27 (or fte for that matter) 18:58:48 okay. do we have anything else to discuss in the remaining time? 18:58:55 yes 18:59:01 hi! 18:59:14 go for it 18:59:23 I am wondering if we could continue the last discussion about the new Tor launcher(sorry for the accidental disconnection last time). 18:59:27 (I think it's worth considering what sandboxing features are possible to implement _before_ a tor-launcher replacement is written.) 18:59:39 (If I were to do this, C++/Qt or something, and I think about a year of my time) 18:59:44 Yawning: a colleague of mine has managed to make a python thing packaged to work on All The OSes (but that doesn't mean it's "not a shitfest on windows" ;/ ) 18:59:58 I notice that arthuredelstein said 18:59:58 " 18:59:58 18:32:07 A related issue is something I was discussing with Yawning a couple of days ago, as a result of his email thread on tbb-dev. 18:59:58 18:32:31 He's wondering how the tor-launcher automation fits in with sandboxing. 18:59:59 18:32:53 That is, his sandbox approach probably requires a separate-process tor-launcher. 19:00:01 18:33:51 So the question is whether the new UI should be developed in the same JS extension or as a new separate program using QT or similar. 19:00:04 18:34:57 Or possibly iry's python-based project would be a way to do it." 19:00:04 it's Python, Twisted and Qt 19:00:09 iry: http://meetbot.debian.net/tor-project/2017/tor-project.2017-06-02-18.04.txt 19:00:22 But people are concered that "try to re-write in QT we will probably fail to deliver on time." 19:00:23 What I just would like to inform you that the all the basic functions of python-based Tor launcher have been implemented now actually(and you try it if you are interested in it). (There are still some issue like how to remember user's last settingf or GUI, but they probably can be fixed without too much effort). 19:00:24 meejah: thanks for volunteering 19:00:33 that's what we came up with last friday in our meeting on #tor-project 19:00:35 yes i went over the friday log 19:00:39 meejah: does it build terministically? 19:00:42 volunteering to point you at his repo? ;) 19:00:46 no 19:00:55 i do not believe it does deterministic builds 19:00:56 :( 19:01:16 iry: let's close the meeting first so we don't block the channel 19:01:21 a huge part of what makes this rediculous is deterministic python for windows, with modules that call native code 19:01:22 So I am wondering if it still can be an option for us to implement the automation based on it. And since it's written in Python, the automation based on it may be even easier. What do you think? 19:01:28 okay! 19:01:35 thanks all for the meeting *baf* 19:01:38 #endmeeting