14:59:18 #startmeeting Tor Browser Weekly Meeting 2022-12-05 14:59:18 Meeting started Mon Dec 5 14:59:18 2022 UTC. The chair is richard. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:18 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:59:21 Hi! 14:59:23 pad: https://pad.riseup.net/p/tor-tbb-keep 15:01:56 So we released 12.0a5 last week, and so far it's been pretty quiet in terms of bug reports 15:02:52 i'm in the middle of release prep for 12.0 and we should have build tags later today, so should be able to build overnight/tomorrow AM 15:03:24 \o/ 15:03:33 oo 15:04:07 (I'm already building Firefox at HEAD of tor-browser-102.5esr-12.0-2, but if the translations are also for Firefox I'll have to drop these binaries :() 15:04:24 once that's ready I'll start prioritizing issues/review the roadmap for 12.5 and s131 work 15:05:56 in the meantime this week feel free to grab s131 milestone 2 issues 15:06:30 Hi all, I have a question about Tor Browser, OpenBSD and Pluggable Transports. Should I ask that during a meeting like this one or is it better if I ask in #tor-browser-dev? I don't want to hijack your meeting 15:06:31 Nice, congrats on having 12.0 almost ready! 15:06:55 here's a gitlab query: https://gitlab.torproject.org/groups/tpo/applications/-/boards?label_name[]=Sponsor%20131&milestone_title=Sponsor%20131%20-%20Phase%202%20-%20Privacy%20Browser 15:08:48 Question: what's the workflow for S131 + Tor Browser patches vs Tor Browser only patches vs S131 only patches (if any)? 15:09:12 ah good question 15:09:38 so going forward we're going to have a base-browser branch rather than a base-browser tag 15:10:52 so for MRs which should be merged to base-browser, please target the appropriate base-browser-102.Xesr-12.5-1 branch 15:11:33 whomever merges should merge such issues into both base-browser and tor-browser branches 15:11:53 richard: just to clarify, are you saying there will not be any tagged releases of Base Browser going forward? 15:12:22 which will affect the rebase/release process so I'll have to update the checklist again :p 15:13:29 Will the tor-browser branch always be based on top of base-browser? 15:13:38 sorry, i think we will continue to tag base-browser branches in line with the tor-browser tags 15:14:20 henry-x: not always 15:15:01 so on release day they will in line but if base-browser specific fixes come in throughout the month then tehre will be divergence 15:15:09 richard: ok, thanks for clarification. (I know some people who are interested in using Base Browser tagged releases.) 15:15:15 (but such fixes should also be merged to tor-browser too) 15:15:22 jeremy: oh? 15:15:48 tbf that is cool but unexpected 15:15:57 richard: I think that targeting tor-browser would be easier for reviewers and testing 15:16:00 ok, what do we do if the base-browser patch must be applied before any tor-browser-only patch? 15:16:42 richard: yeah the Kicksecure guys are evaluating using it. They haven't committed to using it yet, but if they do, tagged releases would presumably be a prereq. 15:17:36 hmm neat 15:18:22 henry-x: what sort of situation would require this? 15:19:00 so, the current workflow has been basically merge to tor-browser with a note that it needs to be in the base-brwoser section, adn then it's moved on the next rebase 15:19:16 richard: it's not super surprising that Kicksecure is interested; they had their own (now-discontinued) project called SecBrowser that was basically the same concept was Base Browser. 15:19:27 s/was/as/ 15:20:49 if we need to touch the same file twice: once for base-browser and then again with some tor-specific parts in tor-browser. And then later we want to fixup the file in base-browser. 15:21:32 ahh so we have had that before 15:21:38 if I understand correctly, it's the kind of problem we've solved with the "dropme!" 15:21:45 yeah that^ 15:21:52 what's "dropme!"? 15:22:03 It's something we invented :P 15:22:10 basically add a commit which brings back the stuff we want to remove with 'dropme!' as the header 15:22:17 ah 15:22:20 nice 15:22:27 We've reverted the tor-browser part of the patch, applied the base-browser part, and then the tor-browser part again 15:22:31 and the a fixup! that comes after which undoes it but in the right place 15:23:01 it is inelegant 15:23:09 I think that 2 MRs could be a better solution in the future 15:23:09 so like a spicy rebase? 15:23:17 i think in that case you'd probably be better doing two MRs, one for tor-browser and one for base-browser 15:23:23 That 15:23:50 So, probably we'll have to split the rebase in parts in the future 15:23:59 yes p much 15:24:04 makes sense 15:24:16 hmm, maybe we can have an automated test for base-browser merge requests that let you know if tor-browser can be based on top of it 15:24:16 rebase base-browser to ESR, then cherry-pick/rebase the tor-browser patches onto base-browser 15:25:18 tbh I'm sure we haven't quite converged to the perfect workflow, so we can make improvements as we go 15:26:36 yeah. Hopefully most of our features are modular-enough that their files will only be in base-browser or tor-browser 15:26:48 yeah ideally 15:27:14 ideally tor-browser should be only connection to tor + onion services on top of base-browser 15:27:52 ok the only other thing was I wanted to encourage you all to please 'link' issues that get merged with the appropriate Release Prep issue(s) in tor-browser-build 15:28:26 makes it a lot easier to build out changelogs if the things we've done are all listed in the same place ^^; 15:29:00 guilty as charged, I don't think I've ever done it, sorry. I'll do it :) 15:29:23 release prep issues? 15:29:24 richard: wdym release prep issues? 15:29:31 eeeeh 15:29:41 so in tor-browser-build we have issues labeled "Release Prep" 15:29:58 such as https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40637 15:30:38 it's basically the meta ticket for each release where all the coordination/checklist happens 15:31:21 currently we only have one for 12.0 but i'll make one for 12.5a1 later today 15:31:37 Do we just link the one that is currently open? 15:31:53 so for usual features you'll typically only add the next alpha to the Linked items section 15:32:15 for MRs that should also be backported, we should add also the next stable as well 15:32:24 henry-x: yeah exactly 15:32:36 there aren't usually that many 15:32:57 the short list of open ones is in the first column on the tor-browser-build board: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/boards 15:33:03 ah cool 15:34:12 ok I think that's all i wanted to talk about 15:34:20 does anyone else have something to discuss? 15:34:27 richard: I think you missed a question from cschutijser at the beginning of the meeting 15:34:34 whoops 15:34:47 cschutijser | Hi all, I have a question about Tor Browser, OpenBSD and Pluggable Transports. Should I ask that during a meeting like this one or is it better if I ask in #tor-browser-dev? I don't want to hijack your meeting 15:34:57 oh hi cschutijser 15:35:00 (not sure they're still online) 15:35:01 Hi! 15:35:04 Yep, I'm still here 15:35:10 feel free to ask! 15:35:16 Okay! 15:35:25 Quickly introducing myself for those who don't know me: I maintain Tor Browser on OpenBSD. Right now Tor Browser on OpenBSD does not have any support for Pluggable Transports. Prompted by some discussion on a mailing list I looked into it. For now I came up with something like to enable it: https://marc.info/?l=openbsd-ports&m=166937708328808&w=2 15:35:34 and if we go over happy to chat in #tor-browser-dev 15:35:37 I don't expect you to fully understand it as it's a diff of an OpenBSD port, but I hope you get the gist of it. I concat tools/torbrowser/bridges.js to browser/app/profile/000-tor-browser.js and I tweak the shipped torrc-defaults file to include a ClientTransportPlugin entry for obfs4proxy. I tested it and it works. Would that be OK to ship or are there some common pitfalls in this area? 15:35:45 As you can see, with the "cat ${WRKSRC}/tools/torbrowser/bridges.js >>${WRKSRC}/browser/app/profile/000-tor-browser.js" stuff, I'm basically re-doing some stuff that you as upstream take care of in a couple of scripts. That's another topic which I hope to look at some point, to basically re-use your scripts instead of doing stuff like this by hand (because we're obviously going to miss things in 15:35:51 OpenBSD). But that's not a small project and not something I can look at right now 15:36:50 cschutijser: that file isn't always up to date 15:37:13 You might prefer the lines that are in tor-browser-build/projects/browser/_something_, let me find the files 15:37:23 (there are many of them, one for each pt) 15:38:01 Ah, it would be great if they're separate for each PT indeed. On OpenBSD we currently only have obfs4proxy so that's the only ones I need to append to 000-tor-browser.js 15:38:45 Oh, sorry, they're in projects/common, not projects/browser 15:38:56 bridges_list.$PT.txt 15:39:25 And you should tweak torrc also for snowflake 15:39:26 Okay. Thanks, that's good to know. Now there's one tiny problem and that is that I don't have an easy way to access tor-browser-build.git from the port build process 15:39:26 yes common/bridges_list.obfs4.txt (and meek-azure.txt) 15:39:37 And also bridges_list.snowflake.txt 15:39:40 can you download files? 15:39:56 Yes, I can. If they are stable in the sense that they always have the same checksum 15:39:57 during port build? 15:40:04 ah, the expert bundle thing would come in handy here by the sounds of it 15:40:05 Not during the build, only before 15:40:20 in that case checkout https://dist.torproject.org/torbrowser/12.0a5/ 15:40:32 there are a bunch of tor-expert-bundle*.tar.gz files (with sigs) 15:40:55 that contain built bins for all our platforms used in tor-browser-build as well as bridge strings in text files 15:41:09 and they coincide with each tor-browser release 15:41:18 currently alpha but we'll be shipping with stable too for 12.0 15:41:23 Ah, thanks! I never looked at those files before. That's exactly what I need for this purpose. Thank you 15:41:33 :D 15:41:44 they're relatively new :3 15:42:17 So If I use the bridges_list.obfs4.txt file and I add torrc-defaults like I did in the URL shown above and it works, you don't see a problem with me shipping that? 15:42:27 Not any obvious problems, let's say 15:42:40 cschutijser: actually there are a few files for pts 15:42:43 s/add torrc-defaults/modify torrc-defaults/ 15:43:04 I expect that you're closer to Linux, so please have a look also at projects/browser/Bundle-Data/PTConfigs/linux/torrc-defaults-appendix 15:43:58 obs4_proxy also supports meek-azure too btw 15:44:20 richard: okay. So I was probably holding it wrong. I'll double-check that, thanks 15:44:41 PieroV: I'll have a look at that, thanks. I don't have the files at hand right now but I'll make a note 15:45:07 you may run into some unexpected behaviour w/ connection assist too if you don't have snowflake configured 15:45:45 and you'll probably want a patch for about:preferences#connection to remove the Snowflake bridge config 15:45:49 Okay. We already have snowflake-proxy in ports on OpenBSD, I'll see how much work it is to get the client as well. Probably shouldn't be too hard 15:46:06 probably easier than carrying tor-browser patches ;) 15:46:14 It's another go project 15:46:15 Right, that's a good idea if I don't ship with Snowflake support 15:46:25 I'd expect it not to be more difficult than obfs4 15:46:34 yeah 15:46:47 Okay, makes sense 15:47:14 Is it OK if I work on a diff for the OpenBSD port in which I take your feedback into account and then I show the diff to you again? Perhaps just in #tor-browser-dev 15:47:33 oh, and long term you'll want to use archive.torproject.org ( https://archive.torproject.org/tor-package-archive/torbrowser/12.0a4/ for instance ) since links on dist.tpo are fairly ephemeral 15:48:13 I think that taking blobs directly from GitLab could work, too 15:48:23 cschutijser: sure! Feel free to ask anytime 15:48:28 richard: I already do that also, archive.torproject.org is a fallback. https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/tor-browser/browser/Makefile?rev=1.97&content-type=text/x-cvsweb-markup 15:48:45 true true 15:48:47 But thanks for the feedback :) 15:48:53 PieroV: great! 15:49:18 but yeah feel free to ping us for any code reviews 15:49:35 and also let us know if there's anything we could change on our end to make things easier for you 15:49:45 That's appreciated, thank you. For now I think I have some homework to do and then I can get back to you with a new diff 15:49:59 ok perfect 15:50:12 Yes, I will 15:50:18 anything else 15:50:31 Not from my side 15:50:32 Not from me; just a remainder that I'll be afk Thu and Fri 15:50:37 * Jeremy_Rand_36C3[m] has a quick question 15:50:42 go go go 15:51:42 As you're probably aware, Robert Min is doing an Outreachy project for us involving proxy leak detection via ptrace. There's nothing actionable yet for you guys, but at some point we should talk about maybe using that code in automated tests of Tor Browser or something. 15:51:49 Just wanted to have it on your radar. 15:52:01 love it 15:52:15 And see if you have any workflow related thoughts on the topic, e.g. how it might best be integrated into your test systems 15:52:36 i think we will have opinions on that in the coming weeks :p 15:52:41 Great! 15:53:06 That is all from me 15:53:27 nothing from me :) 15:53:28 ok, then i'm gonna call it here 15:53:35 o/ 15:53:39 have a good week everyone! 15:53:44 Thanks! 15:53:45 thanks everyone! 15:53:48 #endmeeting