14:59:34 <richard> #startmeeting Tor Browser Weekly Meeting 2023-02-27
14:59:34 <MeetBot> Meeting started Mon Feb 27 14:59:34 2023 UTC.  The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:34 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:59:48 <richard> #agreed
14:59:50 <RobertMin[m]> Hello!
14:59:53 <richard> pad per usual: https://pad.riseup.net/p/tor-tbb-keep
15:02:03 <richard> ok some quick announcements before i get out of the way of discussion
15:02:21 <richard> well i mean i guess it is waht it says on the pad
15:02:58 <richard> but tldr, I'm going to be doing weekly alpha builds/signing for s131/privacy-browser through the initial public release in march
15:03:21 <richard> and planning no weekly joint build reviews (first one after this meeting)
15:03:48 <PieroV> How are we versioning them?
15:04:19 <richard> so i called the last alpha 12.0a3, so that we have a nice transition from the 12.0 alpha series to 12.0 stable
15:04:31 <richard> (despite the build stuff being in main)
15:04:47 <richard> i figure i'll just increment the 12.0aN until initial release
15:06:13 <richard> this does cause *some* collisions that aren't particularly important (eg during signing it will auto-sync builders old sha256 sigs from the v legacy tor-browser 12.0 alpha series but that doesn't really matter since they are internal builds and aren't being published)
15:07:44 <richard> boklm: i'd also like to add privacy-browser to the nightlies and enable nightly updates so we can make sure we haven't accidentally broken the updater sooner rather than later
15:08:31 <boklm> hmm, I think it's difficult to add privacy-browser to nightlies because of the private repos
15:08:32 <richard> unless there's anything else pressing, I think i'll hand over to Jeremy since we kind of butted him and robert out last week and then hand it over to PieroV
15:09:01 <richard> hmm true
15:09:59 <Jeremy_Rand_36C3[m]> Sure, no worries about last week
15:10:02 <boklm> we can add base-browser nigthlies updates first
15:10:13 <richard> well maybe manual weekly alphas are sufficient
15:10:19 <richard> boklm: yeah let's def do that re base-browser
15:10:30 <richard> since the relevant machinery should be similar enough
15:13:05 <Jeremy_Rand_36C3[m]> So yeah, as you've probably heard, Robert Min has made some excellent progress on the proxy leak detector project, and I figured this would be a good chance for anyone here to ask him questions about the status etc.
15:13:32 <Jeremy_Rand_36C3[m]> The project has at least a couple of major use cases: (1) detecting proxy leaks in a CI setting, and (2) acting as a torsocks substitute.
15:14:45 <richard> could you give us a summary of what exactly it does, how it works, use cases, etc?
15:14:48 <Jeremy_Rand_36C3[m]> It's not quite production-ready yet (a few bugs to work out, the main one being a fork/clone-related bug in an upstream library that Robert Min is working on fixing) but we did successfully SOCKSify wget and curl
15:15:00 <boklm> is there a git repo for the project?
15:15:17 * Jeremy_Rand_36C3[m] hands over the floor to Robert Min
15:15:41 <richard> :)
15:18:05 <RobertMin[m]> Basically, the program detects and handles proxy leaks. The detection is done by analyzing syscalls to detect where the connections are sent. If the connection destination doesn't match our proxy, the connection is handles through different way such as logging the leak, blocking the connection, killing the application or redirecting the connection to the right destination (Our Proxy)
15:18:54 <richard> cool!
15:19:06 <ma1> ah, so it can act both as an instrumentation tool and as a "safety net" :)
15:19:29 <richard> Linux only?
15:19:48 <richard> and does it handle fork/child processes?
15:19:49 <RobertMin[m]> [The main repo](https://github.com/namecoin/heteronculous-horklump) (There is an issue with one of the imports used, so it's not yet updated. Should be fixed in about a week. [Current WIP](https://github.com/robertmin1/heteronculous-horklump))
15:19:50 <slacktopus-test> 12[slack] <github> signin
15:20:36 <Jeremy_Rand_36C3[m]> (did the inline links come through on IRC just now?)
15:20:42 <Jeremy_Rand_36C3[m]> Not sure how smart the Matrix/IRC bridge is
15:20:55 <richard> we got markdown (so yeah we got the links)
15:21:05 <dan_b> so this is an external program you have monitor the tor-browser process?
15:21:05 <Jeremy_Rand_36C3[m]> OK cool
15:22:22 <RobertMin[m]> Yes, Linux only since we are using syscalls. Currently, we are working on the fork/child processes, since u-root doesn't seem to handle them correctly
15:23:52 <RobertMin[m]> s/using/manipulating/
15:24:24 <richard> ok neat
15:25:17 <Jeremy_Rand_36C3[m]> Given that ptrace is theoretically a thing on macOS, it might theoretically be possible to do something similar on macOS, but we haven't expended any effort on investigating that
15:25:18 <Jeremy_Rand_36C3[m]> as Robert Min says, it's currently Linux only and probably will stay that way since that's what we care about (but if some third party dev wants to contribute macOS support, we might merge it as long as it doesn't make the code too messy)
15:26:02 <richard> what about windows? no interest in intercepting ntdll.dll calls? :D
15:26:30 <richard> anyway this looks like it could be a useful tool, esp for automated testing
15:26:35 <richard> will def keep an eye on it
15:26:56 <richard> PieroV: shall we move on to your section?
15:26:59 <Jeremy_Rand_36C3[m]> richard: so, Windows doesn't actually allow userspace programs to issue syscalls, all syscalls need to be issued by Microsoft dll's. As a result, LD_PRELOAD approaches (like what torsocks does) are optimal on Windows
15:27:44 <PieroV> I can go if Jeremy and Robert are done (and nice job :))
15:27:52 <Jeremy_Rand_36C3[m]> Or rather, similar to LD_PRELOAD in the sense that it would intercept library calls rather than syscalls -- LD_PRELOAD itself doesn't exist on Windows
15:27:58 <richard> jeremy: I admit I'm a bit out of the loop of windows internals these days
15:28:05 <richard> right right :)
15:28:18 <PieroV> A while ago I found a tool to simulate network problems
15:28:28 <PieroV> Such as increased RTT and other amenities
15:28:32 <PieroV> For Windows. IIRC it was open source
15:28:43 <Jeremy_Rand_36C3[m]> richard: Windows actually randomizes the syscall number list every service pack AFAIK, so any application that issues syscalls directly will stop working when Microsoft ships an update
15:28:53 <Jeremy_Rand_36C3[m]> It's how they force app devs to use the dll's
15:29:06 <PieroV> https://jagt.github.io/clumsy/
15:29:30 <PieroV> I wonder they do something that could help us, too
15:29:42 <richard> oh that's cool, especially if it implies that ntdll.dll's interface is stable now
15:29:55 <richard> PieroV: ok now that's a cool tool
15:30:39 <PieroV> And it seems that actually they use a library called divert/windivert
15:30:46 <richard> anway good job robert :)
15:31:09 <ma1> Cool stuff RobertMin[m] !
15:31:13 <Jeremy_Rand_36C3[m]> Anyways -- Robert Min 's tool doesn't work properly with Firefox right now because of the aforementioned fork/clone bug that we're working on fixing, but once that's resolved, it might be interesting to use in Tor Browser's CI tests or something
15:31:31 <richard> ^agreed
15:31:34 <Jeremy_Rand_36C3[m]> (though I'm aware that Tor Browser's CI tests are very much an in-flux thing)
15:31:53 <RobertMin[m]> Thanks!
15:33:45 <RobertMin[m]> Yes! Once the fork/clone bug is handled, it will be much easier to find nice use cases.
15:34:25 <Jeremy_Rand_36C3[m]> One of the interesting use cases is that the SOCKSification handles SOCKS5 username/password more flexibly
15:35:43 <Jeremy_Rand_36C3[m]> E.g. you can have it generate 10x SOCKS5 auth slots, and each TCP connection will randomly go over one of them. So if you have a P2P app (say, a Bitcoin seeder) that needs to avoid Sybil attacks but also doesn't want to make every TCP connection use its own circuit (to avoid DoSing the Tor network), this is a pretty easy way to do it.
15:37:38 <Jeremy_Rand_36C3[m]> Also a side affect of using ptrace instead of LD_PRELOAD is that statically linked programs work fine, which should be very useful for Go software
15:38:45 <Jeremy_Rand_36C3[m]> And speaking of Go, all the code here is Go, so it's memory safe, securely bootstrappable, and we avoid manually messing with the memory space of the tracee whenever possible
15:39:03 <PieroV> it's memory safe <-- small lie :)
15:39:16 <richard> :p
15:39:20 <PieroV> It's safe from leaks, but Go can crash because of dereferenced nulls too :P
15:39:49 <richard> ok re tor-browser#41654
15:39:53 <Jeremy_Rand_36C3[m]> (We use the "pidfd" feature of recent Linux versions to extract file descriptors of the tracee instead of messing with buffers inside the tracee)
15:40:29 <Jeremy_Rand_36C3[m]> Anyway yeah, if there are no further questions, we can move on :)
15:40:45 <richard> i had a look at this a bit this morning and didn't see any obvious breakage, seems like the dir is just where the updater downloads/stores data related to the update
15:41:00 <richard> what does macOS do?
15:41:07 <PieroV> Yep. But still I'm not sure on how we want to treat that directory
15:41:12 <RobertMin[m]> The only small issue with pidfd is it requires Linux 5.13
15:41:23 <PieroV> macOS adds it to the profile directory
15:41:30 <richard> (I presume it's different because tor browser lives in /Applications)
15:41:35 <Jeremy_Rand_36C3[m]> I think it's Linux 5.6, no?
15:41:35 <PieroV> But I don't know if that's because of signatures
15:41:43 <PieroV> richard: yes, I think so
15:43:40 <richard> it *seems* like something like that should live in the cross-platform equivalent of C:/ProgramData
15:43:42 <richard> since it's not user-specific
15:43:56 <PieroV> Well, for Tor Browser everything is user-specific
15:44:09 <PieroV> What does Firefox do?
15:45:23 <richard> vOv
15:45:38 <richard> or even /tmp if the data doesn't need to be persistent
15:45:49 <richard> but anyway
15:46:14 <richard> if we want to be safe we should probably fix the location before the next alpha
15:47:37 <PieroV> ack. I think we can discuss offline in the issue, in case
15:48:16 <richard> and re tor-browser#41629 let's plan coming back to ripping it out after 12.5a4 (so say in April)
15:48:25 <richard> disabling it by pref is fine for now
15:48:46 <PieroV> Yeah, so, if people haven't read the backlog
15:49:18 <PieroV> I think that since nobody found that this doesn't work for years, trying to get it back to work could not be the best choice
15:49:48 <PieroV> Event though having it working for us would be great, it isn't the best for long term
15:50:05 <PieroV> Since we could have additional regressions, in addition to the ones we already found
15:50:19 <PieroV> It was intended to go away, but it half remained
15:50:42 * ma1 is very scared of regressions lately
15:51:06 <PieroV> So, I think of withdrawing my patch from Moz and maybe do the opposite (i.e., rip it off)
15:51:11 <PieroV> Anyone against this?
15:51:23 <ma1> i.e. keeping the status quo?
15:52:22 <PieroV> Keeping the status quo, but also reminding Mozilla that it's possibly broken code
15:52:27 <PieroV> And remove it
15:52:43 <richard> perhaps we should try again after 12.5, and also uplift tests so they have to maintain it :D
15:52:44 <PieroV> (if you try AppConstant.MOZ_SERVICES_SYNC on Firefox, you'll get false, even though it is enabled)
15:53:25 <henry-x> what does SERVICES_SYNC control?
15:53:42 <PieroV> Whether some js files should be included in the build
15:54:06 <PieroV> But the codebase takes for granted that these files are actually always available
15:54:21 <PieroV> Because of https://bugzilla.mozilla.org/show_bug.cgi?id=1227361
15:54:51 <PieroV> That's a bug from 7 years ago, but I think it missed several usages of that macro
15:55:26 <ma1> So it's just a remnant of when you could actually compile firefox without sync
15:56:12 <PieroV> Yes
15:56:38 <richard> it still seems worth disabling in the future to me vOv
15:57:03 <richard> but perhaps early in an alpha cycle
15:57:03 <PieroV> Okay, then I'll just comment to say that it introduces more breakage than expected
15:57:13 <PieroV> So stop the process upstream
15:57:22 <richard> ack
15:57:22 <PieroV> I had a final point
15:57:25 <richard> and finally rlbox
15:57:26 <PieroV> What to do with RLBox?
15:57:27 <richard> w/ 1 minute
15:57:43 <PieroV> Should we start checking build problems?
15:57:57 <PieroV> And possibly get it for 12.5a4?
15:58:00 <PieroV> Or 13.0?
15:58:23 <richard> let's aim for 12.5a5 I think
15:58:32 <PieroV> okay, I  think we can continue later
15:58:38 <PieroV> Since there's another meeting here now
15:58:39 <richard> unless we run out of work between now and then ;)
15:58:42 <richard> anyway thats' the hour
15:58:45 <richard> later everyone~!
15:58:47 <PieroV> Later!
15:58:47 <richard> #endmeeting