15:01:08 #startmeeting Tor Browser Weekly Meeting 2024-10-15 15:01:08 Meeting started Tue Oct 15 15:01:08 2024 UTC. The chair is morganava. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:08 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:01:23 the pad per usual -> https://pad.riseup.net/p/tor-tbb-keep#L254 15:02:04 yesterday we had an unexpected stable Android release because we discovered it was missing the latest firefox-android tags 15:02:28 so 13.5.8 is out and published and should be makings its way to devices this week 15:02:57 forutnately this *particular* problem won't happen again since we have combined desktop and android repos in the 14.0+ release channel 15:03:29 We can also update the relprep script to tell you that the tag doesn't match HEA 15:03:31 HEAD 15:03:37 o/ 15:03:56 i think it's harder now with the 14/13.5 overlap cus we're more used to not worrying about in 14.0 15:04:03 PieroV: yeah I think we should do this for each of our tagged repos 15:05:00 dan_b: yeah that's exactly what happened 15:05:14 so tor-browser and mullvad-browser basically 15:07:11 in any event, our high priority this week is resolving the Tor Browser 14.0 QA issues -> https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42755 15:07:34 in particular the desktop and android release candidate test pass for each of our shipped platforms 15:08:07 o/ 15:08:27 i'm planning on release-prepping 14.0 toady/tomorrow with the intention of releasing next Monday, barring any show stoppers discovered this week 15:08:29 donuts^ 15:09:43 * PieroV started doing QA 15:10:04 I've updated my onion-tests pages to include more resources for QA: https://onion-tests.pierov.org/ 15:10:24 this will be for Tor Browser only, we'll plan to delay Mullvad Browser's 14.0 release until after the WebRTC patches are cleaned up and merged 15:10:29 jwilde^ 15:11:19 o7 15:11:29 ^^; 15:11:31 o7 15:12:43 once 14.0 is out the door and we've had a little break, we'll be back to our regularly scheduled programming and start the 14.5 cycle 15:13:25 the major difference this time around will be that we'll be doing (at least) the rapid-release security audits throughout the year as releases become available to us, rather than cramming it all in next summer 15:13:54 god willing anyway 15:14:27 alright, i think those are the relevant updates from me, happy to cede the floor to other discussion points :) 15:16:04 how are folks getting assigned/picking arches/browsers to test? 15:16:45 I can grab Android, if it's just volunteering. 15:16:51 in the past I think we've just volunteered based on our available platforms/VMs 15:17:11 I took Linux i686 for now, since I have an i686 VM just for testing already 15:17:37 i'll plan to evaluate what's missing after tomorrow and potentially reach out to people with availability 15:17:53 And I've got an Intel macbook, if it's of interest 15:17:55 *ideally* it would be good if we could get at least one passthrough for each desktop os/architecture pair 15:17:57 cool 15:18:22 I have also Android stuff, even though my emulator might be broken 15:18:26 After the Android Studio update 15:18:34 though given past precedent I think for desktop macOS is probably the most flakey/likely to be broken 15:18:44 between x86_64 and aarch64 15:18:58 but i've been wrong before :p 15:19:43 i've got an arm macos mini so i can start there 15:20:05 I have several Windows VMs 15:20:13 I can take Windows after the meeting 15:22:46 brilliant 15:23:07 does anyone else have topics or things blocking them they could use help with/attention on? 15:23:10 Yes 15:23:15 Several 15:23:20 hit it 15:23:29 First, as stated above, you can find several resources in onion-tests.pierov.org 15:23:50 Which should be easier to type than the GitLab issue with the links :) 15:23:58 * ma1 claps <3 15:24:12 :) 15:24:25 Then, we've had a confirmation that the Samsung device likes TCP sockets for SOCKS more than the Unix sockets 15:24:55 Even though it's probably using Unix sockets for the control port without problems 15:25:11 We have some decisions to make 15:26:10 Like: Android docs itself suggests to use Unix sockets, they're less of a linkability problem, etc... So, can we keep them by default and add the option to choose TCP sockets? 15:26:52 can you summarise the issue w/ Samsung devices? Does TCP just not work at all for the SOCKS5 proxy for whatever reason, or is it just flakey? 15:27:03 how does the uexer experience differ from 13.5? 15:27:04 Also, should we use hardcoded ports with their limits, or should we implement the feature to let tor choose them even though c-tor is in maintenance status now? 15:27:11 morganava: this problem is with 13.5 15:27:45 and presumably also 14.0 then 15:27:47 And a minority of Samsung users, I believe 15:27:49 https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42714 15:27:55 cool cool fun 15:28:44 what does Orbot do, how does it work on these devices? 15:28:57 Anyway, I left the questions also there, I just wanted to tell about the feedback, in case we need for the 14.0 launch 15:29:18 morganava: orbot uses TCP sockets because it's supposed to be shared between different apps 15:29:44 right but I mean does it use a hard-coded port or doe sit let the OS decide and display to the user? 15:30:23 Hardcoded for SOCKS, the OS decides for control, and it used to be broken in nightly builds 15:31:00 (we had several issues about TBA being stuck at reading the control port address from a .txt file) 15:31:12 mmhm 15:31:37 ok given this is a minority of samsung users, I'm fine ignoring for 14.0 15:32:10 for 14.5 (Android at least, maybe desktop) we shoudl finally bite the bullet on switching to letting the OS decide 15:32:22 which will have the nice side-effect of concurrent tor browsers working on desktop 15:32:30 if we go that route 15:32:33 Maybe we can backport 15:32:38 or bridging to Tor VPN #scifi 15:32:50 Esp. if we get the feedback of new users from the 14.0 launch 15:32:52 ma1: yeah that's the long-term goal 15:33:13 (maybe that could help also to understand why it's happening only in some devices) 15:33:22 i mean at *some* point the user workflow of piggy-backing off of Tor Browser's tor is going to break, way or another 15:33:58 PieroV: yeah I'd be fine with backporting once we're happy with it 15:34:39 it isn't terribly difficult to implement, it's a torrc setting and a tor GETCONF or w/e command 15:35:06 i think the harder question is do we care about/want to support people using the hardcoded port 9150 15:36:09 (especially since once the arti switch happens things potentially get weird) 15:37:45 I would like to propose we try to fit the patchset reordering at the beginning of 14.5 15:38:12 It would be good to do it before starting the RR rebases 15:38:34 100% agree 15:38:43 particularly the Android patch shuffle/redistribution 15:40:08 it looks like we've covered each of the discussion points for today 15:40:24 I've been working to update the Geckoview Makefile 15:40:34 oh? 15:40:35 To include support for building also APKs 15:40:40 From tools/geckoview 15:41:00 But I'll need an ELI5 on how to successfully get Android Studio to like tor-browser.git 15:41:59 👀 15:42:06 clairehurst: dan_b: who I can reach to for some help? :) 15:42:27 i can? 15:42:32 like is a strong word 15:42:43 i just open mobile/android/fenix in it? 15:42:50 I can help too probably 15:43:01 Okay, I'll send my problems offline then, thanks :) 15:43:04 and still use intelij for root tor-browser 15:44:46 morganava: can you access the comms project on gitlab? if so, can you update the issue there? 15:45:02 also ack to your previous message 15:45:08 no idea, can you link me offline? 15:45:18 done 15:46:47 brilliant 15:46:52 ok folks 15:47:02 as always, have a good wee and see you on the interwebs 15:47:09 o/ 15:47:17 (anything else?) 15:47:18 ... 15:47:19 o/ 15:47:22 grazie, ciao! 15:47:35 Nothing from me 15:47:38 ok :) 15:47:40 #endmeeting