15:01:01 <morganava> #startmeeting Tor Browser Weekly Meeting 2024-12-02
15:01:01 <MeetBot> Meeting started Mon Dec  2 15:01:01 2024 UTC.  The chair is morganava. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:04 <morganava> welcome
15:01:10 <morganava> to december
15:01:35 <morganava> pad us usual, please update with your todos and todones, etc: https://pad.riseup.net/p/tor-tbb-keep#L254
15:06:22 <henry-x> FYI: I'm going to be away next monday and tuesday. And there's a chance I might be away at times for the rest of next week as well
15:06:34 <bellatchau> o/
15:07:37 <bellatchau> aaaaah december, rainy days
15:07:51 <boklm> o/
15:08:27 <morganava> henry-x: ack
15:08:29 <morganava> ok
15:08:58 <morganava> if i'm understanding calendars right, we don't have a release this week, or a rebase
15:09:26 <PieroV> No more releases until the next year
15:09:44 <PieroV> There are 6 weeks between 128.5 and 128.6
15:09:56 <morganava> amazing
15:10:00 <ma1> ESR holydays
15:10:10 <PieroV> Which is a lot, and possibly a reason for which we have one less RR version between the two ESRs
15:11:36 <morganava> my top priority for this week (apart from various grant proposals floating around) then is 14.5 stuff, specifically the rapid-release processes (code-audits, rebses, etc) and assigning issues out related to that, and following through on the plans from the release meeting last week re: labelling in milestones
15:11:51 <morganava> donuts has already started putting things in the 14.5 Milestone
15:12:02 <bellatchau> <3
15:12:32 <morganava> which you can find here -> https://gitlab.torproject.org/groups/tpo/applications/-/issues/?sort=updated_desc&state=opened&milestone_title=Tor%20Browser%2014.5&first_page_size=100
15:14:39 <morganava> it looks like we have a discussion point just added, so lets move on to that
15:14:45 <donuts> i have indeed :)
15:14:49 <morganava> specfiically: Thoughts about making tor dependencies static?
15:15:09 <PieroV> I have a couple of MRs that I kept drafted even though boklm approved them
15:15:30 <PieroV> To limit the LD_LIBRARY_PATH changes to the tor process, rather than the entire browser
15:16:09 <PieroV> I don't mind dynamic libs + LD_LIBRARY_PATH
15:16:26 <PieroV> But if we decide to go on the static libs route I'll close the MRs
15:17:30 <morganava> so basically, c-tor has various dependencies which we ship as shared libraries on some platforms (openssl, libevent, etc)
15:18:31 <morganava> which has caused some issues in the past becuse our launcher script (on Linux) tells firefox and its child processes to use our packaged shared libraries I guess under the theory that they are the most recent/up-to-date
15:19:10 <morganava> PieroV's current MR chagnes that logic to only make tor use our packaged libs rather than all of Tor Browser
15:19:16 <morganava> which woudl fix the problem
15:20:01 <morganava> however, compilng these dependencies as static libs would also solve the problem (i.e. openssl, libevent, and friends would be built directly into c-tor without *any* shared libs so tor could just run on its own)
15:20:47 <morganava> I don't have any intuition as to which approach is *better* per se, thougoh the current LD_LIBRARY_PATH patch is probably smaller/more surgical
15:21:10 <boklm> compiling as static libs sounds fine, although that might take more time to do
15:21:12 <morganava> whereas the static lib appraoch requires udpating build flags in tor's various dependencies in tor-browser-build
15:21:34 <morganava> there *is* prior art here in ricochet-build
15:21:35 <PieroV> We might have some problems if there are other libs we pull from the system
15:21:43 <PieroV> But I think we'd only load libc at that point
15:21:53 <morganava> (as this is how ricochet refresh's tor is built)
15:22:37 <boklm> ah, so that should make it easier
15:23:11 <boklm> if we already know it works fine
15:23:23 <morganava> here's the ldd output for ricochet-refresh's tor: https://share.riseup.net/#0wqtznUC3w124f-mYeUu0w
15:25:11 <morganava> hmm
15:25:18 <dan_b> oh if we're talking about fiddling with the expert bundle, can we have it ship the unversal binary for mac instead of two seperate arm64 and amd64 ones? cus I'm not sure anyones gonna want to use those.
15:25:57 <dan_b> i didn't. updated cwtch's tor, and had to rip the unified binary from TB instead of use that expert bundle
15:26:28 <morganava> I'm using those for ricochet-refresh since we ship separate x86_64  and amd64 dmgs
15:26:38 <PieroV> We're using Firefox's source code for merging the binaries
15:27:13 <PieroV> So, we have a dependency on the source code. But maybe we can add that to the expert bundle as well
15:27:35 <morganava> is that merging tooling available somewhat standalone?
15:27:41 <boklm> dan_b: how do you merge the other binaries from cwtch?
15:28:02 <PieroV> morganava: I don't know the details, maybe we can also do without that
15:28:22 <PieroV> Maybe the source/tools are used for other browser needs
15:28:38 <PieroV> And we can use something else from the toolchain we already have
15:28:57 <dan_b> boklm: i didnt have to? cwtch only ships x64 linux, x64 windows. and for android, yeah I just fetech the arm7 and arm8 libs and place them in their respective arch named jni folders
15:29:30 <dan_b> oh you mean our other deps?
15:29:49 <boklm> dan_b: I mean the other binaries included in cwtch for macos
15:31:17 <boklm> morganava: we use tor-browser.git/toolkit/mozapps/installer/unify.py
15:32:52 <boklm> but for simple binaries maybe we don't need that script
15:33:18 <morganava> yeah i would need to dig into that and see how it actually works
15:33:52 <morganava> though i suppose it lookslike either me or dan_b is going to need to do it if both of us are going to use the bundle
15:34:18 <dan_b> boklm: flutter generates a unified binary for us, but you're right, our go library we ship as two archs. it's on my todo to learn how oto combine so thanks for the tip. i only asked cus I knew from work here that we had a unified tor already
15:35:10 <PieroV> Regarding the static vs. dynamic, can we merge the MRs and think about this sometimes in the future, or should we prioritize the static thing?
15:35:50 <morganava> let's merge your MRs for now to unbreak gentoo and friends
15:36:05 <morganava> and then do the static thing sometime later in the 14.5 release cycle
15:36:15 <morganava> it feels like a nice 'intro to tor-browser-build' task
15:36:52 <morganava> so maybe a good low-priority side-project for clairehurst?
15:40:01 <clairehurst> sounds good!
15:43:26 <morganava> PieroV: re your ? in your section, please prioritize patch healththis week, and lets plan on a planning/roadmapping meeting for early next week
15:43:35 <PieroV> ack
15:43:37 <morganava> donuts, bellatchau^
15:44:20 <bellatchau> <3
15:44:22 <morganava> i'll send out a mail w/ a pad to facilitate gathering the dev priorities for 14.5
15:45:50 <morganava> oh also, I'll be assigning out bugzilla triage issues this week for the major releases since 128 this week and working on the other rapid-release related processes
15:48:11 <morganava> any other topics to cover this morning?
15:48:17 <morganava> otherwise we can end this :)
15:48:35 <brizental> i just want to let you all know i will be working from pacific time starting next monday until the holidays
15:48:44 <morganava> !!
15:48:50 <morganava> congrats/gl ;)
15:48:57 <morganava> :) * rather no winky
15:49:03 <brizental> lol i'm not moving or anything
15:49:08 <henry-x> I have one question
15:49:24 <morganava> mmhm
15:49:28 <dan_b> ha woo
15:50:10 <henry-x> what is happening with tor-browser!684
15:50:59 * morganava re-reaidng
15:51:02 <morganava> re-reading*
15:51:57 <morganava> ahhh
15:52:13 <henry-x> it is kind of blocking mullvad-browser#312, unless we don't care about providing an obvious way to distinguish mullvad-browser nightly or alpha users
15:53:46 <morganava> how do these two issues interact with the other issue about have a formalised/supported way of detecting Tor/Mullvad Browser vs Firefox?
15:54:23 <henry-x> moreover, as-is, I think the patch would break how drop and TZP detect that the user is using Tor Browser
15:54:36 <henry-x> *drop -> securedrop
15:54:48 <morganava> right
15:55:03 <PieroV> I would be against making it too obvious though
15:56:09 <morganava> PieroV: the 'supported' detection you mean?
15:56:13 <PieroV> Yes
15:56:21 <henry-x> I don't have a strong opinion on this, since with enough work someone can detect your version by other means. I would personally just hide the `branding` assets from websites
15:56:36 <PieroV> At a certain point we were asked to create a document.isMullvadBrowser or something like this
15:56:37 <henry-x> and we can worry about the rest some other time
15:56:39 <PieroV> Thanks but not thanks
15:59:12 <morganava> so, it sounds like we should implement the allow-listed TB.css/MB.css thing for the unspoofable detection, merge something like tor-browser!684, and then drop mullvad-browser#312 entirely yeah?
15:59:34 <morganava> which would make everyone happy?
16:00:34 <morganava> well in any event we're out of time
16:00:41 <morganava> let's follow up offline
16:00:44 <morganava> #endmeeting