Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2024-03-05T15:17:58Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11101Bridges should report implementation versions of their pluggable transports2024-03-05T15:17:58ZRoger DingledineBridges should report implementation versions of their pluggable transportsOur bridges now run a variety of pluggable transports. What if there's a bug in, say, the Scramblesuit implementation (like it appears there is)? If we fix the bug, how do bridgedb or the Tor clients know whether the Scramblesuit bridge ...Our bridges now run a variety of pluggable transports. What if there's a bug in, say, the Scramblesuit implementation (like it appears there is)? If we fix the bug, how do bridgedb or the Tor clients know whether the Scramblesuit bridge they just learned about is one of the new (updated) ones or one of the old (buggy) ones?
One option would be for Tor to include a version for each supported PT in its bridge (or extrainfo) descriptor, so if we turn out to not want to use certain versions for certain situations, we can do it.
Are there better options than this one?Tor: 0.4.9.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/11211Multiple ServerTransportListenAddr entries should be allowed per transport.2023-11-16T20:18:11ZYawning AngelMultiple ServerTransportListenAddr entries should be allowed per transport.Looking through or/config.c, it is apparent that the ServerTransportListenAddr line only allows one address/port to be specified per transport. This is problematic because there are cases where it is beneficial/required to list more tha...Looking through or/config.c, it is apparent that the ServerTransportListenAddr line only allows one address/port to be specified per transport. This is problematic because there are cases where it is beneficial/required to list more than one.
A simple example of where this would be useful is:
```
ServerTransportListenAddr obfs3 0.0.0.0:443
ServerTransportListenAddr obfs3 [::]:443
```
The Pluggable Transport spec doesn't explicitly disallow having multiple bind addresses for TOR_PT_SERVER_BIND_ADDR, but I'm not sure what would happen if more than one is passed with each of the pt config protocol libraries in use.
The keys holding transport names must appear on the same order
as they appear on TOR_PT_SERVER_TRANSPORTS.
Currently the particular example I used is probably a moot point because of #7961, but in general I don't see a good reason why each transport should be limited to one bind address.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/6505GETINFO dir/status-vote/current/consensus returns "Unrecognized key" if no co...2022-02-07T19:38:59ZZack WeinbergGETINFO dir/status-vote/current/consensus returns "Unrecognized key" if no consensus availableIf there is no consensus available, issuing a GETINFO command for dir/status-vote/current/consensus will return an "Unrecognized key" error instead of an empty string, which will make pytorctl crash.
Patch attached.If there is no consensus available, issuing a GETINFO command for dir/status-vote/current/consensus will return an "Unrecognized key" error instead of an empty string, which will make pytorctl crash.
Patch attached.