14:59:35 #startmeeting Tor Browser Weekly Meeting 20220-10-03 14:59:35 Meeting started Mon Oct 3 14:59:35 2022 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:35 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:59:36 o/ 14:59:40 o/ 14:59:54 good morning afternoon and evening! the pad is here: https://pad.riseup.net/p/tor-tbb-keep 15:00:07 o/ 15:00:49 Pad onion down for anyone else, or is that just my Tor connection being flaky? 15:01:01 I'm with Firefox and it works 15:01:09 (I filled in my info 10 minutes ago before it went down, so doesn't really matter I guess) 15:01:24 it was working a few minutes ago but not anymore, and then working again now 15:01:42 * Jeremy_Rand_36C3[m] shrugs 15:01:57 Indeed, just came back 15:11:20 ok looks like we have some things to talk about 15:12:14 boklm: I answered on the pad but I have intermittent access to an arm macto verify the new macOS builds 15:12:22 ok, thanks 15:12:28 are we shipping a single x86_64+aarch64 bundle then? 15:12:32 yes 15:12:42 \o/ 15:12:46 ok i can also verify in an x86_64 vm 15:12:49 that's super exciting 15:13:00 so we need to check that's it's working on both 15:13:04 I know donuts has been anxios for those :D 15:13:19 indeed, very exciting :D 15:13:41 do you have testbuilds uploaded anywhere? otherwise i can fire that off after this meeting 15:13:50 yes, I uploaded a testbuild 15:14:05 ah ok probably on the ticket 15:14:06 ok great 15:14:10 https://people.torproject.org/~boklm/builds/macos-aarch64-testbuild1/ 15:14:20 donuts^ 15:14:35 ty ty 15:14:54 however it's not codesigned, so maybe there is something to do to be able to run it 15:15:16 Right click -> open instead of double click 15:15:22 yes, you typically need to right click->open and then hit yes trhough the warning prompt 15:15:32 (but I might have done something to become dev to do so) 15:15:32 then you can usualy open without having to do that after it's allow listed 15:16:11 ok onto the next thing 15:16:23 "The application “Tor Browser” can’t be opened." 15:16:25 hrmmmm 15:16:38 PieroV: to my knowledge esr91 is dead long live esr102 re security patches 15:16:51 oh, okay 15:17:01 why do you ask? 15:17:06 I was wondering if they still did something, e.g. for some Linux distros 15:17:55 tjr would know the real answer to this 15:17:57 PieroV: FWIW Debian is on 102 already. No idea about CentOS. I think those are the only ESR-based distros Mozilla would be likely to bend over backwards for? 15:18:08 So, do we need to go through each commit of 102.2 -> 102.3 to see what needs to be backported? 15:18:43 Jeremy_Rand_36C3[m]: I see, if they did it also for us it would be great :D 15:18:46 i only did this for the CVE bugs 15:19:30 (and a simlar process for android on alpha) 15:19:48 PieroV: that would be a nice, happy, uplifting AU fanfic :P 15:20:09 https://www.mozilla.org/en-US/security/advisories/mfsa2022-41/ has the list of bug numbers 15:20:11 (what's AU in this context?) 15:20:32 ("alternate universe", it's a fan fiction term for fiction that doesn't conform to canon) 15:20:32 PieroV: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41310 15:20:49 richard: I can volunteer for the stable rebase 15:21:22 oh, right, no rebase needed 15:21:32 Well, to anything related to the release 15:22:09 PieroV: that would be great, and I can pick up anything left over tomorrow 15:22:30 wfm 15:22:39 desktop has the fixes reviewed and backported, just need to merge henry's YEC patches 15:22:53 oh, I think they said they need help with the font 15:22:55 alsmith et al don't seem to care about a particular time for the campaign to go live 15:23:04 (in the pad, not sure it was for the last week) 15:23:07 so long as it's on the the given day in the tickets 15:23:25 that was last week i believe 15:23:41 they ended up doing the same base64 blob technique from last year 15:24:49 stable for android is going to be more involved since we want to migrate to 102 for it (dan_b is in the middle of rebasing his YEC patch to 102 so we may be waiting on that until tomorrow as well) 15:25:30 so geckoview-102.3.0esr-12.0-1 or 102.2? 15:25:46 The former, I'd say 15:25:54 ok 15:25:55 yes 15:26:15 will it be "geckoview-xxx" or "tor-browser-xxx"? 15:26:24 the current alpha (maybe sans any fresh patches unique to the 12.0a3 release) 15:26:28 for stable still geckoview 15:27:26 jeremy: re cloudflare i have no contacts but I'll ping some people who might 15:27:46 I think my geckoview was on 102.2 so updating to 102.3 now 15:28:10 richard: OK. If this is intentional malice on CF's end (i.e. they don't want to support Nightly users) then there's not much we can do, but I'm guessing it's accidental (lack of coordination between Tor and CF) 15:28:11 but I was still seeing that problem in android-components I'd see last month where it fails to compile with being unable to find torSecurityLevels 15:28:15 anyone seen that? 15:28:47 dan_b: you might try to set .3 on the TB version, and you should switch channel either to beta or to nightly 15:29:00 (ma1 found this, I didn't know because we always had the beta channel in the past) 15:29:21 richard: CF has been sufficiently unpleasant for me since Nightly moved to ESR102 (I run Nightly in production on one machine) that I've had to revert that machine to TBB stable in order to get work done without constantly hitting CAPTCHAs 15:29:21 Jeremy_Rand_36C3[m]: yes, it usually happens when we switch esr version, so I think they need to update something on their side 15:29:38 (err, the .3 in the GV version, but you should that only on local builds, I think) 15:29:55 I presume this also happens in alpha then? 15:29:59 boklm: right, that's my guess -- it would be desirable if there were some contact wherein we could give CF a heads up when Nightly switches ESR versions 15:30:00 i've been running it with -with-tor-browser-version=12.0a1 15:30:16 richard: I don't run Alpha so I'm not sure but I assume so 15:30:38 can't imagine why it wouldn't be vOv 15:31:56 android-components only has ac versions, of which i'm using android-components-102.0.14-12.0-1 15:32:10 dan_b: no, it has also GV version embedded 15:32:30 android-components/buildSrc/src/main/java/Gecko.kt 15:32:52 0_o 15:33:15 /** 15:33:15 * GeckoView channel 15:33:15 */ 15:33:15 - val channel = GeckoChannel.RELEASE 15:33:15 + val channel = GeckoChannel.NIGHTLY //.RELEASE 15:33:17 } 15:33:32 i see. ok, so change 102.0.20220705093820 to 102.3.20220705093820 ?? 15:33:39 Yes, and then what ma1 wrote 15:33:45 oh and to NIGHTLY 15:33:50 yep 15:33:56 wow, cool ok thanks 15:36:47 PieroV: do you have any intuition of the relative difficulty of moving torbutton vs multi-locale bundles? 15:37:27 richard: there's the issue about moving our patches to the Rust implementation of Fluent 15:37:45 It's another reason to get new identity moved asap 15:38:08 Apart from that everything should be okay with old l10n mechanism 15:38:20 ahhh, is then that localization migration (and so the torbutton migration) a pre-req for multi-locale bundles? 15:39:06 not really, it's in general the main problem I see with l10n 15:39:23 Which isn't strictly related to multi-locale. 15:40:03 hm, so basically i want to make sure we have multi-locale bundles for 12.0a4 15:40:11 Oh, maybe I haven't understood your question 15:40:22 The difficulty of moving torbutton is very high, compared to the multi-locale 15:40:42 yeah so that's sort of my worry 15:40:45 multi-locale could be as easy as flipping the pref in tor-browser-build 15:40:59 And +1 for doing it for 12.0a4 15:41:14 ok, can you prioritize multi-locale over the torbutton migration then 15:41:20 multi-locale is still a blocker for ARM and POWER ports, yes? 15:41:28 Well, actually +1 for doing it asap, so that we can test it in nightly 15:41:32 (Just making sure I haven't missed a memo somewhere) 15:41:56 I think we'll need to do something to handle updates so that users from single locale get update to multi-locales bundle 15:42:15 boklm: agreed 15:43:03 PieroV: there's a recent tor-browser-build patch which touches that update logic I can point you to later 15:45:56 PieroV, what's the torbutton migrattion issue? I'd like to take a look 15:46:13 ma1: we have to do the same we've done for tor-launcher to torbutton 15:46:24 I.e., take the code, refactor it, and move it to tor-browser.git 15:46:39 donuts: when do you think we'll have an icon-set for s131 browser? I think some testbuild of base-browser with the icon swap would be helpful yeah? 15:47:31 I said two weeks to the sponsor to get visuals over for review, roughly aiming for the end of Oct to get final assets into your hands 15:48:30 ok that sounds perfect, i'll follow up on the ticket with precisely the assets needed for the branding swap 15:48:46 I still have a bolded item 15:49:02 That is: the unified GV-desktop branch is ready, and it was easier to do than I expected 15:49:31 So, I don't want to be pushy about it, but could if I could get a review for it soonish I'd rebase the tor-launcher MR on it :) 15:49:44 so there is little changes between the two branches? 15:50:11 richard: 👍 15:50:12 The bot assigned to boklm, but we could reassign it, if boklm already has a lot on his plate 15:50:28 boklm: the content seems a lot because I've also added the mozconfigs 15:51:06 But apart from that it was fixing a pair of compiling errors (I missed some pieces on the 102 rebase on Java files), fix a moz.configure thing 15:51:47 and finally moving the backend of Securitylevel to include it also when compiling for Androdi 15:53:34 I can have a loot at it tomorrow, unless someone wants to take it 15:53:58 the soonest I could look at it is tomorrow as well 15:54:30 If you want someone's earlier I could take a shoot at it PieroV 15:54:56 Thanks! Tomorrow or even on the next days works great for me :) 15:55:29 (but I think that a local build would be better to test it, I haven't prepared the tor-browser-build MR, but I should prepare one, too, now that I think of it) 15:56:03 So you're keeping it as a draft until ready? 15:56:21 No, it's ready to be tested with a local build 15:57:39 ok i think that's everything 15:57:44 will it require a lot of tor-browser-build changes, or is it just changing the branch name? 15:57:59 boklm: the branch name and add a JAVA_HOME variable, if we don't have one already 15:59:13 ok that's our time 15:59:14 #endmeeting