15:01:30 #startmeeting Tor Browser Weekly Meeting 2023-07-24 15:01:30 Meeting started Mon Jul 24 15:01:30 2023 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:30 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:01:36 the pad: https://pad.riseup.net/p/tor-tbb-keep 15:02:07 as per usual, also take this time to update/cleanup your boards/etc 15:06:02 for once I don't think I have anything to go talk about this week 15:06:43 plannning signing/releasing 13.0a1 today assuming we don't have any more builds to do 15:06:50 richard: today is tag day 15:07:12 We're publishing a version that is going to be old already ^_^ 15:07:19 our signing infra continues to see improvement, and the jump host was replaced at the end of last week, which will allow us to set up a second backup/development signing machine 15:08:02 and we're in the very last stages of reference checking the potential new android dev 15:08:21 I suspect we won't make more forward progress until next week tho since erin is afk 15:09:00 no worries, i have some ideas of stuff to try still going from low probability but hopefully unblocks to larger reworks that'll be a litte longer 15:09:08 and I starte the actual work of the code+issue audit last week and have since been humbled in my git understanding 15:09:47 so it looks like you have a few items PieroV, so I'll hand it off to you 15:09:52 Yes 15:10:03 First is, we have are getting tags in a few hours/tomorrow 15:10:55 seems a little early no? 15:11:02 But we could publish 13.0a1 anyway 15:11:14 richard: nope. Tags are available around a week before the release 15:11:22 Release is August 1st, next Tuesday 15:12:43 Anyway, any plan for release job distribution? 15:12:55 12.5 should be an easy job 15:13:15 13.0a2 should also be easyish at the moment, because most of the patches have been shuffled already 15:14:21 I can alpha is someone else can take stable 15:14:32 Release prep or rebase? 15:15:01 I was thinking both tbh, but we can divide it up further 15:15:33 dan_b, ma1: y'all want some more rebase/release experience? :D 15:15:42 ack. I can rebase, too, in case 15:15:48 I think dan_b should focus bootstrapping Android 15:16:03 I'm inclined to agree re: dan_b actually 15:16:14 ha cool, works for me 15:16:25 I'm gonna be fully afk from 31 to 7, but whatever I can do (including Android ports with advance notice if it arrives Thurs) I'll do. 15:16:37 (and I can release prepare, too; I think I could also rebase alpha if before going back on tor-browser!699) 15:17:23 ok 15:17:25 how about: 15:17:30 ma1: rebase stable 15:17:33 PieoV: rebase alpha 15:17:44 and i'll release prep both? 15:17:46 wfm 15:17:48 wfm 15:18:03 god damn look at that beach factor 15:18:08 alright 15:18:45 btw, did the mar-toools certutil mismatch granted us a new a01 build? 15:19:09 I don't have a clue about what happened, apart from seeing a bigger header 15:19:28 Also, I match with ma1's build (which is strange enough, since my computer is more similar to tb-build-05 than ma1's laptop) 15:19:44 hmm 15:19:58 on which machine was done the build that doesn't match the other two? 15:20:04 tb-build-05 right? 15:20:07 Yes 15:20:20 is it possible i didn't clean something up properly? 15:20:34 richard: can you check your mar-tools in out/firefox? 15:20:37 I only nuked the *browser/release/unsigned/13.0a1 dirs 15:21:20 The directory should be out/firefox/firefox-mullvad-browser-007f5b3e4faa-windows-x86_64-f20b69 15:21:29 it's also possible that it is a reproducibility bug that only happens once in a while 15:21:31 If buildid doesn't match we have a possible other problem 15:21:41 one moment 15:22:47 richard@tb-build-05:~/tor-browser-build/out/firefox/firefox-mullvad-browser-007f5b3e4faa-windows-x86_64-f20b69$ sha256sum * 15:22:47 a57ab80ba14efd40185345458c47b2b1a746c0d0bd14045f36ddee5adc469ddb browser.tar.gz 15:22:47 4fffdbd48c29f768b960b56a0351fcb18538224b199b3ba528fa4528bfd984e8 mar-tools-win64.zip 15:23:01 vOv 15:23:38 ah its the linux mar tool that don't match right 15:23:39 Yes, I match with this, unless I remember the wrong zip 15:24:34 ok linux: 15:24:35 richard@tb-build-05:~/tor-browser-build/out/firefox/firefox-mullvad-browser-007f5b3e4faa-linux-x86_64-bc89f5$ sha256sum * 15:24:35 0c66dbbb087a7b6caa09a852faecc21f625e086f41ea26618e8969d9b18dc6a4 browser-debug.tar.xz 15:24:35 7b5ed732f4f406ddcb8f15926df132268de0a371c01fc2124c04f7931800842c browser.tar.gz 15:24:35 60ae68931d3267133f9cd567ce0ae8e8760223a55f3e2df7594d87cd464fa657 geckodriver-linux64.tar.xz 15:24:36 84007caa31a0e84ddd1b12c90fe46451e7d7e51b3dc20ecd4c3a0a4f168b04db mar-tools-linux64.zip 15:25:01 I confirm same build id, but different hash on the zip 15:25:14 yes, that's it 15:25:40 Have you run Diffoscope on the non-matching zips? 15:25:49 Jeremy_Rand_36C3[m]: yes, but it isn't great 15:26:06 certutil & pk12util differ 15:26:16 Hmm. Yeah Diffoscope can be hit-or-miss 15:26:30 There's a slightly bigger header on one of the zip, so diffoscope is outputting a lot because everything is offsetted 15:26:31 hmm, https://tb-build-05.torproject.org/~richard/builds/torbrowser/alpha/unsigned/13.0a1/sha256sums-unsigned-build.txt and https://people.torproject.org/~ma1/builds/torbrowser/alpha/unsigned/13.0a1/sha256sums-unsigned-build.txt look the same 15:26:56 boklm: it's mullvad browser 15:26:59 ah, that's only in mullvadbrowser that it doesn't match 15:27:07 yes, which is even more strange 15:27:20 I think that we could have richard rebuild, and if that matches call it for 13.0a1 15:27:26 might it be time based (like something we download remotely changed on the fly)? 15:27:51 MB is a small enough diff from TB that theoretically a Git bisect could maybe narrow it down easily? 15:28:18 they both build out of the same tor-browser-build repo tho 15:28:30 Jeremy_Rand_36C3[m]: it's the first official 115 build 15:28:43 and i *doubt* we have any mullvadbrowser or torbrowser patches affecting those components 15:28:48 But I'm quite sure we haven't touched the updater lately 15:28:49 but who knows 15:29:07 i'll re-run the build on b-build-05 and see what we get 15:29:25 If it's specifically affecting certutil and pk12util, my first guess would be to look for suspicious things in the NSS-specific build scripts 15:29:29 ma1/PieroV can one of you upload the mismatched artifacts if you haven't already 15:29:46 ack; ma1 have you? 15:29:51 mine are all at https://people.torproject.org/~ma1/builds/ 15:29:51 it's also strange that only linux64 build doesn't match, but linux32 build does match 15:30:00 indeed 15:30:05 richard, ^ 15:30:11 Jeremy_Rand_36C3[m]: well, now that you mention it and I think of it, I've actually created a patch for using NSS for mar utils 15:30:14 Historically the NSS parts of Firefox have kind of done their own thing build-wise 15:30:38 HMMMM 15:30:42 And I've even uplifted it already (well, I've re-adapted the old patch to use NSS for mar signatures) 15:30:46 i love eating my own hat :p 15:30:48 But it touched the Windows + macOS parts 15:30:50 So it seems entirely plausible that a build script change would break reproducibility in just the NSS parts 15:32:02 Jeremy_Rand_36C3[m]: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/759#note_2924380 15:32:22 (I've movd 13.0a1-build1 to 13.0a1-build1.bak so tb-build-05 links are now broken) 15:32:24 This difference is pretty strange though, richard's build is 72 byte smaller 15:33:42 PieroV: ELF section headers being mismatched makes me think perhaps the NSS parts of the build scripts are doing something weird with binutils compared to the Firefox build scripts 15:34:10 (I can't prove that, just a hunch) 15:34:43 I haven't touched binutils, we don't quick/known test to check what Firefox expects 15:34:48 ok nuked the relevant out/browser and out/firefox dirs and release dirs, rebuilding 15:35:18 I updated it to 2.39 last year, which introduced the NSIS problem ^_^; But I don't remember why I did it 15:35:19 I seem to recall seeing ELF header reproducibility issues with cgo a couple years ago, which I traced to a bug in how the Go compiler calls out to GNU binutils 15:35:41 So maybe something similar is amiss in the NSS build scripts 15:36:52 I could totally be on the wrong track though 15:38:07 slighty differnt track 15:38:48 ma1: can you prioritize the ope letterboxing/default window size issues 15:38:56 re defining better defaults 15:38:58 richard, ack 15:39:41 I think Thorin has alreay done most of the background work on that, so should just be a matter of updating code w/ new and improved defaults 15:40:33 ok, is there anything else we need to discuss beyond his reproducibility problem? 15:40:42 Yes 15:40:52 What if we released debug symbols on all the platforms? 15:41:07 I've just tried to build a zip with Windows PDBs, and it's "only" 250MB 15:41:20 oooh 15:41:21 So, +0.5GB for each release, but I think it'd be worth it 15:41:29 I'm inclined to agree 15:41:32 And I'd enable debug symbols also on Linux 32 15:41:46 re 'why don't we ship pdbs' 15:41:55 I'd do something for macOS too, but I don't have a clue on how it works 15:41:57 most likely because pdbs weren't even possible until relatively recently 15:42:19 Well, they were already possible when I started :) I used them for my first issue here 15:42:25 jesus 15:42:27 on the letterboxing front, there are three things I'd like to consider for 13.0 (depending on what yall think): 1. better UX/more deliberate design in general, 2. better defaults, 3. option in preferences for new windows to open in the last used letterbox size, or to select a default size, or both 15:42:32 well 'relatively' is doing a lot of work there 15:42:57 o/ morning donuts 15:43:00 hello ^^ 15:43:06 i am lurking and listening lol 15:43:07 Last thing about PDBs, then leaving the mic to donuts 15:43:32 I think zip is fine for symbols on Windows, but if we are concerned about size I can try xz 15:44:06 windows users (even devs) tend to be complain if we use archives other than zips 15:44:19 since zip is the only thing that windows understands w/o 3rd party software 15:44:28 Yep, that's why I was suggesting zip 15:44:43 richard: lol who are these Windows devs? Literally the first thing I do when I create a Windows VM for QA testing stuff is install 7zip 15:45:14 Jeremy_Rand_36C3[m]: we have an issue about making tor expert bundle available in zip again (when we extended it to other platforms we switched to gz for all of them) 15:45:17 PieroV: as part of any PDB work, can you also update the Wiki re how to use the pdbs in conjunction w/ the source tarball to setup windbg on Windows? 15:45:37 yep, tor-expert-bundle users were sad about the lack of zip distribution 15:45:49 PieroV: doesn't current Windows have tar anyway? 15:45:49 which meh, I'm kind of ok with a little gatekeeping there 15:45:57 since it isn't meant for normal users 15:46:12 primarily a PT distribution method I think 15:46:21 richard: I didn't want to launch a debug session actually :D 15:46:29 I mean, maybe current Windows has a broken GUI for tar, but I'm quite certain I recall using tar on Windows from PowerShell without installing it myself 15:46:45 I'm doing this because someone from the community might do some work for us \o/ 15:46:59 ^PieroV: that's probably a good plan too 15:47:00 Anyway, if users really want zip, I suppose I'm not one to argue 15:47:40 vOv 15:48:19 ok donuts, talk to us about letterboxing 15:48:36 so yes to better defaults, 100% 15:48:39 iirc ma1 has an open MR that modifies the design of the letterbox area but i haven't built or experience it 15:48:55 yep! it looked like it was heading in a good direction 15:49:12 one of the changes in the design proposal was to center the content area, which ma1 was experimenting with 15:49:23 https://www.figma.com/file/gFE1rXBMdbZGJAIdwtZ508/Tor-Browser-13.0?type=design&node-id=205%3A10697&mode=design&t=GTDhvGaKBGDCT1Px-1 15:49:28 that could potentially be an option though 15:49:51 the main drive here was to try and make the feature look more deliberate, and less like a bug (which most new users assume it is) 15:50:06 on top of that, adding something to preferences would also give us a nice place to describe the feature in general 15:50:06 I think the button/label thing would go a long way about it 15:50:42 the maybe-slightly-controversial thing I'd also like to propose is: additional option in preferences for new windows to open in the last used letterbox size, or to select a default size, or both 15:51:04 because the first thing I see _everyone_ do when they open a new window is to manually change the size anyway 15:51:11 donuts: definitely felt like a bug when i first saw letterboxing this looks so much nicer 15:51:42 donuts: hmm, so I *do* frequently change the window size when I open a new window... 15:51:43 but 15:51:49 I like the "remember my last letterbox size" 15:52:00 I usually have 2 sizes I switch between depending on what I use the window for 15:52:25 And "the last one I used" isn't going to help that workflow very much AFAICT 15:52:35 also these options could be opt-out by default if we have concerns, but I think they're still worth having 15:52:58 Would it be possible to remember the last, say, 2-3 sizes that the user has used, and have quick buttons available for resizing to those? 15:54:11 donuts: do you have designs for these drafted yet? 15:54:12 mmm, that wouldn't help that much I guess. If you go "by hear" you get a letterboxed (quantized) size anyway. Unless you're talking about non-letterboxed windows (which I would like to discourage as much as possible) 15:54:23 Jeremy_Rand_36C3[m]: mmm not sure about that 15:54:34 richard: see the figma link I posted further up 15:54:40 because we're rapidly approaching the esr102 depracation date 15:54:44 they're also in the "explain letterboxing" ticket 15:55:00 ack 15:55:38 i meant more for the preferences portion 15:56:18 richard: oh gotcha, I haven't visualized those yet – was interested in your feedback first 15:56:27 but I can mock that up pretty quick 15:57:03 I'm thinking an option to choose between centering the content vs anchoring it to the top, and the "remember my last letterbox size" at minimum 15:57:14 ack 15:57:35 i like my content anchored at the top :D 15:57:52 yeah I imagine many existing users will prefer to keep it that way 15:57:56 i think i'm happy with the proposed changes 15:58:03 (timecheck) 15:58:08 oh and we're done 15:58:20 cool ty everyone :) 15:58:25 hav ea good week everyone let's scatter before the next folks realise we're taking their room 15:58:29 #endmeeting