14:59:38 <richard> #startmeeting Tor Browser Weekly Meeting 2022-08-02
14:59:38 <MeetBot> Meeting started Mon Aug  8 14:59:38 2022 UTC.  The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:38 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:59:52 <richard> here's the pad: https://pad.riseup.net/p/tor-tbb-keep
15:00:02 <richard> so the way we typically do this weekly meeting thing
15:00:27 <richard> is we each have an entry in the pad, with a sort of rolling record of planned weekly activities vs what actually happened
15:00:57 <richard> there's a section for announcements and any discussion points people wish to bring up
15:01:16 <richard> and traditionally we've also *bolded* any items in your individual seciton that you may want to discuss
15:01:31 <donuts> o/
15:02:04 <richard> we also tend to take this time at the start of the week to update our boards, make sure our assigned issues are in the 'right' columns, etc etc
15:02:38 <richard> as that helps gaba and I a lot with planning and more importantly making sure you all aren't overloaded with too many random asks
15:06:05 <donuts> done
15:06:25 <richard> welcome back to the browser meeting donuts :) not too early I hope ;)
15:06:43 <donuts> tyvm, this is a lovely time lol
15:06:47 <richard> :)
15:08:00 * Jeremy_Rand_Talos_ likes this new timeslot
15:08:10 <donuts> ya right
15:08:21 <donuts> i think i made it to the old one twice
15:08:55 <richard> :)
15:10:29 <richard> alright let's start with the discussion points
15:11:05 <richard> PieroV: what's the current status of your various 102 rebases, and what work is stil outstanding?
15:11:47 <PieroV> I've decided to switch to Rust official binaries as a workaround, and wait for boklm to see together what we can do
15:12:05 <PieroV> I've chatted also with GeKo earlier, to understand some history behind why we compile Rust
15:12:23 <PieroV> TL; DR: it may be needed for reproducibility, in case we need to add patches.
15:13:25 <Jeremy_Rand_Talos_> Long-term it might be interesting to use Guix instead of Debian in that container, since they bootstrap Rust entirely from source.  (I talked to boklm about this in 2019.)
15:13:43 <PieroV> Anyway, I've also opened a thread on Rust forum to ask if someone knows how rustc official binaries are created. The plan is trying to reproduce their builds (probably not byte by byte, but at least the same config) and then try to get our usual rustc build by steps
15:14:49 <richard> are we blocked on anything else beyond Rust for getting some test builds?
15:15:06 <PieroV> No. With this workaround I have both a working base browser and Tor Browser
15:15:28 <richard> well that's just great
15:15:37 <richard> ok now what about for Android?
15:15:38 <PieroV> Base browser has a pair of things to fix (the NoScript icon is visible, and the Tor Browser name is used in the Security Level strings)
15:16:07 <richard> (yes we do have a few more 'tor' mentions here and there in the base-browser source)
15:16:10 <PieroV> Also, the settings contain a new "More from Mozilla" page, which is enabled/disabled by Nimbus and Moz experiments. We'll have to investigate about them
15:16:44 <PieroV> About Android, I'd like to test the new branch to build also GeckoView. I'll have to check a pair of things, first
15:17:17 <PieroV> One is the preferences in 000-tor-browser.js. Then I think we could add the mozconfigs like we do for desktop
15:17:51 <richard> mmhm, we need to do a similar pref split between base-browser and tor-browser there like we do for desktop right?
15:17:54 <PieroV> Also, I'd prefer the Android tor-browser-build MR to be merged before the one for 102 desktop
15:18:38 <PieroV> richard: it could be. But also I'd like to check if GeckoView has some preferences that weren't added to desktop files. Both in the shared preferences, and in the mobile preferences
15:18:55 <richard> ok
15:19:36 <PieroV> richard: anyway, do you thing we can merge tor-browser!337, and then proceed with fixups, or would you prefer to wait until everything has been fixed?
15:20:35 <richard> yeah that sounds good to me
15:21:07 <PieroV> Which one? :)
15:21:29 <richard> sorry, i'm ok with comitting and doing subsequent fixups
15:21:45 <Jeremy_Rand_Talos_> PieroV, switching to Mozilla Rust binaries will disrupt my ARM branch, but I can just not rebase it for a while if you want to get 102 into tor-browser-build ASAP.
15:22:35 <PieroV> Jeremy_Rand_Talos_: I'd switch to Rust binaries, not Mozilla's
15:23:00 <richard> so yeah, I'd like to get 102-based alphas going asap, and optimistically hope for an esr102 alpha release for end of aug/start of sept
15:23:01 <PieroV> Anyway, I'd still need to review that workaround, to enable it only on Linux
15:23:23 <PieroV> Err, about "esr", Mozilla still hasn't added an esr102 branch
15:23:37 <PieroV> To gecko-dev, I mean, they have one in hg.
15:23:44 <Jeremy_Rand_Talos_> PieroV, same thing for me :)  My branch assumes we're building Rust from source with custom build flags
15:24:12 <richard> and the sooner we can find and fix reproducibility issues the better
15:24:44 <richard> Pierov: yeah it's an open issue apparently, i don't see anything wrong with basing off of the hg branches
15:25:04 <PieroV> It will include a lot of history we already have
15:25:22 <PieroV> s/include/add/
15:26:09 <richard> ugh that is true
15:26:43 <PieroV> Unless the hg-git branch is smart enough to start from the newest common commit
15:27:31 <PieroV> err, sorry, I meant hg-git bridge
15:27:36 <richard> yeah
15:27:53 <richard> i'm not sure there's anything we can really do to fix that
15:28:36 <richard> anyway
15:28:52 <richard> donuts: i'll get an updated release schedule out today promise
15:29:03 <donuts> richard: ty <3
15:29:15 <richard> and re apple arm builds, that should be doable, last I checked we have a branch that gets it working we just haven't merged it yet
15:29:33 <Jeremy_Rand_Talos_> donuts: My linux-arm port is 32-bit, and Apple Silicon ARM chips only support 64-bit, but my port is designed intentionally to make additional linux-cross targets easy to add.
15:29:50 <Jeremy_Rand_Talos_> I recently got my hands on some ARM 64-bit hardware (PinePhone) so I should be able to do a linux-arm64 port once the linux-arm and linux-ppc64le/linux-ppc64 ports are merged.  I would exxpect that port to run fine on Apple Silicon, unless the Apple Silicon 16 KiB page size tickles some bugs.
15:30:00 <donuts> awesome! ok – let me know if there's anything I can do, I have an M1 mac I can do some ultra rudimentary testing on
15:30:03 <donuts> (like, designer level testing)
15:30:25 <donuts> Jeremy_Rand_Talos_: oooh good to know
15:30:34 <richard> there will be a bit of work needed to update the website to point to the arm mac builds too
15:30:46 <PieroV> Jeremy_Rand_Talos_: in my dream I'd love to compile Clang once for all platforms
15:31:09 <PieroV> If we add ARM maybe we can compile it for all ARM targets, including Linux, macOS and Android
15:31:11 <donuts> richard: right, it could be messy
15:31:27 <donuts> I'm planning to completely redesign /download but that won't be ready until end of Q4 at the earliest
15:31:41 <donuts> so maybe it'll just need to be messy until then
15:31:41 <richard> once we have 102 initially working/building we should get multi-locale builds working
15:31:50 <PieroV> was about to write it :)
15:31:52 <richard> because while i love supporting lots of hardware
15:32:13 <richard> yeah :)
15:32:33 <richard> ok
15:32:40 <richard> finally
15:33:04 <donuts> it would be super nice if Mac ARM and the new Mac application icon land at the same time
15:33:12 <donuts> our apple users will like that
15:33:28 <richard> nightly builds are broken, and incrementals have been broken for awhile (which is somewhat surprising given alpha worked fine)
15:33:54 <richard> so I think i'll be looking into that this week
15:34:12 <richard> alright let's move on to dan_b and ma1's entries :)
15:34:28 <richard> dan_b: how goes tor-browser#41075 ?
15:34:57 <dan_b> good
15:35:07 <dan_b> I think I found the issue friday
15:35:34 <dan_b> in SSLServerCertVerification.cpp
15:35:49 <richard> oh neat
15:35:52 <richard> not what i was expecting
15:36:07 <dan_b> looking to test this morning to see if I can force a fix or if it's reporting certerror but not the cause
15:36:44 <dan_b> but my next questions are: if it's there, do we have preferences for where to fix things? like at the root as often as possible so less side effects, or higher up in the code anywhere?
15:37:09 <dan_b> and secondly do I need to be looking at fixing this in an existing patch or will a new commit be ok?
15:37:24 <richard> ok
15:38:03 <richard> so in terms of 'where' to fix there are a couple of trade-offs I try to consider in these types of patches
15:38:41 <richard> so in general you'd want to fix things as close to the root cause of the problem as possible
15:39:03 <richard> but we're working on an ever shifting pile of code we don't control
15:39:36 <richard> so 'ease of rebasing' is maybe an equally important consideration
15:40:16 <dan_b> how does one determine what makes better rebase targets?
15:40:49 <dan_b> like if I can find somewhere we're already patching rather than adding a new point?
15:41:09 <richard> i think it kind of depends
15:41:19 <richard> one sort of heuristic is looking at the commit history for a potential fix location
15:41:41 <richard> if it's a fairly stable piece of code then that's better than something with a lot of churn
15:41:47 <dan_b> cool!
15:42:40 <richard> as you can imagine, the UX parts of the onion communication expectations patch (that adds the onion icons) has probably had to be fixed with each rebase as mozilla fucks around with the idenity-block
15:43:02 <dan_b> right
15:44:13 <richard> but really it varies from patch to patch and we can hash i tout in review
15:44:17 <PieroV> in my experience, adding is always better than removing/replacing
15:44:18 <richard> in terms of new commit vs fixups
15:44:31 <richard> ^ true
15:44:46 <PieroV> removing will lead to conflicts
15:44:52 <dan_b> ok cool. Well, once I confirm I have the right location I can start looking at what fix will look like and ask more questions :)
15:45:08 <PieroV> So, adding some ifdefs is better. It will lead to conflicts anyway, but they're usually easier to fix
15:45:43 <richard> in general too, in the JS layer we sort of have converted to a sort of pattern for adding new major functionality (see the TorSettings, TorConnect, commits)
15:45:59 <richard> converged to*
15:45:59 <PieroV> (I tend to try to accept all Moz changes and then reapply ours when rebasing, so I prefer add things because it's easier with this workflow)
15:46:54 <richard> ok re commits vs fixups
15:47:23 <richard> if it is an 'upliftable' bug (ie if it's an underlying issue in firefox) we tend to keep them as separate individual commits
15:47:58 <richard> which get shuffled to early to the 'base-browser' section of tor-browser.git after the monthly rebase
15:48:46 <richard> if we're fixing an issue in on of our added components (so the TorSettings module for example) then we'd commit that as a fixup! to that feature's commit, which get's autosquashed during the monthly rebase
15:49:41 <richard> so which route we go with your particular patch depends on which bucket the fix falls into
15:50:00 <PieroV> See also this comment to understand how patches are ordered: https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/242#note_2769048
15:50:16 <dan_b> cool! thanks
15:50:37 <richard> oh a good comment indeed :3
15:51:08 <richard> ok finally
15:51:10 <richard> ma1!
15:51:30 <ma1> Ehy, so: I've got the backend of the anti-leak feature ready.
15:52:07 <ma1> I hoped to come here with a working beta, but was slowed down by an on-the-fly (literally!) XSS filter fix release ( https://twitter.com/ma1/status/1556570471948292097 )
15:52:49 <richard> lol
15:52:50 <ma1> OTH, I get this chance to ask for suggestions about the UX aspects.
15:53:05 <richard> donuts^
15:53:39 <ma1> In their paper they talk about exceptions for "legitimate use cases like ads and trackers" (sic!), but I'm more concerned about popup-based oAuth workflows.
15:53:52 <richard> mmhm
15:55:05 <ma1> Anyway, I'm surely going to limit the feature to private browsing windows (i.e. all the TB ones, right?) and strip cookes from any request in tabs that have been opened or or opened other tabs cross-site.
15:55:35 <PieroV> ma1: the default configuration for TBB is to have only PBM
15:55:45 <PieroV> But some users tend to disable this setting
15:56:15 <richard> yes
15:56:18 <ma1> Indeed. If you think tor browser / incognito users are likely to perfom oAuth in their "private" sessions, some kind of warning and "disable for this transaction" interaction should be included.
15:57:11 <PieroV> btw, is it something related to tor-browser#14085?
15:58:06 <ma1> PieroV: no, but I'm taking note to look into that as well.
15:58:15 <PieroV> (I think we'll have to continue on #tor-browser-dev)
15:58:23 <richard> yes we have 1 minute
15:58:32 <ma1> OK.
15:58:42 <richard> let's migrate!
15:58:46 <richard> #endmeeting