17:58:50 #startmeeting Tor Browser Meeting 10 August 2020 17:58:50 Meeting started Mon Aug 10 17:58:50 2020 UTC. The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:58:50 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:58:56 o/ 17:58:57 o/ 17:59:09 hihi 17:59:10 Hello! 17:59:15 hello! 17:59:40 * sysrqb updates pad 17:59:57 hi 18:00:18 https://pad.riseup.net/p/tor-tbb-2020-keep is the pad, this is the channel 18:00:36 hello 18:02:07 * mcs added a discussion / info sharing question r.e. updating an MR in GitLab 18:03:11 * Jeremy_Rand_Talos was also wondering about that, thanks for asking that mcs 18:06:13 GeKo, I think you may have a typo "July 3" instead of "August 3" 18:07:43 yeah, i wish it still were july 18:07:45 thanks 18:07:58 no worries :) 18:09:05 okay 18:09:08 i think we can get started 18:10:21 we have boards 18:10:23 https://gitlab.torproject.org/groups/tpo/applications/-/boards 18:10:37 i need to update my tickets so they are on the correct board 18:10:58 please remember to update the labels on your assigned tickets so they reflect your work, too :) 18:11:56 I see all MRs are assigned, https://gitlab.torproject.org/groups/tpo/applications/-/merge_requests 18:12:00 so that is good 18:12:09 if a ticket has a MR which is in need_review, should we update the ticket also an set both need_review and assign to the reviewer? 18:12:59 nah, i think that's not needed 18:13:05 giving both the Needs Review label seems like more work than is necessary 18:13:19 in particular once you take revisions into account... 18:13:38 this is related to mcs' question 18:13:48 so we can jump to that next 18:14:35 but, in theory, a MR shouldn't ben open and have Neds Review for a long time 18:15:08 so leaving the issue in Doing while the MR has Needs Review seems okay to me 18:15:22 (please excuse my typos :) ) 18:16:15 fine with me 18:16:38 we can think about an alternative if we have an issue and a MR open for a long time because they aren't high priority 18:16:55 maybe in that case the MR has Needs Review, and the issue gets Icebox or Backlog or something like that 18:17:21 whatever is most reasonable for us 18:18:05 mcs: for your question 18:18:55 we've experimented with this, and at this point we're following the process of closing the current MR and opening a new MR with the corrections 18:19:06 /changes 18:19:26 GeKo has included one more step, where he pushes a fixup commit to the current MR 18:20:24 and then creates a new squashed branch and creates a new MR with that branch 18:20:48 i like this flow because it make reviewing changes between MRs extremely simple 18:20:58 *makes 18:21:36 So both branches are pushed to GitLab? 18:22:11 yes, the original branch including the fixup! commit(s) and the new squashed branch 18:22:33 the original MR is then closed, and a new MR is opened for the new squashed branch 18:23:09 does that make sense? 18:23:51 pushing the fixup commits simply lets you `git diff` the two branches and they shouldbe identical 18:23:59 i'd be okay with just having fixup commits and then squashing the branch myself before merging 18:24:07 so if the fixup looks good, then the squashed branch is good 18:24:15 the important point for me is that i can keep my local review state 18:24:22 yeah, that's another option 18:24:32 so i don't have to re-review everything when i pull from gitlab 18:25:01 the first option is a bit easier for folks who review and merge at the expense of the patch writer 18:25:06 the latter vice versa 18:25:13 if only gitlab would allow changing the source branch in a MR :) 18:25:41 Things get more complicated if the new branch is based off a different tor-browser-… branch (e.g., if the fix is rebased). 18:26:07 I guess the fixup on the original MR would help in that case 18:26:23 yes 18:27:41 mcs: i am very much interested in tor-browser#40059 :) 18:27:53 not sure if the things you planned are in order... 18:29:01 not listed in order we will work on things (order by issue number). I think tpo/applications/tor-browser#40059 will be next after we revise tpo/applications/tor-browser#40048 18:29:18 sounds good, thanks 18:29:50 mcs: the closed bugs audit went only up to and including mozilla78 and firefox78, right? 18:29:56 + feature audit 18:30:53 GeKo: yes, so far 18:31:21 okay. i guess we need at some point making plans how to proceed with all the auditing... 18:31:32 given that we need that for mobile 18:31:53 mcs: but we can do that next week when you are away :) 18:31:54 i briefly chatted with acat about this 18:32:01 aha, okay 18:32:07 we don't have a plan yet 18:32:11 to be clear 18:32:24 but it is something we are thinking about 18:32:33 great 18:32:35 we should create a plan 18:33:16 mikeperry: how's the proxy audit going? 18:34:09 I did tests to check for stray quic/http3 leaks last week. those protocols appear to be properly disabled by pref 18:34:25 did the fenix audit fall off your plate? 18:34:26 I still have to finish off the xpcom grepping, but almost done 18:34:37 okay, that's good 18:35:28 I am going to finish that xpcom audit and then take a brief vacation 18:35:39 mikeperry: what's the plan for https://bugzilla.mozilla.org/show_bug.cgi?id=1620045 18:35:41 ? 18:37:28 I looked through the rust code for networking via grepping.. I still dont understand enough about the rust build process to understand that tool 18:38:02 but it occurrs to me that at the point where we are inspecting networking imports, we may want to patch *all* networking syscalls in the final 18:38:10 err final build binary 18:39:40 once we have beta builds, I can look at them in a disassembler and see how we might do that. that might be what we have to do long term anyway. this audit is a nightmare and fragile 18:40:10 mikeperry: i see. you can already do that in out nightly builds is if you like :) 18:40:20 http://f4amtbsowhix7rrf.onion/tor-browser-builds/ 18:40:29 they are based on 78.1.0esr 18:40:33 ah, we have those on esr78? 18:40:40 yep 18:41:06 here is the announcement: https://lists.torproject.org/pipermail/tbb-dev/2020-August/001126.html 18:41:47 thanks 18:42:22 automating this sounds painful 18:42:44 but, mikeperry, please document how you do it 18:42:59 and hopefully we can find a more sustainable solution 18:42:59 finding some solution where we block all known bad APIs seems the only way to go forward safely 18:43:37 yep 18:43:38 this sounds like a specific case of the "torsocks problem" 18:43:49 yah, basically 18:44:15 I am not so worried about desktop tbh 18:45:01 everything I have seen looks good, except for that DoH issue I filed, and some deep support for quic burried in the socket code. but it did not activiate in testing 18:45:18 yeah, mobile is probably another story... 18:45:22 I am most worried about android because of all the intent shit that I found laast time 18:45:44 yep 18:45:50 and other ways external system code can be invoked 18:46:26 mikeperry, which DoH issue is that? (Wondering if it's the same thing I noticed) 18:46:35 and idk if torsocks style import patching is the right way to go there.. it really depends on how many such apis there are 18:46:50 https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40034 18:47:18 Ah ok, sounds different. 18:47:43 * Jeremy_Rand_Talos will file a bug for the thing I noticed as soon as I have sane repro instructions 18:47:54 sounds good, thanks 18:48:16 I have firewall rules for macos to notify me on leaks, so we have that going for us. similar sandboxes exist for linux 18:48:31 we may want to announce such things for the alpha, for people to help us monitor just in case I missed something 18:48:44 yes 18:48:49 but I'm less worried about that, as I said.. 18:49:22 for android, my plan is to also test in the simulator, to see if I can hack/instrument/firewall that thing to check for leaks via live testing 18:49:28 with nightlies, too. "please run this with tcpdump/wireshark/firewall rules and monitor for abnormal connections" 18:50:07 how's our timeline for the fenix nightlies/alpha? 18:50:25 the emulator creates an interface you can snoop with tcpdump/wireshark 18:50:28 at least on linux 18:50:51 i'm hoping we'll get nightlies in (maybe) a 1.5 weeks 18:51:20 but that's a kind of a blind guess right now, because we have a lot of unknowns 18:51:36 i'm hoping we'll have a better estimate by the end of this week 18:51:43 for nightlies 18:52:29 i'm aiming for an alpha fenix-based version by the end of the month 18:52:59 and on this topic, while we're running out of time 18:53:30 we planning on releasing the first desktop alpha version at then beginning of next week 18:53:51 i'm going to be afk on Friday and during the weekend 18:54:30 but i can help with prep until Friday morning, and then any remaining signing/uploading on Monday 18:54:54 acat: can you help with building? 18:55:03 i can 18:55:11 thanks 18:56:18 i guess we won't start building before monday, but we'll see how the week goes... 18:56:54 GeKo: considering i'll be away, i'll let you make that call :) 18:57:01 I will be afk this thursday-weds... I will finish off the xpcom grepping before that point. I will look into android closer to when we have nightlies, and do some binary analysis of all builds around that point as well 18:57:03 (away for the weekend) 18:57:43 mikeperry: okay, sounds good, thanks 18:58:30 okay, we can discuss plans for 10.0a5 during the week 18:58:48 i'll close the meeting here 18:58:55 thanks everyone! have a good week 18:59:06 and mikeperry have a nice afk 18:59:10 o/ 18:59:11 thanks! 18:59:14 #endmeeting