18:01:20 #startmeeting tbb-dev 18:01:20 Meeting started Mon Jul 25 18:01:20 2016 UTC. The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:20 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:01:30 hi 18:01:39 hi everyone 18:02:17 ok, so GeKo is on vacation, so I'm going to chair th meeting today, and help rebase and tag the release 18:02:54 mikeperry: thanks for stepping into old shoes 18:03:01 hi browser people 18:03:14 as far as I understand it everything is ready as far as code, we just need me to do the rebasing of the patch sets and tag the release for building 18:03:56 I may also try to switch us to DuckDuckGo, if I feel confident I can do that without issue 18:04:33 Will there be an alpha release at the same time or just after? 18:05:05 hopefully at the same time, but Georg's mail mentioned only a stable branch 18:05:16 OK 18:05:49 is there anything I need to be aware of the the alpha and hardened tags+branches? GeKo mentioned only tor-browser-45.2.0esr-6.0-1 18:05:58 as the source for rebasing on to 45.3.0 18:07:11 apparently #19735 is the ticket I should use for the search engine change 18:08:00 alpha should be on tor-browser-45.2.0esr-6.5-1 18:08:43 but boklm probably knows all :) 18:09:08 uh 18:09:15 is my resource:// patch 18:09:20 going to get merged at least in alpha 18:09:49 mtg today? 18:09:51 hi 18:09:52 I would also be in favor of Yawning's patch being included in the alpha. 18:09:55 it might not be perfect, but it probably won't break shit, and makes the situation dramatically less bad 18:10:12 do we have a ticket for it? 18:10:21 #8725 18:10:47 in an email, Georg said he was not sure about waiting for August 1 to do the alphas, or start building them on the weekend to have enough time for signing them 18:11:18 Yawning's branch has three commits that would need to be included 18:12:01 I used your commit naming convetion, so the 3 commits should stand out >.> 18:14:38 shooting from the hip, my guess is #8725 will be fine for the alpha. less sure about the stabl 18:14:55 I've been using various versions of that for weeks 18:15:03 which ironically makes my browser fingerprint unique 18:15:19 becasue it doesn't leak information like a sieve >.> 18:15:37 up to y'all 18:16:47 (offtopic to the meeting I have questions-ish about the updater) 18:17:20 ok, let's progress into the normal status updates and blocker concerns, and then discuss the release in more detail after that 18:17:27 who wants to go "next"? :) 18:17:41 * arthuredelstein can go 18:17:46 I poked at sandboxing tor browser 18:17:48 it works 18:17:58 it's sketch and kludge but infinitely better than any other attempt 18:17:59 nyah 18:18:01 done 18:18:03 >.> 18:18:20 Yawning: How do you feel about firejail vs flatpak now? 18:19:02 hm 18:19:07 either would work still 18:19:18 depends on what we want to do with our uptater 18:19:25 and how we want to launch tor 18:21:16 (which is an issue that we need to do design work on earlier rather than later) 18:22:53 Do you think firejail is easer to use with the existing updater/tor launcher? 18:23:27 the former kind of 18:23:44 tor-laucher poses interesting questions regardless of system 18:24:13 I need to think about it more (and we should prolly discuss this offline/in a tocket/e-0mail w/e) 18:25:16 Yawning: there's a *lot* of sandboxing work going on over on my side of the fence...have you talked to anybody working on it? 18:25:23 jld@mozilla.com is probably the place to start 18:25:33 no 18:25:52 I have sat in my bunker of h8 and infinite lonleyness and just got it working for me >.> 18:26:28 yeah, I have some thoughts in a text file about this.. Tor either needs to be launched independently, or we need some mechanisms like apparmor has for changing sandbox contexts based on execution.. we also need some way to lock down configuration of the tor client (at minimum some kind of control port filter could enforce this, possibly) 18:27:12 Yawning: also re: tor#8725 you should set yourself as owner of https://bgz.la/863246 and upstream the patch. (I'll help you do it). 18:27:21 ... 18:27:32 we may actually also need a separate meek-style profile to run tor launcher in a separate process 18:27:34 it's sketch javascript, doing it in C++ is prolyl better >.> 18:27:58 my thing is just the "expeident, good enough" thing >.> 18:28:01 and maybe leverage Mozilla's work there at a later date 18:29:10 re: sanboxing, our current work tor related work that is sandboxing oriented is https://bgz.la/1287994 and https://bgz.la/1288308 18:29:15 we're adding named pipe support 18:29:28 so we can block/unshare the network kernel API's altogether 18:29:49 then jld would know all about the work cribbing from the chromium sandbox 18:30:08 Yawning: anyway, my point is, maybe coordinate? you might make friends 18:30:43 and your bunker at h8 and infinite loneliness might turn into h8-less and not-so-lonely :) 18:30:43 oh cool namd pipe proxy support? 18:30:52 mikeperry: yup ;) 18:31:01 I went with af_unix 18:31:02 i convinced our necko team that it is a priority 18:31:09 for my h8 implementation 18:31:12 but I cheated 18:31:15 * mikeperry gets distracted by the mozilla tickets instead of status updates. and wonders if he is being a bad meeting chair :)( 18:31:36 naw, we're always a bunch of chaos in this meeting 18:31:47 I also looked at the neko code and it looked simple, but cheating was easier/faster 18:31:52 and didn't involve rebuilding firefox 18:31:54 mikeperry: let me make it easier on you. all active tor work: https://wiki.mozilla.org/Security/Tor_Uplift/Tracking 18:32:00 do we have af_unix patches/tickets for the linux and mac side? 18:32:08 we have a ticket 18:32:11 we don't have a patch 18:32:23 mikeperry: uh, yes... 18:32:24 because, like I said, I cheated (I use LD_PRELOAD) 18:32:27 that's the second bug 18:32:30 1288308 18:32:37 i think we're tackling windows first 18:32:48 cheating works fine on all the unixes 18:32:49 heh 18:33:31 turns out windows is harder than thought to make named pipes work 18:33:43 Do we have a parent TBB sandboxing ticket on trac? 18:33:44 and AFAICT, windows tor proxy doesn't support it either 18:33:57 so we might have a patch for you guys :) 18:34:16 arthuredelstein: don't think so 18:34:39 #14270 is our af_unix one 18:34:53 Yawning: I'll open one. 18:37:12 Yawning: done with your update? 18:37:32 #19055 18:37:36 I've been done for a while 18:37:43 >.> 18:37:48 arthuredelstein: that's orthogonal 18:37:54 Oops, #19750 18:38:22 (the whole upstreaming thing is dumb, and I have a better idea, but other people should do their reports) 18:39:23 ok 18:39:24 can I go? 18:39:28 go ahead 18:39:49 so, my team....(HAH! "my team"...never thought I'd say that) 18:39:50 so, ehem 18:40:05 my team has a WIP uplift for the javascript timer precision reduction 18:40:16 https://bgz.la/1217238 18:40:33 i'll be reviewing it today but would like some feedback from arthuredelstein and mikeperry (if you have time) 18:40:44 jonathan ran into some issues IIRC 18:41:10 I've got a WIP patch for the firstPartyDomain origin attribute here https://bgz.la/1260931 18:41:28 we're still chewing on it, but this will eventually replace ThirdPartyUtils::Get* functions 18:42:10 the containers project is maturing and fixing a bunch of the origin attributes bugs 18:42:28 next up for me is to uplift the tor isolation patches to validate our origin attributes implementation 18:42:33 that's it for me 18:42:36 oh 18:42:45 an we're all coming to the tor dev meetup in seattle in september 18:42:54 "my team" is 18:43:30 there is one more engineer that will be joining my team in the next week or so 18:43:36 so velocity++ 18:43:41 ok, now i'm done 18:44:45 cool. I am digging around for the follow-up ticket we had to #1517 on our side 18:46:16 * arthuredelstein can go 18:46:25 Since our last meeting, I reworked the font whitelisting patch 18:46:32 (https://bugzilla.mozilla.org/show_bug.cgi?id=1121643) 18:46:42 I finished up the https://bugzilla.mozilla.org/show_bug.cgi?id=1235520 patch (for posting soon) 18:46:47 I did some more investigation of the ramifications of the #18762 patch. 18:46:56 I opened and started working on #19741. 18:47:02 I set up a live test for #8725 / bugzil.la/1120398 and then reviewed yawning's additional patch to address that issue. 18:47:08 I reviewed #19484. 18:47:23 I started working on #19459, and I also did some work on #13018. 18:47:28 I hope to have patches working for these two in the next few weeks, in between vacations days. 18:47:31 That's it for me 18:47:46 * boklm can go next 18:48:30 This past week I was offline. This week I'm planning to help with the new release, and finish #19528 and #19410. 18:48:37 That's it for me 18:48:49 * mcs will give a report 18:48:58 Since our last meeting, Kathy and I helped finish #19568, we created a fix for #19269, and we filed and fixed #19689. 18:49:07 Also, we investigated some updater issues that were reported via blog comments and filed #19725. 18:49:13 We did some work on #19706 but we still need to develop a patch. 18:49:19 We reviewed the changes for #19417 and #19528. 18:49:26 We also did a quick review of https://bugzilla.mozilla.org/show_bug.cgi?id=1173199 (upstream bug for the pref to disable MathML). 18:49:31 This week we plan to work on #19725, #19706, and #19646. 18:49:37 A reminder: we will both be on vacation starting this Friday July 29 through August 5th. 18:49:42 That’s all for us. 18:50:50 Someone that understands the update process, if I download one of the incremental mars and invoke the `update` binary with the approrpiate flags, will the right thing happen? 18:51:48 Yawning: yes, you should be able to apply an update via that method. 18:52:01 mcs: thanks <3 18:52:07 and update handles signuatrue verification yes? 18:52:23 (where's the public key used to sign mars, is it posted anywhere?) 18:52:53 There may be some code that logs tghe args used to invoke the updater. 18:53:14 kk 18:53:25 Yes, sig verification is done by the updater. 18:54:05 arthuredelstein: huseby: #16610 is relevant to https://bugzilla.mozilla.org/show_bug.cgi?id=1217238 18:54:22 arg 18:54:23 https://trac.torproject.org/projects/tor/ticket/16110 18:54:35 (sorry for the continual dumb questions) 18:54:42 The public keys are checked in under toolkit/mozapps/update/updater (as .der files). I am afraid to ask why you need them :) 18:55:25 uh, pet project? >.> 18:55:54 more code from my house of madness? 18:56:18 :) 18:57:37 mikeperry: Thanks. The timing thing seems like potentially a big rabbit hole :( 18:57:51 Does anyone else have a status update to share? 18:58:34 mikeperry: did you mean #16610? 18:58:39 wait...sorry 18:58:41 reading 18:58:44 blah 18:59:30 mikeperry: thanks, marked the bgzla bug 19:00:32 arthuredelstein: yeah. intuition tells me that it's not "indefensible" but that there will be a fllor below which it will be hard to reduce the precision, even with the algorithm from #1110 19:00:56 I know, 16110 ;) 19:00:57 damn this lag 19:01:00 #16110 19:01:49 Yeah. I think the longer a script runs, the higher the precision is can achieve, through averaging. 19:02:33 "is can" -> "it can" 19:04:20 (regardless of the algorithm) 19:06:36 Anyone else for a status update? 19:07:32 yeah. it would be nice to know how long we can make it have to run, and what error that tends to introduce on single core vs multicore systems, etc 19:08:10 but going down that rabbithole by myself was not a high enough priority for me compared to other things 19:08:58 I can go next 19:09:30 we have finished porting the updater patches from TBB to Instantbird for Tor Messenger. the actual deployment and testing remains 19:10:20 there are few things that are not clear so I was wondering what would be the best way to discuss them? one is the MAR signing key generation and the other is the update-responses 19:11:22 (happy to do the real work here, just need to be pointed to the right direction as mcs did when we started) 19:12:50 for the mar signing key generation: https://gitweb.torproject.org/tor-browser-spec.git/tree/processes/KeyGeneration 19:12:54 mar key generation is documented at https://gitweb.torproject.org/tor-browser-spec.git/tree/processes/KeyGeneration 19:13:05 oh great, thanks 19:14:16 if we have time, I would also like to discuss if we can sign Tor Messenger releases on Windows and OS X with their respective certs 19:15:03 is there any solution where I can send the signed releases and someone on the TBB team can sign them with the required certs? 19:15:34 for the update-responses, we will need to use the script from https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/tools/update-responses 19:16:01 boklm: yeah I saw that. is the deployment process documented somewhere? 19:18:33 the deployement process we use is: https://gitweb.torproject.org/tor-browser-spec.git/tree/processes/ReleaseProcess 19:19:46 I meant for update-responses and its functionality on dist 19:20:28 * mcs unfortunately has to leave for a while but will read the backlog later. 19:21:52 heh, I'm out of practice at keeping these meetings timeboxed :) 19:21:56 sukhe: the deployement process is: updating config.yml, signing the mar files, running update_responses, copying the tools/update-responses/htdocs directory to dist 19:22:56 ok I will try it out and ask if you there any questions. thanks. 19:23:03 sukhe: do we have a ticket for this ? 19:23:25 for the updater? yeah #14388 19:24:11 ok, I can add some details about this on the ticket 19:25:18 ok great. thanks. (that's all from me) 19:25:46 do we have anything for the Tor Browser release other than #8725 and maybe #19735 (perhaps both going into only the alpha)? 19:28:41 we have also #19737 19:32:28 ok thanks 19:33:19 I'm going to call te meeting now, then. I am still travelling, but will merge those three in the next couple days, and then rebase when mozilla tags 19:33:57 thanks, Mike! 19:34:02 boklm: I will ping you when I think stuff is ready to start building 19:34:19 mikeperry: ok, thanks! 19:35:05 #endmeeting *baf*