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