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