#4957 (moved) adds a new transport line to sanitized bridge extra-info descriptors, e.g.,
transport obfs2transport obfs3
I think we'll have to bump the version number for these descriptors from 1.0 to 1.1. Even though 1.0 parsers won't understand this line, they shouldn't break. Therefore the new version should be 1.1, not 2.0.
However, both metrics-lib and stem look for "1.0" as the version number and won't parse 1.1 descriptors at all. See:
stem/stem/descriptor/__init__.py: elif first_line in ("@type bridge-extra-info 1.0"):
I'll update metrics-lib very soon. Once stem is updated, too, I'll make metrics-db produce 1.1 descriptors.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Though I'm not clear on this new field's attributes. Is it a simple only-appears-once string field? Is it a space separated listing? Does it appear multiple times to provide a list of values?
Thanks. I noticed that in your commit ba74915 you simply replaced 1.0 with 1.1. Shouldn't we still accept 1.0 descriptors?
That's the metrics-db commit which is about writing descriptors, not parsing them. metrics-web, which parses descriptors, still accepts 1.0 descriptors.
In that commit, doesn't the following line only accept versions 1.0 and 1.1?
+ elif desc_type == "bridge-extra-info" and major_version == 1 and minor_version in (0, 1):
Shouldn't stem also accept versions 1.2 and higher? It won't necessarily understand the new keywords, but it should parse all the parts that it understands.
Though I'm not clear on this new field's attributes. Is it a simple only-appears-once string field? Is it a space separated listing? Does it appear multiple times to provide a list of values?
"transport" transportname address:port [arglist] NL [Any number.] Signals that the router supports the 'transportname' pluggable transport in IP address 'address' and TCP port 'port'.
For sanitized bridge descriptors we scrub the part after transportname as explained in sanitizing step 5 on the formats page. transportname is a single string, but there can be any number of transport lines.
Can I deploy the changed metrics-db code to produce 1.1 bridge extra-infos descriptors then?
Shouldn't stem also accept versions 1.2 and higher? It won't necessarily understand the new keywords, but it should parse all the parts that it understands.
Hmm, this is kinda a weird field then that the spec says...
"transport" transportname address:port [arglist]
but will only appear in practice as...
"transport" transportname
Is there any reason that stem should have the ability to parse the former? If so, then can I rely on transportname being unique so I can make this a {transportname => address:port [arglist]} dictionary?
Shouldn't stem also accept versions 1.2 and higher? It won't necessarily understand the new keywords, but it should parse all the parts that it understands.
Hmm, this is kinda a weird field then that the spec says...
"transport" transportname address:port [arglist]
but will only appear in practice as...
"transport" transportname
Is there any reason that stem should have the ability to parse the former? If so, then can I rely on transportname being unique so I can make this a {transportname => address:port [arglist]} dictionary?
Yes, at the moment, transportname is supposed to be the unique identifier of a pluggable transport used by a bridge.
That is, if a bridge publishes more than one transport lines with the same transportname, it is either evil or a future version of tor where we have decided that this should be allowed (I don't see this happening atm).
or a future version of tor where we have decided that this should be allowed
Um... so you do want to allow it? It would be nice if the spec required the transportname to be unique (it would let me make things nicer for users). But if the answer is "it's unique for now but might change" then that translates to "it's not unique" since that would let a future Tor change break us.
or a future version of tor where we have decided that this should be allowed
Um... so you do want to allow it? It would be nice if the spec required the transportname to be unique (it would let me make things nicer for users). But if the answer is "it's unique for now but might change" then that translates to "it's not unique" since that would let a future Tor change break us.
OK, sorry if I gave the impression that this will change in the future.
Let me rephrase as: "The transportname is a unique identifier for each ClientTransportPlugin line.". I also checked the 180 spec again to make sure that this won't be problematic in the future.
Also, FWIW, the tor code is using this property of the transportname to match ClientTransportPlugin lines with Bridge lines.