18:00:22 <gaba> #startmeeting Browser July 20th
18:00:22 <MeetBot> Meeting started Mon Jul 20 18:00:22 2020 UTC.  The chair is gaba. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:22 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:00:27 <gaba> Pad is in http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor-tbb-2020-keep
18:00:28 <Jeremy_Rand_Talos> hi!
18:02:06 <gaba> please update the statuses. We will wait :)
18:03:25 <gaba> and add anything you may have to discuss to the agenda
18:06:09 <gaba> ok. should we start?
18:06:35 <sysrqb> good for me
18:06:58 <gaba> is the board up to date on what everybody is working on ? https://gitlab.torproject.org/groups/tpo/applications/-/boards
18:07:06 <gaba> are people using this board or finding it useful?
18:07:57 <GeKo> not sure yet :)
18:08:09 <GeKo> i still have some problems adjusting to the gitlab ui
18:08:16 <GeKo> with all the colors and stuff
18:08:56 <sysrqb> me too, but I haven't tried as hard as I should
18:09:21 <gaba> ok
18:09:37 <sysrqb> i think it'll be helpful in the future when I don't know what is needed within the next month
18:09:50 <sysrqb> but right now, we have an quickly approaching deadline
18:09:51 <GeKo> heh
18:09:52 <gaba> ok
18:10:03 <sysrqb> and we know what is needed in general
18:11:32 <sysrqb> okay, reviews
18:12:03 <sysrqb> https://gitlab.torproject.org/groups/tpo/applications/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Needs%20Review&assignee_id=None&label_name[]=Sponsor%2058
18:12:11 <sysrqb> is empty, so that seems good
18:12:31 <gaba> all reviews are assigned
18:12:32 <gaba> nice
18:12:47 <gaba> does anybody have any review that you think nobody is taking care of?
18:12:54 <antonela> should i move my tickets which need comments to [review
18:13:01 <GeKo> i plan to look over the Merge Ready items to get them finally merged :)
18:13:15 <antonela> or we are actively working on them and reviews are just merge requests
18:13:23 <GeKo> antonela: i think pinging folks might be enough?
18:13:28 <GeKo> but i am fine either way
18:13:30 <gaba> antonela: please do and unassign yourself
18:13:51 <antonela> but i did not finish
18:13:58 <gaba> oh
18:14:02 <gaba> you just need comments
18:14:17 <antonela> right
18:14:19 <mcs> Can someone remind me what the protocol is for getting things reviewed? Create an MR and then add Needs Review?
18:14:19 <gaba> pinging people or comment with their names on it may be good
18:14:21 <gaba> to focus
18:14:29 <GeKo> mcs: yes
18:14:34 <mcs> oh, and reassign to the reviewer
18:14:39 <GeKo> yes
18:14:42 <antonela> right, matt has it in his todo list i bet
18:14:44 <mcs> I think brade and I missed some steps last week :)
18:14:50 <GeKo> (the MR that is)
18:15:10 <gaba> yes
18:15:19 <mcs> so reassign the MR and leave the issue assigned to the patch author?
18:15:43 <GeKo> yes
18:15:49 <mcs> thx
18:17:02 <sysrqb> I don't see anyone requesting help with any tickets/issues
18:17:45 <sysrqb> please grab someone's attention if you need during the week
18:18:34 <sysrqb> so, discussion topics
18:18:38 <sysrqb> we have a few this week
18:18:48 <gaba> I left the discussion on line 51 from last week there
18:18:55 <gaba> in case there is any other question about it
18:19:10 <sysrqb> yes, thanks
18:19:39 <sysrqb> i don't have anything to add on that
18:19:44 <mcs> good info; thanks
18:20:41 <sysrqb> okay, next item
18:20:55 <GeKo> gaba: we should probably go over the tickets you tagged with s58 after the meeting
18:21:01 <GeKo> some are not s58 related
18:21:14 <GeKo> (just to get the milestones right)
18:21:24 <gaba> yes
18:21:41 <sysrqb> some of you may be aware of the discussion that preceded tpo/applications/tor-browser#40033
18:22:13 <sysrqb> but, the short summary is that we know there exist some onion services that do not terminate at the onion service
18:22:25 <sysrqb> the connection extends passed the onion serices to a remote host
18:22:33 <gaba> mostly in enterprise onions, right?
18:22:55 <sysrqb> the onion service doesn't provide any guarantees about the "onion service" -> "remote web server" connection
18:23:14 <gaba> :(
18:23:22 <Jeremy_Rand_Talos> sysrqb, are you talking about TLS in Whonix-style scenarios as well as enterprise infra?
18:23:33 <sysrqb> if that connection goes over the internet, then a http connection between tor browser and an onion srevice using http may be secure
18:24:04 <sysrqb> but if the onion service -> remote server connection is not encrypted in another way, then the http connection is happening over the internet
18:24:08 <sysrqb> so fun times.
18:24:25 <sysrqb> Jeremy_Rand_Talos: not in particular
18:24:35 <sysrqb> gaba: yes, i hope
18:24:50 <sysrqb> but i don't know how often an onion service is deployed like this
18:25:09 <sysrqb> therefore, we have a problem
18:25:40 <sysrqb> where Tor Browser assumes onion services connections are secure
18:25:46 <ahf> hopefully none of them are deployed where the last link is over the internet with HTTP? :o
18:25:52 <Jeremy_Rand_Talos> sysrqb, so, IMO it's unwise to treat non-TLS onion as secure, because in Whonix style threat models the Tor daemon is in a different trust domain than the application, and onions terminate at the Tor daemon
18:26:04 <GeKo> ahf: there are
18:26:06 <sysrqb> (providing authenticity, integrity, and confidentiality)
18:26:14 <ahf> ok
18:26:16 <GeKo> which is the problem :)
18:26:57 <sysrqb> Jeremy_Rand_Talos: if that is in your theat model
18:27:04 <sysrqb> then I argue you're doing it wrong
18:27:15 <sysrqb> and Tor Browser should have its own tor client
18:27:25 <sysrqb> and that client connects to another gateway tor client
18:28:06 <sysrqb> using a remote tor client is kinda weird
18:28:45 <sysrqb> so, maybe this would be better discusssed at a dedicated meeting
18:29:09 <Jeremy_Rand_Talos> sysrqb, yeah let's defer my comment for later, don't want to hijack the convo :)
18:29:10 <sysrqb> and i saw acat snuck a comment onto tpo/applications/tor-browser#40033 just before the meeting
18:29:56 <sysrqb> but, given that we know about deployments where an onion service connection should not be considered as a secure channel
18:30:12 <sysrqb> we should think about what assumptions we can/should make about onion service connections
18:30:34 <sysrqb> and, maybe, what we should start doing such that in the future we can correctly make that assumption
18:30:41 <sysrqb> and what we should do in the mean time
18:30:55 <sysrqb> because tpo/applications/tor-browser#40033 has usability implications
18:31:36 <sysrqb> we have a release next week, and that should (probably) include a fix, of some sort
18:31:53 <sysrqb> so maybe i'lltry scheduling a meeting in the next day or two for this
18:32:06 <gaba> we are supposed to have a release meeting tomorrow
18:32:10 <gaba> at the same time as today
18:32:11 <sysrqb> (we have too many discussion topics today for that)
18:32:26 <gaba> https://pad.riseup.net/p/tor-browser-release-meeting-keep
18:32:30 <sysrqb> oh, true, we can take over the release meeting with this topic
18:32:36 <sysrqb> good idgaba
18:32:38 <gaba> yes
18:32:39 <gaba> let's do that
18:32:41 <sysrqb> *idea
18:32:49 <sysrqb> great
18:32:50 <gaba> do you think we should announce that this meeting its happening tomorrow?
18:32:52 <GeKo> sysrqb: i think we should not waste time to try to get into contact
18:32:59 <GeKo> with the problematic onion services we know
18:33:04 <gaba> in tor-project or tor-internal@
18:33:10 <GeKo> maybe we can find a way to fix things together with them
18:33:23 <GeKo> because the problem runs way deeper than just cookies
18:33:32 <sysrqb> GeKo: yes, i agree
18:33:37 <GeKo> if we think we need to backout the cookie patch
18:34:02 <GeKo> we should bite the bullet and do not treat *any* http://xxxx.onion as secure
18:34:19 <acat> and change the security expectations patch i guess
18:34:24 <GeKo> which has far-ranging usability issues for mixed content and password entering
18:34:35 <GeKo> see #21321
18:34:51 <GeKo> and additionally, #23439
18:35:07 <GeKo> at the end of the day
18:35:22 <GeKo> if http gets strike-through or blocked
18:35:25 * Jeremy_Rand_Talos notes that a potential medium to long term solution is discussed in #33568
18:35:31 <GeKo> http://xxxxx.onion would need too
18:35:45 <sysrqb> yes
18:35:54 <GeKo> so, if we want to cross that bridge then we should be ready to burn down that whole thing
18:36:02 <GeKo> which we worked on over the last years
18:36:57 <GeKo> let alone getting all the code ripped out of firefox as we upstreamed everything here
18:37:06 <Jeremy_Rand_Talos> sysrqb, I don't usually attend the release meetings, but if this topic will be covered at this one, I would probably want to attend; what's the timeslot (so I know to keep my schedule open for it)?
18:37:20 <sysrqb> Jeremy_Rand_Talos: same time as this meeting
18:37:29 <Jeremy_Rand_Talos> ok, and that's tomorrow?
18:37:33 <sysrqb> gaba: but we should make clear our assumptions ues
18:37:37 <sysrqb> arg.
18:37:38 <sysrqb> yes
18:37:47 <sysrqb> gaba: maybe tor-project
18:37:51 <gaba> ok
18:38:01 <gaba> done
18:38:10 <sysrqb> GeKo: yes, i'm conflicted.
18:38:42 <sysrqb> but we should create a plan
18:38:48 <sysrqb> for one solution or another
18:38:55 <gaba> ok. Let's discuss this tomorrow
18:39:22 <sysrqb> yeah
18:39:28 <gaba> There are a few more topics in the agenda and only 20 min more of meeting :)
18:39:34 <GeKo> sysrqb: could you get it going making contact to whomever knows anything about the problematic onion service setups?
18:39:57 <GeKo> i feel we still don't have all the information or possible view points to make a proper decision
18:40:08 <sysrqb> GeKo: sure, yes
18:40:22 <GeKo> we have things alec said, yes. but that's it from the server side
18:41:04 <sysrqb> yeah
18:41:15 <sysrqb> okay. Fenix on Gitlab
18:41:16 <mikeperry> are problematic onion services exclusively the ones that have expensive .onion TLS certs?
18:41:31 <sysrqb> mikeperry: no
18:42:00 <GeKo> i don't think we know of any others, no?
18:42:04 <sysrqb> because, as the argument goes, if the webserver sends a cookie containing a credential over http but sets the secure attribute
18:42:14 <sysrqb> then, even though the original channel was not secure
18:42:26 <sysrqb> the browser should not echo that cookie over an insure channel in the future
18:42:31 <sysrqb> *insecure
18:43:00 <acat> but as GeKo said, then the actual problem is not just cookies, but anything that assumes that's a secure connection (e.g. logins)
18:43:13 <sysrqb> so, if the browser doesn't know if the onion service is terminated locally or remotely, then it can't make a decision about whether the channel was secure
18:43:21 <sysrqb> acat: right
18:43:25 <sysrqb> i agree
18:43:52 <sysrqb> okay. GitLab
18:44:14 <sysrqb> mirroring the fenix repo from github seems reasonable
18:44:22 <sysrqb> i know gitlab has a mirroring feature
18:44:29 <sysrqb> but i don't know how it works
18:44:34 <ahf> we have no way right now of automatically updating it, but i was thinking of pulling it over seems like a good start
18:44:46 <ahf> i also don't know if we want to do it via gitolite?
18:45:00 <GeKo> sysrqb: why would we want to mirror the whole repo and not just create branches as we need them
18:45:08 <GeKo> as we do right now for tor-browser?
18:45:20 <sysrqb> true
18:45:43 <gaba> Fenix hosting on Gitlab  :)
18:45:44 <sysrqb> we'll create thosee branches manually
18:46:03 <sysrqb> so we can simply push the branches onto gitlab directly
18:46:09 <ahf> the fenix repo does already have a lot of branches in it, including their release branches
18:46:36 <sysrqb> and we should maintain signed HEAD git commit
18:46:47 <sysrqb> as we plan for the other repos
18:47:26 <ahf> with a signature someone in tor makes or is that something they provide?
18:47:41 <sysrqb> one of GeKo or myself (right now)
18:48:38 <ahf> cool
18:48:47 <sysrqb> ahf: how difficult is setting up CI on gitlab?
18:48:54 <ahf> very easy!
18:48:59 <ahf> and the machines that hans came with a beefy
18:49:06 <acat> and how heavy can it be? :)
18:49:06 <sysrqb> i'd like to run the existing unit tests in fenix (and other android projects)
18:49:21 <ahf> https://gitlab.torproject.org/tpo/core/tor/-/blob/master/.gitlab-ci.yml
18:49:29 <ahf> is all it needs to for tor to build on debian
18:49:41 <sysrqb> neat, thanks
18:50:08 <ahf> and the machines have 32 cores and a lot of RAM, so things are moving fast there
18:50:13 <sysrqb> while we are starting from a clean place, i'd like to try maintaining the tests in the next projects
18:50:16 <sysrqb> and adjusting them as needed
18:50:38 <ahf> so this is for fenix you are thinking?
18:50:58 <sysrqb> yes, and android-componetns, application services, glean
18:51:07 <sysrqb> but those can come after fenix
18:51:17 <ahf> hm, i haven't tried running fenix' test because i have just messed around in the build systems
18:51:27 <ahf> but maybe if it is very easy to run then it wouldn't be much work to do
18:51:38 <acat> sysrqb: and what about tor browser (desktop)?
18:51:48 <sysrqb> acat: we want that, too
18:52:06 <sysrqb> but i think that is a separate project
18:52:16 <sysrqb> and we can run the testsuite locally until then
18:52:43 <acat> we could maybe at least have linting (./mach lint)
18:52:57 <acat> although we can also run locally, i guess
18:53:24 <sysrqb> specifically we need to solve tpo/applications/tor-browser-build#23631
18:53:28 <ahf> how about i try to move a fenic repo over on gitlab just to see how that goes and try to see if i can do anything useful with it via gitlab ci? i wanted to the first today anyway
18:53:29 <sysrqb> acat: that's true
18:53:32 <sysrqb> we can try that
18:53:54 <sysrqb> ahf:  sure
18:54:03 <sysrqb> i've run the tests fenix locally
18:54:08 <GeKo> sysrqb: boklm has a good patch for that i think
18:54:12 <ahf> you just run them on linux sysrqb?
18:54:13 <sysrqb> so i can help with getting the config setup
18:54:16 <ahf> without any emulator or anything?
18:54:25 <GeKo> we get to that ticket after we are done with release migration
18:54:28 <sysrqb> ahf:  yes, linux
18:54:35 <ahf> sweet, gonna try that
18:54:37 <sysrqb> GeKo: yeah, i haven't looked at it, though
18:54:39 <GeKo> (and are getting rid of wheezy for linux)
18:54:52 <sysrqb> but i am happy to see it
18:55:19 <sysrqb> ahf: it's only the java/kotlin tests, which are platform independent
18:55:34 <sysrqb> i think there are android-specific tests, bu i haven't looked at them yet
18:55:47 <ahf> oki!
18:56:06 <sysrqb> okay, quickly tpo/applications/tor-browser#33962
18:56:27 <sysrqb> whose discussion item was DoH?
18:56:29 <mikeperry> yeah basically I realized that patch makes it unsafe for ppl to use DoH
18:56:32 <mikeperry> but is itself safe
18:56:43 <mikeperry> idk if that matters to us but I wanteds to flag it
18:56:59 <mikeperry> because I could see ppl on eg tor-talk going yolo to test DoH
18:57:50 <sysrqb> can we easily patch out the parallel request?
18:58:07 <mikeperry> and it will first break, and then they may decide to flip that pref, and then that becomes unsafe.. and not because DoH itself leaks, but because there's this perf experiment stuff, and some other fallback cases to native
18:58:57 <sysrqb> okay
18:59:00 <mikeperry> sysrqb: yeah it will be blocked by that pref.. like we could make a separate patch to disable DoH and not have that pref apply to DoH
18:59:13 <mikeperry> and then the parallel rerquests would fail due to that patch
18:59:27 <sysrqb> can you create a gitlab issue for it?
18:59:47 <sysrqb> this is something we should track
19:00:14 <mikeperry> ok
19:00:17 <sysrqb> in particular, related to tpo/applications/tor-browser#30753
19:00:37 <sysrqb> (we missed the "Tor Browser 9" boat)
19:00:39 <sysrqb> thanks
19:01:01 <sysrqb> we're running a few minutes over time
19:01:11 <sysrqb> so i'll end the meeting here
19:01:19 <sysrqb> mikeperry: thanks for bringing that up
19:01:22 <sysrqb> thanks everyone
19:01:29 <sysrqb> o/
19:01:30 <Jeremy_Rand_Talos> thanks!
19:01:33 <acat> thanks
19:01:43 <ahf> o/
19:01:58 <gaba> #endmeeting