16:02:18 #startmeeting Tor Browser Release Meeting 2024-07-08 16:02:18 Meeting started Mon Jul 8 16:02:18 2024 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:18 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:02:21 o/ 16:02:27 ok so people who have been online today 16:02:39 wth is going on with mozilla and pinned certs and why is tpa on fire 16:03:14 Basically www.torproject.org wasn't working on Firefox anymore 16:03:18 let's encrypt changed their intermediate certs 16:03:18 Because we rotated certs 16:03:34 And the new ones have an intermediate cert that isn't pinned in Firefox/Chromium 16:03:47 but TB seems fine? 16:03:52 because we patched it 16:03:56 at least when i bootstrapped i can connect/check for updates 16:04:03 Also, lavamind reverted the certs 16:04:04 and asked moz to pickup our changes, but they forgot about it 16:04:16 And restored the ones that work 16:04:27 ok, so the updater isn't broken forever then 16:04:42 I think the updater domains are not pinned 16:04:53 It's not for all subdomains 16:05:05 It's only for the ones we had asked to be pinned 16:05:49 blog.tpo, check.tpo, dist.tpo, www.tpo 16:06:14 Updates are fetched from aus1.tpo, but I don't remember where the mars live... dist.tpo? 16:06:23 Or do we have some other CDN for it? 16:06:35 they live on cdn.tpo I think 16:06:42 mmhm 16:07:07 mar files are in https://cdn.torproject.org/aus1/torbrowser 16:07:07 Well, we could probably even serve them through HTTP and we'd still have our signature on them :) 16:07:07 ok so just to make sure i understand 16:07:25 So, not a big deal not to pin cdn.tpo for the browser 16:07:27 but we should be good anyway, because in our patch we included the new intermediate 16:07:48 TPA updated/rotated torproject's certs, Mozilla *didn't* update our pinned intermediate cert even though we asked to 16:08:09 exactly. So Firefox is broken, but we aren't 16:08:19 so i guess what i want to know is what went wrong in this process, and how can we fix it so we don't break the updater in the future 16:08:30 we asked in May last year, today they answered apologizing because they forgot abotu it 16:08:46 (even though the updater was fine this time around) 16:09:00 I couldn't find a Bug connected to our request 16:09:05 actually it seems let's encrypt advises again pinning, so tpa now is asking moz to just remove the pins 16:09:08 removing the pinning might solve the problem 16:09:08 (they contacted us in the first place) 16:09:42 In facts, the process was they contacting us asking for keeps/changes, and we timely answered. 16:10:07 But then they forgot about it, and now they're apologizing and trying to update. ETA 2 weeks max unless we say it's very urgent. 16:10:21 For 128.0.1? 16:10:46 Yes. If we say it's urgent they *may* schedule an earlyer dot release 16:11:38 but TPA can just use the old certs until then and we're good? 16:11:42 Yes 16:11:53 The current live ones expire around Aug 8 16:12:05 right 16:12:16 ok 16:12:23 Yep, for now we're good. Anyway, our last request to Mozilla is just removing the pins. We'll probably keep bridges.tpo on our side. 16:12:54 is there a possible scenario here where upstream can break the updater? 16:13:10 soe combo of certs expiring, upstream pinning/unpinning the wrong thing, etc? 16:13:13 No 16:13:30 Except for untrusting let's encrypt as a CA 16:13:39 right 16:14:30 hmm 16:14:45 well that would break most of the intenret i imagine 16:14:58 and we'd probably notice :p 16:16:22 ma1: did you get the preview of the security fixes? 16:16:44 not yet 16:16:50 ack 16:17:17 Is it possible they sent it to the wrong address? 16:17:30 nope. richard should get it as well, btw 16:19:09 (frankly if they sent security@mozilla.org stuff to random email recipient I would be a bit worried) 16:19:27 i get periodic security bug reports that's like a table 16:19:57 ma1: I thought once tjr said that something was sent to another security mailing list 16:19:57 yep, last one 2024-07-07 - just stats 16:20:03 yeah exactly 16:20:06 ok 16:20:21 But maybe it wasn't this, but something else (maybe it was the last chemspill) 16:21:30 ok, so is there anything else then beyond waiting for security backports? 16:21:48 Apart from that I run the release preparation earlier 16:22:03 PieroV, btw, I'm compiling some "blind" backports and I've got apparently unrelated rust dependencies errors. rustc is 1.69 - should I downgrade for 115 or look for something else? 16:22:19 (and also rebased onto 115.13) 16:22:42 ma1: rustc 1.69 is the one we use in tor-browser-build 16:23:40 it starts with error[E0432]: unresolved import `crate::p11::PK11SymKey` 16:24:30 well, I'll try a ./mach bootstrap and see if it helps 16:24:33 Is it in third_party? 16:24:36 yep 16:24:49 It might be some vendored depdendency then... Which is a very ugly thing to patch 16:24:54 Because vendored deps include hashes 16:25:41 Maybe 115 isn't affected because it vendors an old version of that crate 16:27:57 it's neqo-crypto v0.6.4 - however, didn't mean to hijack this meeting. ./mach boostrap didn't help. Going on with backports and check this later on #tor-browser-dev 16:28:28 also just got to that point grep'in :p 16:29:07 alright if there's no impending doom 16:29:19 i think we can end this unless there are further topics of discussion? 16:36:00 ok i will take your silence as a yes we're done here 16:36:22 later folks o/ 16:36:24 #endmeeting