14:58:54 #startmeeting Tor Browser Weekly Meeting 2023-03-20 14:58:54 Meeting started Mon Mar 20 14:58:54 2023 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:58:54 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:58:55 \o 14:58:59 it's that time of the week again 14:58:59 Hi! 14:59:11 the beginning? ๐Ÿ˜„ 14:59:13 the pad as usual: https://pad.riseup.net/p/tor-tbb-keep 14:59:15 hi 14:59:48 my favorite time of the week 15:01:51 hi 15:01:58 o/ 15:03:01 ok folks 15:03:26 12.0.4 went out late last week after some unexpected though over-due android security backports 15:03:31 we'd been lucky for too long :p 15:04:03 i'm planning on having a tor-browser-build MR ready for 12.5a4 this evening and build overnight 15:04:23 and an s131 build thereafter 15:05:02 question: i had always thought 12.5a4, the 'a' meant alpha, as in 12.5a4 was the alpha of what would become stable 12.0.4 15:05:18 or is that what it means, you're cutting a tag so we can always rebuild that while HEAD moves on? 15:05:39 ok 15:05:47 dan_b: it's an alpha of what will become 12.5.0 AFAIK 15:05:57 I.e. the 4th alpha 15:05:59 aaah gotcha 15:06:00 so the alpha series is what will be the next major stable series 15:06:20 whereas the current stable series is basically the last of the previous alpha series + any backports from the current alpha series 15:06:21 any reason we jump from 12.0 to 12.5? 15:06:21 But I should probably defer to richard to explain better 15:06:44 right so the tor browser version goes up by 0.5 between each major release 15:07:08 so like we had 11.5 release in Q2 of 2022, 12.0 release in Q4 15:07:17 ah gotcha 15:07:26 dan_b: I think the UX/marketing people figured out that consumers like 0.5 jumps more than 0.1 jumps 15:07:29 after 11.5 was released alpha jumped to 12.0a1 15:07:37 etc 15:07:53 IIRC long long ago Tor Browser didn't use 0.5 jumps 15:07:55 so there's no real relatonship between the version numbers of the current stable and current alpha version 15:07:59 they just happen to have the same digit 15:08:03 But I don't think I was active in Tor Browser dev back then 15:08:15 ok that helps a bunch, thanks 15:08:20 but they aren't really meant to be in alignment or anything (just happenstance atm) 15:08:33 um ok 15:09:21 dan_b: good question because I didn't know why either :) 15:09:23 We also prefer jumping by 1 for the ESR rebase, I think 15:09:39 The other version is in the middle, so .5 :) 15:09:50 I've always thought so, at least 15:09:51 aaah cool 15:09:54 But I might be mistaken 15:09:55 ma1, PieroV: can y'all provide a quick overview of what happened last week re webRTC on windows base-browser and the current plan for that one *particular* android-backport 15:10:11 so 13a will start with the ESR migration work then? 15:10:14 no idea why historically we jump by 0.5, probably a question for boklm or gk at this point :p 15:10:22 I don't know why 15:10:31 dan_b: i think that sounds right 15:10:34 I think it's always been like that 15:10:49 WebRTC is quite easy 15:10:52 I'll tell you about Android, and leave the floor to PieroV for WebRTC+รน 15:10:53 the major ones were for the esr update 15:10:55 * Jeremy_Rand_36C3[m] could have sworn that circa 5-10 years ago TBB didn't jump by 0.5 15:11:04 Maybe I'm remembering wrong 15:11:20 but we wanted to have kind of major ones for features we delevoped over the year ourselves 15:11:25 which went into .5 15:11:33 that's all 15:12:13 :) 15:12:32 ma1: do you want to go with Android first, or do you want me to go with WebRTC? 15:12:42 PieroV, the floor is yours :) 15:13:07 Okay. So, we had a crash on Windows... But it was not a real memory shenanigans crash or something similar 15:13:31 It was a MOZ_CRASH because a promise wasn't expected to be rejected, but it was 15:13:51 Long story short, initialization of the IPC mechanism with the socket process failed 15:14:25 HTTP seems not to use it, but WebRTC does. So, the quick fix for WebRTC on Windows is completely disabling the network process 15:14:52 And in the meantime maybe try to send msism's great job upstream, and then discuss this problem there 15:15:31 Re: Android. We've found one of the Android backports doesn't work on TB, and quite unreliable on Firefox as well. Everything points at Mozilla's fix having a race condition due to the too many moving parts in Fenix/Android Components/GV. 15:16:02 At least, that what I gathered by creating a mitigation in NoScript as a stop-gap measure. 15:16:31 And what PieroV confirmed trying to follow the logs along many debug sheenigans (both mine and yours) on our Android tools. 15:17:02 (which, BTW, I think we should try to put in some order as soon as we're out of other priorities like S131) 15:17:13 Yep, the race condition seems to be on the GV/C++ side 15:17:37 The Java side seems fine-ish, it just makes everything more complicated to deal with 15:17:47 ok, so mostly good news all around then 15:17:54 Anyway, we basically shipped with this not-so-good "fix" from Mozilla, but a full working mitigation is in NoScript 11.4.19, which I've asked for expedite review in the weekend 15:18:11 So as soon as NoScript is autoupdated TBA is protected 15:18:20 (and firefox :3) 15:18:21 Fine-ish and not fine because Moz's original fix ends up in an ignored error condition 15:18:29 And in the meanwhile, we're gonna ask Mozilla to fix their fix :D 15:18:58 lol 15:19:28 ma1: can you keep track of that upstream and backport once/if they have something that's backportable? :p 15:19:39 Probably performances have been improved in more recent Firefox, so Firefox encounters the race condition less likely than us 15:19:45 * Jeremy_Rand_36C3[m] notes that it's extremely unreasonable for Mozilla to be acting as a Tivoization gatekeeper for Tor Browser security fixes that we choose to deploy via NoScript 15:19:46 Yes, I'm cced in the bug and I'm commenting there later today 15:20:29 Jeremy_Rand_36C3[m], something I'm trying to push for for some time now is having our own Tor-hosted NoScript update channel. 15:20:29 jeremy: android backports got harder around january of this year due to them merging fenix and android-components 15:20:38 which to be clear I think is a good thing and will make our jobs easier long term 15:20:50 but in the interim is a bit challenging to deal with 15:20:55 Jeremy_Rand_36C3[m]: I'm not sure I'm following 15:21:09 ma1: yeah that would help 15:21:23 PieroV, I think Jeremy_Rand_36C3[m] was talking about AMO reviews 15:21:38 PieroV: WebExtensions need a Mozilla signature to be updated/installed, even when they're extensions that Tor Browser has already decided should be deployed 15:21:40 oh i see i see 15:21:53 That's an extra layer of trusted third party that shouldn't exist ideally 15:22:14 Oh, I see, thanks 15:22:25 agreed from me 15:22:46 dan_b/donuts: were there any issues getting the requested nightlies built/delivered for user testing last week? 15:22:53 Jeremy_Rand_36C3[m], if we self-host a tor-specific version we can have AMO automatic signature in minutes. 15:23:03 or any issues that came out of that (not sure when the testing is meant to be happening) 15:23:13 richard: no issues with the nightlies afaik, however there wasn't really a lot to test 15:23:15 shipped on our end just find, donuts seemed happy, i assume the testing went well 15:23:45 i'll be working through the rest of my s30 tickets until they are gone so hopefully you'll have a bit more next time 15:23:57 donuts: what's the next major deadline for user testing in April? 15:24:48 ma1: you mean using a Tor signing key? 15:24:49 richard: w/c the 17th is when the final session will happen, I'm not sure on the exact day(s) yet though 15:24:50 (if so that seems generally sane) 15:25:14 ok good taht's not for awhile 15:26:06 Jeremy_Rand_36C3[m], no, just uploading to AMO if you specify a non-mozilla update URL gets it signed after some automated validation for already approved extensions such as NoScript. 15:26:30 Well, we could even decide to have a Tor Browser key for addons 15:26:45 ma1: Ah. That's still an improvement I guess, but I do think requiring a Mozilla signing key instead of a Tor Project signing key is undesirable. 15:26:45 Nothing prevents us from doing so 15:27:21 ok 15:28:02 PieroV: can you backport any required updater patches to s131, update the updater URLs, etc for the next release? 15:28:16 richard: I have tor-browser!585 15:28:30 Once it gets approved, it should be as easy as cherry-picking it to S131 15:28:33 amazing 15:28:35 ok 15:30:05 and boklm: can you update the signing scripts for signing s131 mars for the subsequent release 15:30:17 ok 15:30:29 I will do that this week 15:30:45 ok 15:32:14 by the way, did you get news about the new signing machines? 15:32:26 oh no i haven't 15:32:31 is it on the ticket? 15:32:43 I haven't 15:33:11 oh I see 15:33:18 i'll follow up 15:34:27 ok I think that's everything I was curious about 15:34:47 i'll happily give the floor to anyone else if you have topics to discuss 15:34:50 boklm: any ETA on the openssl / arm-linux MR? 15:35:07 I think I addressed all the feedback, hopefully should be boring to review 15:35:40 Jeremy_Rand_36C3[m]: thanks, I'm planning to look at it soon 15:36:32 boklm: great thanks! 15:38:07 ok, have a good week everyone 15:38:14 see you all on IRC o/ 15:38:17 Thanks! o/ 15:38:25 o/ 15:38:26 o/ 15:38:35 #endmeeting