15:01:26 <morganava> #startmeeting Tor Browser Weekly Meeting 2024-10-28
15:01:26 <MeetBot> Meeting started Mon Oct 28 15:01:26 2024 UTC.  The chair is morganava. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:26 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:47 <boklm> o/
15:02:11 <Jeremy_Rand_Lab19[m]> Hi!
15:02:15 <morganava> the pad per usual: https://pad.riseup.net/p/tor-tbb-keep
15:02:16 <morganava> :D
15:02:20 <clairehurst> o/
15:03:12 <morganava> in case you missed it, Tor Browser 14.0 went out last week
15:03:14 <morganava> \o/
15:04:00 <morganava> judging from the mails/gitlab notifications over the weekend, it looks like the only major issue atm is a particular crash on macOS
15:04:15 <morganava> when attempting to connect to a valid but offline onion-service
15:04:23 <morganava> which is.. weird
15:04:24 <bellatchau> o/
15:04:34 <morganava> but at least reproducible
15:05:19 <PieroV> morganava: is it?
15:05:21 <morganava> has anyone looked into this yet?
15:05:32 <brizental> o/
15:05:42 <PieroV> morganava: as far as I can tell nina tried, but she couldn't
15:05:43 <brizental> (i haven't looked into it, i am just saying hello)
15:05:49 <morganava> PieroV: seems so? I remember reading in one of the places that it was consistent
15:05:58 <PieroV> (I don't know which version of macOS she's running)
15:06:18 <morganava> perhasp it was only consistent for that particular user/their configuration
15:06:19 <ma1> it's said to be consistently reproducible on MacOS 15 / M1
15:06:39 <ma1> (from the hackerone late report, with steps to reproduce)
15:06:48 <morganava> micah: and this right here is why we need real hardware sometimes^
15:07:23 <thorin> https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43250#note_3099858 - you need to ask if they're running stuff
15:08:02 <morganava> well, in other non-dev news, happy to report our CCC talk submission was submitted on time with a general topic of the tor browser dev cycle, ESR transition, etc
15:08:22 <morganava> so should be hearing about whether it was accepted by iirc Nov 11 or some similar date
15:08:45 <ma1> thorin, I've already closed their report as "informative" because we had an earlier public issue. Not sure if they're still in the mood to cooperate :P
15:08:49 * thorin has a mac 10.14 and is willing to update, for a price
15:08:55 <dan_b> 🤞
15:09:05 <PieroV> thorin: macOS 14, probably?
15:09:16 <PieroV> 10.14 is the unsupported one :)
15:09:23 <morganava> yeah i saw the h1 report and was like i've already heard about this on the bug tracker :p
15:09:28 <thorin> sorry
15:09:35 <thorin> yeah I meant 14
15:09:54 * dan_b loves mac os versioning
15:10:09 <morganava> indeed :p
15:11:32 <PieroV> Don't release builds output tor stdout even with -v?
15:12:02 <PieroV> In case it might be the time we move logs from outside the provider
15:12:12 <PieroV> * to outside
15:12:28 <morganava> who currently has an M1 mac available to potentially debug on?
15:12:37 <morganava> clairehrust and dan_b?
15:12:43 <morganava> clairehurst*
15:12:45 <PieroV> And possibly macOS 15
15:12:52 <morganava> right
15:13:19 <PieroV> Maybe Intel macOS is also good, as long as it has macOS 15
15:13:39 <morganava> i mean fortunately we only have the 1 patch which could reasonable cause a crash that I'm aware of (the custom SOCKS5 error code patch)
15:14:05 <morganava> but 1, it's weird it's mac only whcih I guess would imply it's happening somewhere far away from that patch
15:14:12 <Jeremy_Rand_Lab19[m]> morganava: see https://content.events.ccc.de/cfp/38c3-community-stages/ , deadline for submitting to a Community Stage (if you get rejected by the main track) is Nov 16.
15:14:19 <morganava> and also weird if it really is arm-specific
15:14:19 * dan_b waves
15:14:23 <morganava> jeremy: oh nice
15:14:26 <clairehurst> M2 here, but should still work?
15:14:29 <dan_b> i'm pretty sure my mac is up to 15?
15:14:37 <dan_b> let me double check
15:14:45 <catladyfelicia> o/ (sorry, forgot the time)
15:14:46 <PieroV> If I remember correctly, we don't customize the CFLAGS of tor... And sometimes I hit assertions
15:14:50 <clairehurst> Yeah I'm at 15.0.1
15:15:03 <Jeremy_Rand_Lab19[m]> morganava: CDC (the Cluster that includes Namecoin) is involved in the Community Stages CfP, so I think it's likely that your talk would get approved there if necessary
15:15:03 <morganava> clairehurst, dan_b: looks like y'all have an opportunity for some native macOS debugging :D
15:15:13 <ma1> in the meanwhile, shall I close the confidential bug as duplicate and dump the information into the earlier bug?
15:15:25 <dan_b> nope 14.4 currently
15:15:34 <PieroV> clairehurst: I think M2 is also okay
15:15:37 <morganava> ma1: yes please
15:16:14 <morganava> alright, a fix for this is not a blocker for 14.0.1 just FYI, happy to let this be a known issue in the blog post for now
15:16:46 <PieroV> The STR should be visiting an offline Onion service if I understand correctly (e.g., offlin4w6nrxjkyf7k6xpf2sw4lxbclih45ltwsiiouivksr6wgdulqd.onion)
15:16:58 <Jeremy_Rand_Lab19[m]> morganava: FWIW if we don't know what's causing the crash, there is a possibility that it's exploitable in other, less obvious ways
15:16:59 <thorin> there's 3 bugs
15:17:25 <PieroV> morganava: 14.0.1 has already been built, so I'm happy to hear it isn't a blocker :)
15:17:54 <thorin> ma1: would you consider 43249 also a dupe of 43245
15:18:14 <thorin> ok, ninja'ed
15:18:41 <morganava> also a reminder that the apps team is officially afk next week, I'll be keeping an eye on the mozilla emails so; if there's a chemspill I'll probably (try) to flag down another builder
15:19:02 <morganava> but we've already had our chemspill for the year so I'm sure it'll be fine
15:19:23 <morganava> PieroV: you people are getting too on top of things
15:19:25 <ma1> thorin, okey dokey
15:19:28 <dan_b> ok looks like i can prolly manualkly trigger the macos 15 upgrade on my m1 if we want?
15:19:28 <morganava> :p
15:19:57 <morganava> dan_b: I'd say try to repro first on w/e OS you ocurrently have and upgrade if it's a no-repro
15:20:11 <dan_b> ok
15:20:33 <dan_b> is it m1 specific or will clairehurst's m2 work?
15:20:53 <morganava> dan_b: I don't think we  know for sure yet
15:20:54 <PieroV> (disregard my str from earlier)
15:21:11 <morganava> it may repro on x86_64 but we don't know yet
15:21:37 <morganava> unless there's been any new info in overnight
15:23:04 <morganava> PieroV: Looks like you've a discussion point on non-build tools
15:23:29 <PieroV> morganava: yeah, as I said a while ago, I think we could create a repo for useful tools
15:23:37 <PieroV> E.g., the scripts to tag browsers
15:23:49 <clairehurst> I bet it's more to do with arm, I haven't had any issues with M1 vs M2 before, but quite a lot with arm vs arch64
15:23:59 <PieroV> Keeping stuff on tor-browser.gitsometimes is a bit awkward
15:24:21 <morganava> due to the branching between base/tor/mullvad?
15:24:25 <PieroV> Yeah
15:24:32 <boklm> would using tor-browser-build.git/tools for those scripts work?
15:24:41 <morganava> yeah i ran into that with the tag/signing patch
15:24:54 <PieroV> boklm: I think it would be better than using tor-browser.git for sure
15:25:05 <PieroV> I don't have a strong opinion on tor-browser-build vs. dedicated repository
15:25:24 <PieroV> I have also some other stuff I could share (well, it's already public in my scripts repo)
15:25:51 <PieroV> E.g., a script for repacking and signing APKs without building, which is useful for testing JS patches
15:27:08 <boklm> as we already have a few scripts there I think it makes sense to add those new scripts there too, unless we have some reason to want them in a separate repo
15:27:28 <morganava> so if the scripts don't live in the repo they operate on, it becomes a bit awkward having to somehow point them to the relevant root
15:28:09 <morganava> problem exists for instance with the blog generation script, you need to update one of the tools/signnig/set-config files
15:28:42 <boklm> yes
15:28:53 <morganava> I dno't have a strong opinion of where the scripts live, but i think having them in one place is a good idea for consistency and discverability
15:29:19 <morganava> and hopefully for sharing some of the relevant functionality (setting relevant diectory roots mostly) between them
15:30:07 <morganava> in theory if the scripts live in tor-browser-build but operate on tor/mullvad browser they *could* do so through git_clones (if you add a pushable remote)
15:30:36 <PieroV> For some scripts you could just run them in the root of the repo
15:30:37 <boklm> we could have some tools/browser/set-config file shared by the scripts operating on tor-browser.git
15:31:01 <PieroV> That's what I do in a few scripts (you're expected to call them from the right directory)
15:31:20 <PieroV> But also what boklm says, we do that for example with the GeckoView build tools
15:31:28 <PieroV> (you need to define your env file with your custom paths)
15:32:34 <morganava> boklm: the only annoying part about the set-config setup intor-browser-build is that you need to either manually re-populate these files when switching branches or just have custom branches with main/maint-13.5/etc with a patch that sits on top whcih updates all the relevant pieces
15:33:31 <PieroV> That script would need to be in .gitignore
15:33:40 <boklm> yes, sometimes it can be annoying with conflicts when the default config file changes
15:37:33 <dan_b> we can also ship a .example version of settings like in tools/geckoview/android-env-linux-template.sh that has to be copied to the .gitignored android-env.sh
15:37:41 <morganava> I *really* like the soft-link track using the browser name at the end to speify which thing to operateon
15:37:52 <dan_b> and our scripts fail if it settings file hasnt been created
15:37:58 <morganava> specify which thing to operate on
15:38:29 <morganava> so we could re-use that for scripts living in tools/browser which may have per-browser logic
15:38:46 <boklm> yes
15:38:46 <morganava> soft-link trick*
15:38:54 <PieroV> morganava: if jwilde is supposed to use those she might have issues I guess?
15:39:08 <PieroV> Don't softlink still require admin privileges on Windows?
15:39:13 <morganava> nope
15:39:26 <morganava> but also tor-browser-build is pretty linux specific
15:39:43 <boklm> will any of those scripts work on windows?
15:39:50 <morganava> exactly :p
15:39:53 <jwilde> yeah, there's little hope of getting tbb working in Windows for a myriad of other reasons
15:40:12 <jwilde> years worth of dormant perl and perl library bugs for starters :P
15:40:19 <ma1> wls
15:40:24 <ma1> (kidding)
15:40:32 <morganava> i mean yes though^
15:40:52 <morganava> WLS is basically just a linux VM with windows integration now isn't it?
15:41:23 <jwilde> I think there's some things missing but I could try it!
15:41:26 <Jeremy_Rand_Lab19[m]> Personally I liked it better back when it was literally GNU/Windows
15:41:32 <boklm> WLS might support symlinks
15:41:48 <Jeremy_Rand_Lab19[m]> If nothing else because the very concept of GNU/Windows is hilarious
15:42:12 <morganava> jeremy: back when they implemented the linux syscalls in the Windows kernel you mean?
15:42:18 <Jeremy_Rand_Lab19[m]> But yeah I'd be kinda surprised if WSL2 can't handle it
15:42:31 <morganava> it's a shame they abandoned that but I suppose it was probably the 'right' engineer decision in many ways
15:42:37 <morganava> but unfortunate
15:42:45 <Jeremy_Rand_Lab19[m]> morganava: IIRC WSL1 was basically a shim between the Linux and Windows kernels, so the GNU userspace ran without modifications
15:42:52 <Jeremy_Rand_Lab19[m]> kernel API's I mean
15:42:55 <morganava> mmhm
15:42:57 <Jeremy_Rand_Lab19[m]> there was no Linux running there at all
15:43:02 <morganava> righ texactly
15:43:09 <morganava> it was a native re-implementation
15:43:13 <Jeremy_Rand_Lab19[m]> Such a cool design
15:43:16 <Jeremy_Rand_Lab19[m]> Very sad it died
15:43:34 <morganava> iirc fork() was somehow impossible to do in NT for w/e reason
15:43:38 <morganava> but who knows ancient history at this point
15:43:57 <morganava> ok right
15:44:07 <Jeremy_Rand_Lab19[m]> One of my university classmates worked at Microsoft for a summer working on Windows kernel things
15:44:11 <Jeremy_Rand_Lab19[m]> the horror stories he tells...
15:44:19 <morganava> so I think this is somehow workable
15:44:39 <morganava> scritps in tor-browser-build/tools/browser (or other projects in the future)
15:45:27 <morganava> we can use a similar .gitignore'd conf and conf.example similar to rbm.local.conf scheme
15:45:49 <morganava> and browser-specific things can be done via similar symlink tricks as we use in tools/signing
15:45:56 <boklm> yes
15:46:28 <morganava> probably a bike-shedding question
15:46:43 <morganava> but do we *particularly* care about scripting language used?
15:46:49 <boklm> maybe selecting tor-browser.git directory can be done using a symlink instead of a config file
15:47:27 <morganava> oh so you just symlink tor-browser into the scripts dir?
15:47:36 <boklm> yes
15:47:49 <boklm> that way it can work with any language
15:49:20 <morganava> works for me
15:49:48 <morganava> also we should have a README for that dir that docuoments what the various scripts do
15:49:52 <dan_b> what scripting languages are we voting from? perl, shell, python and?
15:50:14 <ma1> node.js ? :P
15:50:15 <morganava> dan_b: i reckon that's probably it?
15:50:34 <morganava> Rust :p
15:51:02 <boklm> for example tools/browser/tor-browser would be a symlink to tor-browser.git
15:51:23 <dan_b> shell where possible would be my vote. i haven't dont a ton of python but it does seem to occasionally get wonky between versions. as much as i haven't done much perl in eons, it's... very stable now lol
15:52:15 <morganava> tbh i'm fine with w/e tool makes the most sense for the job, we have a lot of v useful python scripts :D
15:52:20 <dan_b> jwilde: any of those 3 make you more nervous than the others when thining about running on windows?
15:52:37 <PieroV> +1 for the tool for the job
15:52:42 <morganava> so long as people are fine with potentially needing to debug scripts they don't know the language flulently of :p
15:52:43 <dan_b> or we can get more chaotic: lua
15:52:59 <morganava> :p
15:53:44 <morganava> ok I think I love this
15:53:53 <morganava> i'll move my signing script MR over sometime this week
15:54:03 <jwilde> +1 for the tool for the job as well, and for running on windows I'd say not perl
15:54:13 <dan_b> i'm really bummed out about go's shift from compile in dir, to dir is a project needing a .mod file and etc, it really made it a lot harder to use go for small scripty sys admin tasks, which was definatly something some folks were doing some years ago
15:54:42 <dan_b> not that there weren't a lot of good reasons for it, but it really made doing scripting like work with go a bit more akward
15:54:52 <morganava> ok and one last point from me I almost forgot
15:55:06 <dan_b> oh really? perl's the hard one for windows? fascinating. ok noted! thanks!
15:55:19 <morganava> we have working testbuidls with working WebRTC on Windows for Mullvad Browser
15:55:46 <morganava> jwilde: how goes the last WeakReference.idl work?
15:56:18 <jwilde> good!! I'm cooking up a build now that I'm hoping will be my last for this
15:56:36 <morganava> inshallah
15:57:11 <jwilde> pls everyone cross your fingers that widl has been kind to me lol
15:57:13 <morganava> please push your latest clean branches for this to the open MRs so we can hopefully review and get into nightly at the end of this week
15:57:22 <jwilde> o7
15:57:43 <morganava> widl would never miss entire features-sets found in midl don't worry ;)
15:58:22 <morganava> ok 2 minutes, any other last minute comments or complaints?
15:58:33 <morganava> otherwise have a great week everyone :)
15:59:01 <ma1> you too
15:59:46 <morganava> clairehurst, dan_b: please prioritise repro'ing/debugging that macOS crash, I'll cc you to the relevant bug(s) after the meeting
16:00:00 <morganava> #endmeeting