16:00:11 #startmeeting tor anti-censorship meeting 16:00:11 Meeting started Thu May 13 16:00:11 2021 UTC. The chair is cohosh. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:19 welcome :) 16:00:25 hey 16:00:30 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 16:01:14 feel free to add things to the agenda for today 16:02:51 the first thing on the agenda is more workflow/git repo maintenance stuff 16:03:25 the git branch migration is wrapping up but there are a few outstanding tasks 16:03:29 like sorting out our mirrors 16:03:54 it seems like our existing snowflake mirrors are just automatically working for the new main branches 16:03:56 q: what is gitolite? Is it the git@git-rw.torproject.org SSH thing? 16:04:09 dcf1: yes it is that 16:04:53 i am a bit fuzzy on the details and so i'm not sure if gitolite also encompasses the https://git.torproject.org thing 16:05:51 when i was sorting out the issues with HTTPS being slow to update with anarcat it seems like they are separate 16:06:01 git.torproject.org might be gitweb (so readonly/web only service) 16:06:03 and that a push to git-rw will cause the https to update 16:06:49 meskio: yeah that sounds reasonable 16:08:02 so yeah we're in a situation now where we have some gitolite --> gitlab mirrors (for e.g., snowflake) 16:08:31 i *think* we have or had some gitlab --> gitolite mirrors for e.g., gettor-web but i'm not sure 16:08:54 and some repos like bridgedb we were just remembering to push to both 16:09:11 and some that are only in one place or the other 16:09:20 yep :) 16:09:59 anarcat and meskio mentioned some rumblings that gitolite will be made legacy but afaict there hasn't been a public discussion about that 16:10:53 in any case, it'd be nice if we at least documented where our workflows differ 16:11:02 and if possible have all our mirrors going int he same direction 16:11:35 my proposal on the ticket was to have them all go from gitlab --> gitolite 16:12:03 but there was some discussion on the attack surface of gitlab 16:13:22 so my current proposal is to set up gitlab --> gitolite mirrors and then work on adopting a policy to sign some or all of our commits 16:13:43 any thoughts/concerns/objections/feedback? 16:13:48 sounds good to me 16:14:15 we just need to find a signing policy that we are all happy with 16:14:20 for repositories not on gitlab we can just set up the mirrors if/when they are migrated there 16:17:41 okay i'll take that as no more comments for now 16:17:48 and start working on setting up mirrors 16:18:01 dcf1: you want to move on to the next discussion item? 16:18:48 we don't have to discuss it during the meeting, but while writing comments on https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/36 I realized I had a lot to say 16:19:07 it might be better to have some interactive discussion rather than long hacking followed by long review 16:19:46 we could schedule a time for interactive discussion of pair programming 16:20:22 *or pair programming 16:20:26 okay cool, and it would be great for meskio to be involved as well 16:20:41 since this has good background on how the broker is set up and what future work on snowflake will be like 16:20:45 sure, I'll be happy to tray to follow you 16:21:44 I'm sure you two are the most constrained meeting-wise, so maybe you can suggest a time 16:21:44 s/tray/try/ 16:21:49 dcf1: thanks for the detailed comments on the merge request btw, i read them earlier today 16:21:53 we can also do the scheduling outside the meeting itself 16:22:25 my fridays and tuesdays are almost always free of meetings right now 16:22:41 and mondays for the most part 16:22:53 meskio would probably prefer before 17 utc? 16:23:33 for me is better tuesday than friday 16:23:34 and i prefer after 14 utc 16:23:49 but I could do most friday if needed 16:24:19 what about tomorrow, then, at 14utc? 16:24:36 tomorrow I can't, but you can go ahead without me 16:24:48 I don't have a lot to say that's not written on the ticket, but we can maybe save a lot of future time by some shorter discussion now 16:25:04 okay tue 18 May at 14utc? 16:25:15 sounds good to me 16:25:48 sounds good re tuesday 16:25:55 and yes let's do a bit of discussion now 16:26:07 okay let's budget 90 minutes for tue and see how it goes 16:26:41 by "now" I mean whever we have this discussion 16:27:00 the important thing for me is to keep the path open for other plans we have for the broker 16:27:33 and because I'll be doing AMP cache rendezvous in the near future that will probably use this facility 16:27:53 ah i see 16:28:04 (re th emeaning of now) 16:28:54 most of the broker code is effectively legacy code at this point, and we have that to deal with in addition to new design issues 16:29:10 weird to think that at one point our concern was decoupling it from app engine so it could run standalone on a vps 16:29:51 heh 16:31:04 hmm yeah you're right about the legacy thing 16:31:30 at first i was surprised and then realized that yes, much of the broker code is implemented as HTTP handlers 16:31:41 the actual proxy assignment is extremely simple 16:31:51 yeah that's partly vestigial from when it was only an app engine app 16:32:08 where you have to implement things that way 16:34:19 alright cool, let's continue discussion next tuesday and for now move on to our needs help with? 16:34:26 yeah 16:35:35 meskio: i think bridgedb32276 would be a good one for you to review 16:35:42 bridgedb#32276 16:35:56 i'll provide some links in the ticket with moat documentation 16:36:32 cohosh: great, I'll look into it 16:36:50 there is not rush for this, so i'll let you decide when you want to cram more onboarding info into your brain lol 16:37:28 :) 16:37:38 anyone else need reviews or have more discussion they want to bring up? 16:39:03 I'm good 16:40:49 alright nice 16:41:01 i'll wait just anothe rminute or so before ending th emeeting 16:43:14 #endmeeting