16:00:08 <cohosh> #startmeeting anti-censorship meeting 16:00:08 <MeetBot> Meeting started Thu Sep 30 16:00:08 2021 UTC. The chair is cohosh. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:08 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:11 <cohosh> welcome :) 16:00:25 <cohosh> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 16:00:40 <meskio> hello 16:00:56 <cohosh> feel free to add items to the agenda 16:02:09 * cohosh waits a min or so while pad is being edited 16:03:32 <cohosh> okay let's get started 16:04:05 <cohosh> the first item is discussing using a relatively new feature of the tor pt spec to allow pts to pass in their version number 16:04:22 <cohosh> there is a very old ticket about it: https://gitlab.torproject.org/tpo/core/tor/-/issues/11101 16:04:30 <cohosh> and the network team was asking if this is still useful 16:05:16 <meskio> what will be the use of it? to collect metrics of versions? to detect problems from the versions on the debug logs? 16:05:24 <meskio> I guess I mean, where will this versions end up? 16:05:28 <cohosh> the idea is to put it in the extrainfo docs 16:05:43 <cohosh> and it will allow us to get metrics/reach out to operators if they are running super old versions 16:06:06 <meskio> I see, is for the bridges 16:06:11 <cohosh> so part of this discussion is to decide if this is useful enough to have the network team go through and implement it 16:06:19 <cohosh> oh yeah it's for the server side 16:06:39 <arma2> right, it is for the bridge side -- the idea is, if there's a bug in obfs4 and we fix it and some people upgrade and some people don't, we have no way to see which ones upgraded currently 16:08:03 <cohosh> has it happened in the past that we really wanted this feature? 16:08:04 <meskio> the issue says 'estimated: 24h', so no trivial change, but done in less than a week of a single developer 16:08:23 <arma2> cohosh: we have so far avoided wanting it by never fixing any bugs in obfs4 :) 16:08:33 <meskio> :D 16:08:34 <cohosh> lol 16:08:58 <cohosh> alright well assuming we want it, the second half of this discussion is how to handle things on the PT side 16:09:19 <cohosh> there are a few possibilities which include: 16:09:20 <dcf1> one issue is that there is no implementation of STATUS in goptlib 16:09:29 <cohosh> - adding a new PT message just for this 16:09:51 <cohosh> - using an existing one of which STATUS is a candidate because it accepts arbitrary key=value pairs 16:10:00 <cohosh> dcf1: yeah that was one of the considerations 16:10:20 <cohosh> iirc, it wasn't yet implemented because there wasn't a use for it yet? 16:10:21 <dcf1> at the time there were no documented or even imagined use cases for STATUS, and I didn't want to add what would be dead code 16:10:42 * cohosh nods 16:11:01 <dcf1> if there's a concrete use case with stable and documented key strings, then I don't have a problem with it 16:11:44 <meskio> so the only difference between using STATUS or another message is going to be modifying or not the spec 16:11:48 <cohosh> is the idea to implement a fix number of accepted strings in goptlib? or just that if tor has fixed strings then it's worth implementign? 16:12:28 <arma2> i am thinking that https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40062 might turn out to be a second use case for something similar. or for the same thing. 16:12:42 <dcf1> The situation to avoid, in my mind, is a folksonomy where one transport does _version and one transport does currentVersion and one transport does v, and tor is in the position of having to sort it all out 16:13:13 <cohosh> dcf1: yea good point. standardizing these is what a spec is good for 16:13:30 <dcf1> If the spec says something like, "transports may self-report their version number using: STATUS TRANSPORT "version"="1.1.0-foo"", then all are on the same page 16:14:35 <cohosh> okay so it looks like we might want to modify the spec either way 16:14:47 <meskio> makes sense 16:15:25 * dcf1 notices the syntax specification for STATUS is ambiguous as to whether commas are required (pretty sure commas are not allowed) 16:16:13 <cohosh> given that, i think it makes sense to leave it up to the network team as to whether they want to introduce a new message or use STATUS? 16:16:33 <cohosh> we only have one maintained implementation of the tor specification for PTs 16:17:14 <dcf1> well, this may be something to consult with the wither PT ecosystem 16:17:41 <dcf1> Like with STATUS I reached out to the author of ptadapter, which implements the tor side of the PT protocol (opposite of goptlib) https://gitlab.torproject.org/tpo/core/tor/-/issues/28181#note_2487293 16:18:14 <dcf1> It wouldbe good to check first to see whether PT 2.x makes provision for version reporting (offhand I don't think it does) 16:18:21 <cohosh> ah good catch 16:18:42 <dcf1> I think STATUS makes more sense than a new message, with one caveat: 16:19:19 <dcf1> I think STATUS is specified to be permitted at any time, even after the initial negotiation has finished with CMETHODS/SMETHODS DONE. 16:19:45 <dcf1> (Which was another slight issue with STATUS, some old versions of tor would deadlock the PT process if they wrote too much to stdout after the initial negotiation.) 16:20:15 <dcf1> For version self-reporting, it might be a requirement that the version number message happen before the initial negotiation is finished 16:20:43 <dcf1> (Otherwise tor has to e.g. wait a configurable amount of time after the negotiation to see if the message comes, sounds unpleasant) 16:21:16 <dcf1> And in that case, it would create two classes of STATUS keys: ones that happen during the negotiation and ones that may happen afterward 16:21:33 <dcf1> not sure if I'm explaining it well 16:21:45 <cohosh> yeah that makes sense 16:22:52 <dcf1> Like "progress=35" would make sense as a STATUS message at any time, but "version=xxx" would have to come early 16:23:05 <cohosh> yup 16:23:06 <dcf1> made somewhat more complicated because you can have multiple k=v in one STATUS message 16:23:22 <cohosh> this sounds a bit messy to do rather than have two different message types 16:23:51 <dcf1> maybe a good way to specify it would be: "the 'version' key is only honored if it is sent during negotiation; it's ignored after that" 16:24:09 <cohosh> yeah, i assume this is what happens to unknown keys as well 16:24:41 <dcf1> I think currently all STATUS messages go into a black hole, or get redirected to the same code path as LOG, or something like that 16:24:59 <dcf1> And the spec should say what happens if the message occurs more than once with different values 16:25:29 <cohosh> i think ahf is afk at the moment but said he'd read the backlog 16:26:15 <dcf1> great 16:26:58 <cohosh> awesome thanks dcf1 16:27:01 <cohosh> anything else on this? 16:27:12 <meskio> I have a point about zoossh 16:27:23 <cohosh> meskio: go for it :D 16:27:24 <dcf1> from my side, 1. I'm willing to add either a new message or STATUS to goptib, if there's documentation for what the message means and what tor will do with it), 2. I would want guidance on when the message may occur and what happens if there are duplicates 16:28:20 <meskio> sounds good 16:29:59 <meskio> are we done with the pt version? 16:31:54 <dcf1> yes 16:32:03 <meskio> in rdsys we are starting to use zoossh to parse networkstatus, bridge-descriptors and so: https://github.com/NullHypothesis/zoossh 16:32:12 <meskio> but we need some modifications to it 16:32:26 <meskio> I reached out yesterday to phw with some proposed changes 16:32:52 <meskio> and basically said that is not touching this code for a long time, that is happy to merge whatever we give him or we can just take it over and fork it in our side 16:33:28 <meskio> I think it will make sense to fork it into gitlab under the anti-censorship team (or somewhere else in tpo) and maintain it ourselves 16:33:36 <meskio> what do you think? 16:33:59 <cohosh> will the fork include backwards incompatible changes to the library? 16:34:15 <meskio> no, I don't think we need to break compatibility 16:34:32 <meskio> (or maybe tiny behaviour changes) 16:35:44 <meskio> for now I plan to add just what we need, I don't intend to make it a full parser of all the details of the files 16:36:37 <cohosh> if phw is still happy to maintain/handle merge requests and is responsive then i have a slight preference for not forking 16:36:55 <cohosh> especially if we aren't trying to fundamentally change how the library works 16:37:02 <meskio> phw comment on it: https://github.com/NullHypothesis/zoossh/pull/12#issuecomment-930954831 16:38:30 <meskio> I'm happy anyway 16:38:39 <cohosh> okay, yeah i don't have strong feelings either XD 16:38:51 <meskio> we can send zoossh patches, and phw gets tired of reviewing we can take over :) 16:39:01 <meskio> for now is being pretty fast answering 16:39:14 <cohosh> cool that sounds good 16:39:43 <meskio> good, I'll do that, I think that is all for this point 16:40:17 <cohosh> awesome thanks meskio! 16:40:23 <cohosh> anything else for today? 16:40:27 <meskio> do we have reading group next week? 16:40:33 <cohosh> yup! 16:40:38 <meskio> nice 16:41:27 <meskio> I don't have anything else more for today 16:41:39 * cohosh waits another minute 16:43:15 <cohosh> #endmeeting