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