18:01:59 #startmeeting Tor Browser Meeeting 3 August 2020 18:01:59 Meeting started Mon Aug 3 18:01:59 2020 UTC. The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:59 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:02:07 Welcome to August 2020, everyone 18:02:20 2020 what a joke 18:02:29 can we reset? :) 18:02:53 do over? 18:02:57 i am here 18:02:59 sorry 18:03:00 not until the next simulation checkpoint is stored 18:03:10 lol 18:04:00 mikeperry: when's that scheduled? 18:04:02 https://pad.riseup.net/p/tor-tbb-2020-keep 18:04:04 i think you put more weight on the simulation argument than it actually holds but that's for a different discussion .) 18:04:07 :) 18:04:15 heheh 18:04:39 GeKo: you're not convinced yet? you've heard his argument 18:04:51 :) 18:04:52 sysrqb: it is continuous, but movement means a lot of copy-on-write updates.. so staying still at home definitely makes it faster 18:04:55 i've read the original paper :) 18:04:58 anyway 18:05:11 mikeperry: oh, good. 18:05:15 :) 18:05:22 so. Tor Browser. 18:06:52 mikeperry: you have a second “Week of 07/27 (planned):” 18:07:07 multiples dimensions perry 18:07:34 mcs: CoW glitch. fixed : 18:07:34 0 18:08:49 time keeps on slipping... 18:09:01 into the past 18:09:26 mikeperry: what's the situation with QUIC/HTTP3? 18:09:45 did you already brain dump onto a ticket? 18:10:45 no I found a couple of pieces of support code that were using UDP.. I need to dig more to make sure they can't be reached 18:11:05 it's disabled via pref anyway right? I noted it down and plan to come back after I finish XPCOM/android 18:12:28 similar story for FastOpen. it looks disabled, and we probably don't care about re-enabling it with proposal#309 I assume? I noted that one on the ticket 18:13:20 okay, that's good 18:13:51 GeKo, acat, and I chatted earlier today 18:14:10 and we'd like to get our 78esr-based alpha within the next two weeks 18:14:24 but, one blocker for that is the proxy-safety audit 18:14:33 so this work is definitely a high priority righ tnow 18:15:51 moving on to XPCOM is fine, if necko looks okay 18:16:18 what else do you have on your list after XPCOM and fenix (other than looking at QUIC/HTTP3/FastOpen again)? 18:16:28 yes, I have not noticed anything definite yet 18:16:53 XPCOM is ther last piece of desktop-specific audit. after that is android. hence my discussion point on that 18:17:30 ah ha. okay 18:17:48 the item dated "27 July" :) 18:18:34 we can come back to that discussion item in a little bit 18:20:17 acat: did you already talk with mcs/brade about reviewing the rebase? 18:20:55 not yet, i mentioned them in #40023 18:21:10 ah, okay 18:21:18 to ask for updater patches reviews (which they already probably do) 18:21:19 let us know what we need to do :) 18:21:38 ah, I see a comment now 18:21:41 but this time i'm a bit less sure of some of the patches i rebased 18:22:57 we will definitely look at the updater patches. does it make sense for GeKo to tell us which other patches need a second look? 18:23:24 i can ping you for those 18:23:38 great; thanks 18:26:06 acat: i see you created some MRs 18:26:09 https://gitlab.torproject.org/groups/tpo/applications/-/merge_requests 18:26:14 should those be assigned to someone? 18:26:28 ah, is that part of #40023? 18:26:49 yes, but maybe they could be reviewed independently 18:26:58 okay 18:27:20 we have four torbutton patches 18:27:28 i was not sure whom to assign them to, maybe mcs/brade? 18:27:54 i think mcs/brade hav a lot on their plate already 18:28:14 i can try doing that during my #40023 review 18:28:18 i can take MR 2: https://gitlab.torproject.org/tpo/applications/torbutton/-/merge_requests/2 18:28:29 but we all have a lot on our plate :/ 18:28:55 #40002 #40003 #40004 18:29:05 oh, right. 18:29:32 tpo/applications/torbutton#40002 tpo/applications/torbutton#40003 tpo/applications/torbutton#40004 18:29:52 we should probably be careful about merging those changes, tooo 18:29:55 *too 18:29:55 should we leave these as unassigned for now? 18:30:09 because they might conflict with what we need for esr78 18:30:28 in principle my intention was to make them compatible with esr78 18:30:36 yeah :) 18:30:40 :) 18:31:01 sysrqb: wfm 18:31:14 okay 18:31:42 okay, anything else we should talk about regarding weekly updates, before we move on to the discussion 18:32:41 okay, discussion topics 18:33:05 we only have mike's 18:33:54 so, pon Friday I pushed a branch onto the fenix repo 18:34:25 it's the Firefox 79 tag plus a signed commit that includes a gitlab CI file for running the full test suite 18:34:33 (fenix test suite) 18:34:57 it was an easy base from which we can modify, but we may want something different 18:35:36 for the proxy audit, yes, that's probably the correct place to start for auditing fenix 18:36:03 the dependencies go deep, but i've been auditing some of them as I work through #33939 18:36:15 just for sanity 18:37:54 i haven't thought enough about how we should track firefox beta development 18:38:23 so the current audits are using out-dated code 18:38:23 does that CI commit clone all the sub-repos we want? 18:38:38 well, just jumping on the latest beta and starting would be a good thing 18:38:40 or is there another way to get a full checkout of whatever we decide to build with, all at once? 18:38:47 but i'm working under the assumption that the delta between 79 and the next versions will be easier to audit 18:38:49 it's already 2 cycles past esr78 18:39:03 mikeperry: i don't think so 18:39:16 nope 18:39:22 we have our own fenix repo 18:39:28 right now we want at least application-services and android-components in addition to fenix 18:39:40 but the other repos are still using mozilla's tree 18:40:25 mikeperry: i think it's a safe assumption to use the current tip of those and look for proxy issues 18:40:41 and we'll finally reach that code when we release in september 18:41:00 just those two? 18:41:15 I am a little lost because I have no idea how this fits together or how to tell if it changes 18:41:21 application-services, andrdoi-components, fenix 18:41:39 the first one needs nss as deps and sqlcipher 18:41:58 for the former i applied the patches we already have in our tor-browser repo 18:42:14 (when preparing the branch for tor-browser-build) 18:42:20 i am not sure about the latter 18:42:38 i guess we would find out when doing the proxy audit in application-services 18:42:41 tpo/applications/tor-browser-build#3410 18:42:55 whoops. #34101 18:43:07 thanks 18:44:32 starting at fenix and then auditing down into android-components/applications-services/etc is probably a good path 18:44:44 a lot of the proxy audit from 68esr is applicable 18:44:57 yep 18:45:15 but the implementations are in the libraries instead of the browser (fenix) now 18:46:01 fenix mentions the androic-components version at https://gitlab.torproject.org/tpo/applications/fenix/-/blob/tor-browser-79.0-10.0-1/buildSrc/src/main/java/AndroidComponents.kt 18:46:01 i've stared at a lot of this code, and have a general working understanding of how the pieces fit together 18:46:13 so if you need some help, let me know 18:46:18 you could look at the respective tag in the android-components repo 18:46:23 to have that link 18:47:58 ok. I might not have questions until next week, but this will be useful if I have time to get to android before next meeting 18:48:37 mikeperry: this may be relevant, too https://gitlab.torproject.org/tpo/applications/fenix/-/issues/40008 18:49:07 that ticket is the parent for auditing various components within android-components 18:49:55 mikeperry: thanks 18:49:58 okay, anything else we should discuss now? 18:50:42 okay, i think we're done. 18:50:46 thanks everyone! 18:50:52 thanks! 18:50:52 have a good week, and happy hacking 18:50:53 thanks! 18:50:57 #endmeeting