16:00:08 #startmeeting anti-censorship meeting 16:00:08 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:11 welcome :) 16:00:25 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 16:00:40 hello 16:00:56 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 okay let's get started 16:04:05 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 there is a very old ticket about it: https://gitlab.torproject.org/tpo/core/tor/-/issues/11101 16:04:30 and the network team was asking if this is still useful 16:05:16 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 I guess I mean, where will this versions end up? 16:05:28 the idea is to put it in the extrainfo docs 16:05:43 and it will allow us to get metrics/reach out to operators if they are running super old versions 16:06:06 I see, is for the bridges 16:06:11 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 oh yeah it's for the server side 16:06:39 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 has it happened in the past that we really wanted this feature? 16:08:04 the issue says 'estimated: 24h', so no trivial change, but done in less than a week of a single developer 16:08:23 cohosh: we have so far avoided wanting it by never fixing any bugs in obfs4 :) 16:08:33 :D 16:08:34 lol 16:08:58 alright well assuming we want it, the second half of this discussion is how to handle things on the PT side 16:09:19 there are a few possibilities which include: 16:09:20 one issue is that there is no implementation of STATUS in goptlib 16:09:29 - adding a new PT message just for this 16:09:51 - using an existing one of which STATUS is a candidate because it accepts arbitrary key=value pairs 16:10:00 dcf1: yeah that was one of the considerations 16:10:20 iirc, it wasn't yet implemented because there wasn't a use for it yet? 16:10:21 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 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 so the only difference between using STATUS or another message is going to be modifying or not the spec 16:11:48 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 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 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 dcf1: yea good point. standardizing these is what a spec is good for 16:13:30 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 okay so it looks like we might want to modify the spec either way 16:14:47 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 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 we only have one maintained implementation of the tor specification for PTs 16:17:14 well, this may be something to consult with the wither PT ecosystem 16:17:41 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 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 ah good catch 16:18:42 I think STATUS makes more sense than a new message, with one caveat: 16:19:19 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 (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 For version self-reporting, it might be a requirement that the version number message happen before the initial negotiation is finished 16:20:43 (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 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 not sure if I'm explaining it well 16:21:45 yeah that makes sense 16:22:52 Like "progress=35" would make sense as a STATUS message at any time, but "version=xxx" would have to come early 16:23:05 yup 16:23:06 made somewhat more complicated because you can have multiple k=v in one STATUS message 16:23:22 this sounds a bit messy to do rather than have two different message types 16:23:51 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 yeah, i assume this is what happens to unknown keys as well 16:24:41 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 And the spec should say what happens if the message occurs more than once with different values 16:25:29 i think ahf is afk at the moment but said he'd read the backlog 16:26:15 great 16:26:58 awesome thanks dcf1 16:27:01 anything else on this? 16:27:12 I have a point about zoossh 16:27:23 meskio: go for it :D 16:27:24 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 sounds good 16:29:59 are we done with the pt version? 16:31:54 yes 16:32:03 in rdsys we are starting to use zoossh to parse networkstatus, bridge-descriptors and so: https://github.com/NullHypothesis/zoossh 16:32:12 but we need some modifications to it 16:32:26 I reached out yesterday to phw with some proposed changes 16:32:52 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 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 what do you think? 16:33:59 will the fork include backwards incompatible changes to the library? 16:34:15 no, I don't think we need to break compatibility 16:34:32 (or maybe tiny behaviour changes) 16:35:44 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 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 especially if we aren't trying to fundamentally change how the library works 16:37:02 phw comment on it: https://github.com/NullHypothesis/zoossh/pull/12#issuecomment-930954831 16:38:30 I'm happy anyway 16:38:39 okay, yeah i don't have strong feelings either XD 16:38:51 we can send zoossh patches, and phw gets tired of reviewing we can take over :) 16:39:01 for now is being pretty fast answering 16:39:14 cool that sounds good 16:39:43 good, I'll do that, I think that is all for this point 16:40:17 awesome thanks meskio! 16:40:23 anything else for today? 16:40:27 do we have reading group next week? 16:40:33 yup! 16:40:38 nice 16:41:27 I don't have anything else more for today 16:41:39 * cohosh waits another minute 16:43:15 #endmeeting