Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2021-09-12T21:12:59Zhttps://gitlab.torproject.org/legacy/trac/-/issues/30642Add an ed25519-identity file to the data directory2021-09-12T21:12:59ZteorAdd an ed25519-identity file to the data directoryRelays print their RSA fingerprint to a "fingerprint" file in their data directory.
We need an equivalent file for base-64 encoded ed25519 public keys.Relays print their RSA fingerprint to a "fingerprint" file in their data directory.
We need an equivalent file for base-64 encoded ed25519 public keys.Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/15518Tor considers routers in the same IPv6 /16 to be "in the same subnet"2020-06-13T18:28:20ZIsis LovecruftTor considers routers in the same IPv6 /16 to be "in the same subnet"When `EnforceDistinctSubnets` is enabled, tor uses:
```
/** Return true iff router1 and router2 have similar enough network addresses ...When `EnforceDistinctSubnets` is enabled, tor uses:
```
/** Return true iff router1 and router2 have similar enough network addresses
* that we should treat them as being in the same family */
static INLINE int
addrs_in_same_network_family(const tor_addr_t *a1,
const tor_addr_t *a2)
{
return 0 == tor_addr_compare_masked(a1, a2, 16, CMP_SEMANTIC);
}
```
to determine if an address is in the same family. For an example IPv6 address, `2001:1234::0:1`, its /16 representation is `2001::/16`, meaning that `2001:ffff::` would be in the same family. A `\16` for IPv6 is _huge_, particularly considering that [only one-eighth of all IPv6 space is currently allocated for use on the internet](https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml) (`2000::/3`). For the path selection code, using `/16` essentially means that no two IPv6 routers in the same country (or possibly even continent) will be in the same path, and might possibly provide extremely increased chance of selection to routers in weird/rare IPv6 subnets.
For a related ticket, see #15517 governing how BridgeDB's version of `EnforceDistinctSubnets` will work for IPv6. (In that ticket, I proposed using IPv6 `/32`s, since that is the [minimum ARIN IPv6 subnet allocation for a LIR](https://www.arin.net/resources/request/ipv6_initial_assign.html).Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/28269Repeated HSFETCH queries fail with QUERY_NO_HSDIR2020-06-13T18:03:46ZDamian JohnsonRepeated HSFETCH queries fail with QUERY_NO_HSDIRHi lovely network team. Iain is working on a script to inform him of hidden service descriptor age. He's using stem to fetch them but unfortunately after a few HSFETCH calls it begins to fail with QUERY_NO_HSDIR. Maybe some attempt at ra...Hi lovely network team. Iain is working on a script to inform him of hidden service descriptor age. He's using stem to fetch them but unfortunately after a few HSFETCH calls it begins to fail with QUERY_NO_HSDIR. Maybe some attempt at rate limiting? Once the tor process gets into a borked state it doesn't seem to recover until I bounce the tor process.
Here's an example of my first query (which succeeds)...
```
>>> SETEVENTS HS_DESC HS_DESC_CONTENT
250 OK
>>> HSFETCH facebookcorewwwi
250 OK
>>> /events
HS_DESC_CONTENT facebookcorewwwi 3jjxhgi72xguhnihk4nwzrcpyvwf3ml5 $DA722ECCB9C0DE462C4FA585B93C99CCCA1C7547~SIRDRAKE2018
rendezvous-service-descriptor 3jjxhgi72xguhnihk4nwzrcpyvwf3ml5
version 2
permanent-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBALfng/krEfrBcvblDiM3PAkowkiAKxLoTsXt3nPEzyTP6Cw+Gdr0ODje
hmxTngN1pKiH7szk4Q1p2RabOrUHWwXmGXeDDNs00fcyU6HupgqsCoKOqCsmPac6
/58apC64A7xHeS02wtfWJp6qiZ8i6GGu6xWXRWux+ShPgcHvkajRAgMahU8=
-----END RSA PUBLIC KEY-----
secret-id-part wuyfue4erz2hlh4d5o4kduweosco6rw4
publication-time 2018-10-31 18:00:00
protocol-versions 2,3
introduction-points
-----BEGIN MESSAGE-----
aW50cm9kdWN0aW9uLXBvaW50IHR6c3U3ZXh5amVlZWU2cm92cDd1Z25lM3pxemlo
ZHk1CmlwLWFkZHJlc3MgMTQ0Ljc2Ljk2LjYKb25pb24tcG9ydCA5MDAxCm9uaW9u
... lot more base64...
L1UycythTGNtYmhITGJPWlhZRjRMcERTV1R3THkwb0ZzTEFnTUJBQUU9Ci0tLS0t
RU5EIFJTQSBQVUJMSUMgS0VZLS0tLS0KCg==
-----END MESSAGE-----
signature
-----BEGIN SIGNATURE-----
cMLWu42NG+I5hH9QAHZUQ8eDGCUzcny/uN/FwAYiLsUSc3QLg7MKbRTZ3v2ARonB
wcUgEAGpO4wDjuEj2ivNmpt6U0smJ7nM5KTWy4l0732QnTeSEX+P53qIJ7KwxDro
+JyBARfK4orCMieHuxYtJop6YgVRQ8XN6NtP6NiDrWY=
-----END SIGNATURE-----
OK
HS_DESC RECEIVED facebookcorewwwi NO_AUTH $DA722ECCB9C0DE462C4FA585B93C99CCCA1C7547~SIRDRAKE2018 3jjxhgi72xguhnihk4nwzrcpyvwf3ml5
HS_DESC REQUESTED facebookcorewwwi NO_AUTH $DA722ECCB9C0DE462C4FA585B93C99CCCA1C7547~SIRDRAKE2018 3jjxhgi72xguhnihk4nwzrcpyvwf3ml5
```
... and here's an example of my fourth onward, which always fail.
```
>>> /events clear
cleared event backlog
>>> HSFETCH facebookcorewwwi
250 OK
>>> /events
HS_DESC_CONTENT facebookcorewwwi 3jjxhgi72xguhnihk4nwzrcpyvwf3ml5 UNKNOWN
OK
HS_DESC FAILED facebookcorewwwi NO_AUTH UNKNOWN REASON=QUERY_NO_HSDIR
HS_DESC_CONTENT facebookcorewwwi csq76xfzmtyepzmkhzz2lb7ja3vmylwu UNKNOWN
OK
HS_DESC FAILED facebookcorewwwi NO_AUTH UNKNOWN REASON=QUERY_NO_HSDIR
```
I'm filing this on irl's behalf. If anything's needed from me on the stem front just let me know.Tor: 0.4.1.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25511Expose TZ info on control port for better debugging of time errors2020-06-13T17:44:06ZNick MathewsonExpose TZ info on control port for better debugging of time errorsWhen we tell people that their clocks are wrong, it's frequently because they've set up their systems with the wrong time zone. It would be helpful to tell torbrowser (or some other controller) about this information, so that it can giv...When we tell people that their clocks are wrong, it's frequently because they've set up their systems with the wrong time zone. It would be helpful to tell torbrowser (or some other controller) about this information, so that it can give more useful error messages on time-related bootstrapping failures.
~~One complication here is (IIUC) TB runs, and runs tor, with its TZ set to UTC.~~
Further investigation suggests that TB might not set `TZ` for the first time it starts tor. Opened #25823 for the Tor Launcher behavior inconsistency.Tor: 0.3.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32672Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version()2020-06-13T15:53:43ZteorReject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version()We should modify dirserv_rejects_tor_version() to keep it up to date with our supported versions:
* After 1 January 2020, we should reject all versions less than 0.3.5.
* After 2 February 2020, we should reject the 0.4.0 series, but allo...We should modify dirserv_rejects_tor_version() to keep it up to date with our supported versions:
* After 1 January 2020, we should reject all versions less than 0.3.5.
* After 2 February 2020, we should reject the 0.4.0 series, but allow the 0.3.5 series
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Current
After these dates, we should get arma to test this change, then merge it.
After we merge, we should create a ticket in 0.4.4 to reject 0.4.1.Tor: 0.4.2.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34311Space out code in relay.c2020-06-13T15:53:42ZNeel Chauhanneel@neelc.orgSpace out code in relay.cYes, I do understand that Tor is working on automatic code checks for things like code spacing and that I should work on that instead of sending spacing patches, but I still noticed a lot of spacing issues in relay.c (more than normal) s...Yes, I do understand that Tor is working on automatic code checks for things like code spacing and that I should work on that instead of sending spacing patches, but I still noticed a lot of spacing issues in relay.c (more than normal) so I just **had** to submit this.
My PR fixes all (or at least most) of relay.c.Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34245Declare variables in for loops in rend_service_dump_stats()2020-06-13T15:53:37ZNeel Chauhanneel@neelc.orgDeclare variables in for loops in rend_service_dump_stats()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34238Space out some function calls in parse_short_policy()2020-06-13T15:53:36ZNeel Chauhanneel@neelc.orgSpace out some function calls in parse_short_policy()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34237Fix spacing in if statement in tor_version_parse()2020-06-13T15:53:36ZNeel Chauhanneel@neelc.orgFix spacing in if statement in tor_version_parse()This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34236Fix spacing in if statement in port_parse_config()2020-06-13T15:53:35ZNeel Chauhanneel@neelc.orgFix spacing in if statement in port_parse_config()This line in `port_parse_config()`:
```
if ( has_used_unix_socket_only_option && ! unix_socket_path) {
```
should be:
```
if (has_used_unix_socket_only_option && !unix_socket_path) {
```This line in `port_parse_config()`:
```
if ( has_used_unix_socket_only_option && ! unix_socket_path) {
```
should be:
```
if (has_used_unix_socket_only_option && !unix_socket_path) {
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34065Make routerset_contains_router() support IPv62020-06-13T15:53:18ZteorMake routerset_contains_router() support IPv6In router_should_check_reachability(), we test to see if the current relay is in ExcludeNodes.
But ExcludeNodes doesn't support IPv6, so if a user excludes our IPv6 address, we'll just ignore that setting.
This is not a required task.
...In router_should_check_reachability(), we test to see if the current relay is in ExcludeNodes.
But ExcludeNodes doesn't support IPv6, so if a user excludes our IPv6 address, we'll just ignore that setting.
This is not a required task.
But we should probably be explicit about ignoring IPv6 in the man page.Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33956Define and use TOR_ADDRPORT_BUF_LEN2020-06-13T15:53:13ZteorDefine and use TOR_ADDRPORT_BUF_LENIn #33918, we discovered a bug where IPv6 addresses were being truncated in logs.
During the fix, we noticed that we had a TOR_ADDR_BUF_LEN, but no equivalent constant for addresses and ports. The new TOR_ADDRPORT_BUF_LEN should allow s...In #33918, we discovered a bug where IPv6 addresses were being truncated in logs.
During the fix, we noticed that we had a TOR_ADDR_BUF_LEN, but no equivalent constant for addresses and ports. The new TOR_ADDRPORT_BUF_LEN should allow space for:
* TOR_ADDR_BUF_LEN
* IPv6 brackets (2, if not included in TOR_ADDR_BUF_LEN already)
* the port separator (1)
* the port (5)
We should check for other truncation errors while making this change.Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33883Fix typo in router_build_fresh_unsigned_routerinfo() comment2020-06-13T15:53:03ZNeel Chauhanneel@neelc.orgFix typo in router_build_fresh_unsigned_routerinfo() commentThis comment in `router_build_fresh_unsigned_routerinfo()`:
```
/* If there is no valud IPv6 ORPort, the address and port are null. */
```
should be:
```
/* If there is no valid IPv6 ORPort, the address and port are null. */
```This comment in `router_build_fresh_unsigned_routerinfo()`:
```
/* If there is no valud IPv6 ORPort, the address and port are null. */
```
should be:
```
/* If there is no valid IPv6 ORPort, the address and port are null. */
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33816Fill in missing IPv6 addresses in extend cells2020-06-13T15:52:49ZteorFill in missing IPv6 addresses in extend cellsWhen an extend cell is missing an IPv6 address, tor relays could use the IPv6 address from the consensus. (If there is one.)
Similarly, if the client only supplied an IPv6 address, the relay could add an IPv4 address.
Relays already ad...When an extend cell is missing an IPv6 address, tor relays could use the IPv6 address from the consensus. (If there is one.)
Similarly, if the client only supplied an IPv6 address, the relay could add an IPv4 address.
Relays already add ed25519 keys during an extend, when the client only supplies the RSA fingerprint.
This change helps obfuscate:
* whether clients know the IPv6 addresses of relays,
* which clients implement sending IPv6 addresses in extends, and
* which clients are configured to send IPv6 addresses in extends.
This change also helps with reachability, if a relay has recently gained an IPv6 ORPort, or its IPv4 ORPort is unreliable.
It has a minor impact on testing:
* increases the number of IPv6 extends, but
* decreases the number of IPv4-only extends.
This change can be made in circuit_extend():
https://github.com/torproject/tor/pull/1801/files#diff-84b529c5e46d955c02d683463cd3317bR230
By calling a function that works like circuit_extend_add_ed25519_helper(), but adds IP addresses instead:
https://github.com/torproject/tor/pull/1801/files#diff-84b529c5e46d955c02d683463cd3317bR77Tor: 0.4.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33670Fix erroneous spaces in circuitmux_ewma.c2020-06-13T15:52:25ZNeel Chauhanneel@neelc.orgFix erroneous spaces in circuitmux_ewma.cNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33555Space out the line.key/line.value in test_policy_summary_helper_family_flags()2020-06-13T15:52:05ZNeel Chauhanneel@neelc.orgSpace out the line.key/line.value in test_policy_summary_helper_family_flags()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33463Correct spacing in dns_launch_correctness_checks()2020-06-13T15:51:52ZNeel Chauhanneel@neelc.orgCorrect spacing in dns_launch_correctness_checks()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33375Stop advertising an IPv6 exit policy when DNS is broken for IPv62020-06-13T15:51:37ZteorStop advertising an IPv6 exit policy when DNS is broken for IPv6When `dns_seems_to_be_broken_for_ipv6()`, exits should stop advertising an IPv6 exit policy.
Here's a rough design:
* when `dns_seems_to_be_broken_for_ipv6()` is first set to 1, mark the relay descriptor dirty
* when rebuilding the desc...When `dns_seems_to_be_broken_for_ipv6()`, exits should stop advertising an IPv6 exit policy.
Here's a rough design:
* when `dns_seems_to_be_broken_for_ipv6()` is first set to 1, mark the relay descriptor dirty
* when rebuilding the descriptor, check `dns_seems_to_be_broken_for_ipv6()` before including an IPv6 exit policy
* reset `dns_seems_to_be_broken_for_ipv6()` periodically, maybe every 1-3 days?Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33156DoS subsystem should compare IPv6 /642020-06-13T15:50:41ZteorDoS subsystem should compare IPv6 /64s7r writes:
> Our internal DoS defense subsystem should also treat prefixes instead of
> addresses, because right now with a client with a /64 public IPv6 prefix
> assigned to it I could hammer via IPv6 guards without triggering the DoS...s7r writes:
> Our internal DoS defense subsystem should also treat prefixes instead of
> addresses, because right now with a client with a /64 public IPv6 prefix
> assigned to it I could hammer via IPv6 guards without triggering the DoS
> defense.
https://lists.torproject.org/pipermail/tor-dev/2020-February/014144.html
We could make this change by:
* only putting the first /64 of each IPv6 address in the filter list, and
* only checking the first /64 of each new IPv6 connectionTor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32034tor reads PT protocol messages from stderr2020-06-13T15:50:03ZDavid Fifielddcf@torproject.orgtor reads PT protocol messages from stderrCreate a fake server transport plugin that writes PT protocol strings to stderr, not stdout:
```
#!/bin/sh
(
echo "VERSION 1"
echo "SMETHOD testpt 127.0.0.1:9999"
echo "SMETHODS DONE"
) 2>&1
```
Verify that it writes nothing to stdout:...Create a fake server transport plugin that writes PT protocol strings to stderr, not stdout:
```
#!/bin/sh
(
echo "VERSION 1"
echo "SMETHOD testpt 127.0.0.1:9999"
echo "SMETHODS DONE"
) 2>&1
```
Verify that it writes nothing to stdout:
```
$ ./testpt.stderr.sh >/dev/null | wc
0 0 0
```
Run tor with this torrc:
```
PublishServerDescriptor 0
AssumeReachable
SOCKSPort 0
ORPort auto
ServerTransportPlugin testpt exec ./testpt.stderr.sh
Bridge testpt 127.0.0.1:9999
```
A log line shows that tor has interpreted PT protocol messages from stderr, when it should only be looking for them on stdout.
```
Oct 10 16:21:11.000 [notice] Registered server transport 'testpt' at '127.0.0.1:9999'
```
----
I think this is a bug. [pt-spec says](https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt?id=d890052d5525a09829c798ab0ad6dcdcede1a8ef#n368) "All Pluggable Transport Proxies communicate to the parent process via writing NL-terminated lines to stdout." It does not say that tor should inspect stderr and interpret any lines that happen to be a well-formed PT protocol message that it finds there, as if they had been sent on stdout.
The only mention of stderr in the spec is [in the context of LOG and STATUS](https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt?id=d890052d5525a09829c798ab0ad6dcdcede1a8ef#n599), and that is [a fairly recent addition](https://gitweb.torproject.org/torspec.git/commit/pt-spec.txt?id=d890052d5525a09829c798ab0ad6dcdcede1a8ef) with #28179/#28181. I always thought that the intention was to copy anything seen on stderr to tor's log, as if it had been part of a LOG message on stdout. The mention of stderr in relation to STATUS is something I missed during review of that part of the spec, because I don't think it makes sense there.
What I expected to see was this, treating verbatim stderr lines as things to be logged:
```
[notice] Unknown line received by managed proxy (VERSION 1)
[notice] Unknown line received by managed proxy (SMETHOD testpt 127.0.0.1:9999)
[notice] Unknown line received by managed proxy (SMETHODS DONE)
```
Otherwise, tor is essentially holding transport plugins to a contract that is unstated in the spec: transport plugins cannot safely write anything to stderr at all, because there is always a danger that a future version of tor will recognize it as a PT message and interpret it, instead of just logging it.Tor: 0.4.3.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.org