The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:02:32Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13153version_supports_optimistic_data is obsolete2020-06-27T14:02:32ZRoger Dingledineversion_supports_optimistic_data is obsolete```
rs->version_supports_optimistic_data =
tor_version_as_new_as(tok->args[0], "0.2.3.1-alpha");
```
There aren't any relays in the network for which this check will be false.```
rs->version_supports_optimistic_data =
tor_version_as_new_as(tok->args[0], "0.2.3.1-alpha");
```
There aren't any relays in the network for which this check will be false.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13221Misleading error messages about bind_ipv4_only and bind_ipv6_only?2020-06-27T14:02:28ZRoger DingledineMisleading error messages about bind_ipv4_only and bind_ipv6_only?```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with t...```
if (bind_ipv4_only && tor_addr_family(&addr) == AF_INET6) {
log_warn(LD_CONFIG, "Could not interpret %sPort address as IPv6",
portname);
goto err;
}
```
Is this warn mixed up? Same with the one below it.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13314Send back more SOCKS5 errors where appropriate.2020-06-27T14:02:24ZYawning AngelSend back more SOCKS5 errors where appropriate.As a follow up to legacy/trac#12971, our SOCKS5 code can now send back specific errors in response to requests fairly easily. A quick glance through the code suggests that the following cases (at a minimum) should be changed to do the r...As a follow up to legacy/trac#12971, our SOCKS5 code can now send back specific errors in response to requests fairly easily. A quick glance through the code suggests that the following cases (at a minimum) should be changed to do the right thing:
* Invalid/malformed address (`SOCKS5_ADDRESS_TYPE_NOT_SUPPORTED`, `SOCKS5_GENERAL_ERROR`, `SOCKS5_NOT_ALLOWED` depending on the case)
* CONNECT command while SafeSocks is set to an IP address (`SOCKS5_NOT_ALLOWED`)
One could argue that legacy/trac#11138 would magically fix these things as well, but since returning errors is a one line addition (and the unit tests) per case, there's no reason not to make the changes now.Tor: 0.2.6.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13315Our SOCKS hostname validation is overly lax.2020-06-27T14:02:24ZYawning AngelOur SOCKS hostname validation is overly lax.This applies to both SOCKS4a and SOCKS5.
What we check (for rejection): `!tor_strisprint(req->address) || strchr(req->address,'\"')`
What the RFC says (RFC 1035 - 2.3.1. Preferred name syntax):
```
<domain> ::= <subdomain> | " "
<subd...This applies to both SOCKS4a and SOCKS5.
What we check (for rejection): `!tor_strisprint(req->address) || strchr(req->address,'\"')`
What the RFC says (RFC 1035 - 2.3.1. Preferred name syntax):
```
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
```
Changing the check to enforce isalnum(), '.' and '-' would cut out a lot more things that are flat out invalid.
The one concern (raised by nickm) is "are there clients that send IPv6 addresses as FQDNs"? This is plausible for SOCKS4a (because it's the only way to get IPv6 support to work), and a sign of broken client that deserves to be laughed at for SOCKS5. Calling `tor_inet_pton()` on the FQDN before filtering will cover this case (and is probably something we should do anyway for SafeSocks).
This may be another legacy/trac#11138 will fix it sort of issue, though the changes are likewise trivial to do.rl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/13477Memwipe more keys after tor is finished using them2020-06-27T14:02:21ZteorMemwipe more keys after tor is finished using themI think crypto_digest_get_digest and init_curve25519_keypair_from_file aren't memwiping all their key memory.
I'll list the details of a branch when the changes file is done.I think crypto_digest_get_digest and init_curve25519_keypair_from_file aren't memwiping all their key memory.
I'll list the details of a branch when the changes file is done.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13538Stop signed left shift overflows in curve25519-donna (non-64-bit)2020-06-27T14:02:20ZteorStop signed left shift overflows in curve25519-donna (non-64-bit)Similarly to legacy/trac#13280, the curve25519-donna.c code contains some signed left shifts of negative numbers, which clang identifies as runtime errors. (This is only an issue with the generic code, not the 64-bit code.)
Under -ftrap...Similarly to legacy/trac#13280, the curve25519-donna.c code contains some signed left shifts of negative numbers, which clang identifies as runtime errors. (This is only an issue with the generic code, not the 64-bit code.)
Under -ftrapv, this causes a trap/crash.
I've used a similar strategy to the one in legacy/trac#13280, where we automate the entire SHL32/SHL64 conversion using a perl script. The first commit sets up the macros.
The safe SHL32/SHL64 macros perform potentially overflowing left shifts in unsigned arithmetic.
I'll post a branch as soon as I've set up a change entry (for which I need the bug number).
Version: tor 2.6.?-alpha
git: fc5cab44724e8328e2186f22114625388f1c8f0d (Thu Oct 16 13:29:14 2014 -0400)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13605Create a client/relay-side ReducedExitPolicy2020-06-27T14:02:18ZMike PerryCreate a client/relay-side ReducedExitPolicyWe should have an "ExitPolicy Reduced" or "ReducedExitPolicy 1" torrc option for relay operators to more easily opt in to https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy.
We have a lot of people doing this on an ad-h...We should have an "ExitPolicy Reduced" or "ReducedExitPolicy 1" torrc option for relay operators to more easily opt in to https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy.
We have a lot of people doing this on an ad-hoc basis. We should make it official.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13736Kill the DynamicDHGroups feature2020-06-27T14:02:14ZGeorge KadianakisKill the DynamicDHGroups featureIn legacy/trac#4548 we implemented the `DynamicDHGroups` feature of prop179 which we ended up never using. It's pretty clear now that we will never use it at all, because we have PTs to do this job.
Since the code is non-trivial, I sugg...In legacy/trac#4548 we implemented the `DynamicDHGroups` feature of prop179 which we ended up never using. It's pretty clear now that we will never use it at all, because we have PTs to do this job.
Since the code is non-trivial, I suggest we kill it completely from the current codebase.
Seems like a good volunteer task too.Tor: 0.2.7.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13813Add router_have_consensus_path() as status/consensus-exit GETINFO control event2020-06-27T14:02:11ZteorAdd router_have_consensus_path() as status/consensus-exit GETINFO control eventSplit from legacy/trac#13718:
We could add router_have_consensus_path() as a GETINFO control event called status/consensus-exit or something.
But this is low priority, as knowing that the consensus is missing exits only impacts on test ...Split from legacy/trac#13718:
We could add router_have_consensus_path() as a GETINFO control event called status/consensus-exit or something.
But this is low priority, as knowing that the consensus is missing exits only impacts on test networks.
These details have been obsoleted by changes in legacy/trac#13718:
~~> We may also need to update the status/enough-dir-info GETINFO control event - should we add status/enough-dir-info/exit and status/enough-dir-info/internal (we default status/enough-dir-info to exit for backwards compatibility).~~
nickm:
Sounds fine, though it could be a separate ticket.
Note: the relevant code is located in src/or/control.c in getinfo_helper_events() around line 2019.https://gitlab.torproject.org/tpo/core/tor/-/issues/13840Refactor? Use END_CIRC_REASON_TORPROTOCOL rather than "1" in connection_exit_...2020-06-27T14:02:09ZRoger DingledineRefactor? Use END_CIRC_REASON_TORPROTOCOL rather than "1" in connection_exit_begin_conn()In the function comment for connection_exit_begin_conn() we see
```
* Return -(some circuit end reason) if we want to tear down <b>circ</b>.
* Else return 0.
```
and then at the front of the function we see
```
if (rh.length > RELAY_...In the function comment for connection_exit_begin_conn() we see
```
* Return -(some circuit end reason) if we want to tear down <b>circ</b>.
* Else return 0.
```
and then at the front of the function we see
```
if (rh.length > RELAY_PAYLOAD_SIZE)
return -1;
```
Now, it happens that 1 is END_CIRC_REASON_TORPROTOCOL, which is a legitimate reason to use in this case. But did we just get lucky?
Later there's also a
```
if (r < -1) {
return -1;
```
If we want to go wilder with the change here, I think this function actually only ever returns 0 and -1, so it's not actually following the function comment and we could get rid of that part of it instead?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13862No error message when fatally failing to open files in DataDirectory2020-06-27T14:02:09ZTracNo error message when fatally failing to open files in DataDirectoryDue to installing packages from conflicting sources, I ended up with a Tor installation where the tor daemon (with `User toranon`) could access the DataDirectory, but not open the files in it for lack of permissions.
In this situation, ...Due to installing packages from conflicting sources, I ended up with a Tor installation where the tor daemon (with `User toranon`) could access the DataDirectory, but not open the files in it for lack of permissions.
In this situation, tor exits quickly with only the following messages:
```
Nov 30 00:07:12.878 [notice] Tor v0.2.5.10 (git-42b42605f8d8eac2) running on Linux with Libevent 2.0.18-stable, OpenSSL 1.0.1e-fips and Zlib 1.2.7.
Nov 30 00:07:12.878 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Nov 30 00:07:12.878 [notice] Read configuration file "/usr/share/tor/defaults-torrc".
Nov 30 00:07:12.878 [notice] Read configuration file "/etc/tor/torrc".
Nov 30 00:07:12.881 [notice] Opening Socks listener on 127.0.0.1:9050
Nov 30 00:07:12.881 [notice] Opening Control listener on 127.0.0.1:9151
Nov 30 00:07:12.881 [notice] Caching new entry toranon for toranon
Nov 30 00:07:12.881 [notice] Caching new entry toranon for toranon
```
There are no explicit `Log` directives in torrc.
Except for exit status 1, there is no indication to the user that something has gone wrong, and what the problem could be. We should print a helpful error message.
**Trac**:
**Username**: sqrt2Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14015Elevate HidServAuth authorized log level from debug to info2020-06-27T14:02:03ZcypherpunksElevate HidServAuth authorized log level from debug to infoCan you please elevate the HidServAuth authorized log level from debug level to info level?
I believe it's in src/or/rendservice.c
```
/* Allow the request. */
log_debug(LD_REND, "Client %s authorized for service %s.",
...Can you please elevate the HidServAuth authorized log level from debug level to info level?
I believe it's in src/or/rendservice.c
```
/* Allow the request. */
log_debug(LD_REND, "Client %s authorized for service %s.",
auth_client->client_name, service->service_id);
```
Thanks.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14055Implement TestingDirAuthVoteHSDir like TestingDirAuthVoteGuard/Exit2020-06-27T14:02:02ZteorImplement TestingDirAuthVoteHSDir like TestingDirAuthVoteGuard/Exitasn is working on legacy/trac#8243: "Getting the HSDir flag should require more effort".
This may require a TestingDirAuthVoteHSDir flag for hidden services to continue to work in test networks.asn is working on legacy/trac#8243: "Getting the HSDir flag should require more effort".
This may require a TestingDirAuthVoteHSDir flag for hidden services to continue to work in test networks.https://gitlab.torproject.org/tpo/core/tor/-/issues/14137Make Tor tests pass under Wine2020-06-27T14:01:59ZNick MathewsonMake Tor tests pass under WineRight now, there are some failures and some weird warnings when you build Tor with mingw and try to run the unit tests under Wine.
Obviously, this isn't really supported or essential, but it would be nice for unix-based devs if it worked.Right now, there are some failures and some weird warnings when you build Tor with mingw and try to run the unit tests under Wine.
Obviously, this isn't really supported or essential, but it would be nice for unix-based devs if it worked.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14185Make src/test/test-network.sh and friends handle out-of-tree builds2020-06-27T14:01:58ZteorMake src/test/test-network.sh and friends handle out-of-tree buildsMake src/test/test-network.sh handle out-of-tree builds by removing the assumption that we will always be in the tor directory when building.
Add code to src/test/test-network.sh like:
```
TOR_PATH="`dirname $0`/../or/tor"
```
A simila...Make src/test/test-network.sh handle out-of-tree builds by removing the assumption that we will always be in the tor directory when building.
Add code to src/test/test-network.sh like:
```
TOR_PATH="`dirname $0`/../or/tor"
```
A similar change was made to src/test/zero_length_keys.sh in legacy/trac#13111.
Review other scripts to see if they have the same issue.https://gitlab.torproject.org/tpo/core/tor/-/issues/14312tor-spec says additional fields in exitpolicy response are "optional" when th...2020-06-27T14:01:54ZRoger Dingledinetor-spec says additional fields in exitpolicy response are "optional" when they're notA #tor user reported seeing
```
if (rh.length < 9) { /* reason+ipv4+dns_ttl */
log_notice(LD_PROTOCOL,
"Short path bias probe response length field (%d).", rh.length);
return - END_CIRC_REASON_TORPROTOCOL;
...A #tor user reported seeing
```
if (rh.length < 9) { /* reason+ipv4+dns_ttl */
log_notice(LD_PROTOCOL,
"Short path bias probe response length field (%d).", rh.length);
return - END_CIRC_REASON_TORPROTOCOL;
}
```
I think this was triggered by Tom's new relay implementation.
It turns out our spec says
```
The payload of a RELAY_END cell begins with a single 'reason' byte to
describe why the stream is closing, plus optional data (depending on
the reason.)
[...]
(With REASON_EXITPOLICY, the 4-byte IPv4 address or 16-byte IPv6 address
forms the optional data, along with a 4-byte TTL; no other reason
currently has extra data.)
```
Tom and I are now thinking that this word 'optional' means 'required for some types of end cells but not included in others'. But he misinterpreted 'optional' to mean 'you don't have to implement it'. Which is a fine interpretation, except Tor clients complain at log-level notice when you don't.
I think it was originally optional because some very old Tor versions didn't implement it. But now they all do (well, up until yesterday, when Tom's version came online). Should we just make this extra data for reason-exitpolicy be optionally mandatory?Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14764powerpc32 compilation failures due to char signedness issues.2020-06-27T14:01:49ZYawning Angelpowerpc32 compilation failures due to char signedness issues.Originally reported in: https://lists.torproject.org/pipermail/tor-dev/2015-February/008231.html
One of the scheduler functions uses a `char` as an argument to pass a `-1`/`1` value, which causes GCC to issue warnings on platforms where...Originally reported in: https://lists.torproject.org/pipermail/tor-dev/2015-February/008231.html
One of the scheduler functions uses a `char` as an argument to pass a `-1`/`1` value, which causes GCC to issue warnings on platforms where `char` defaults to unsigned. While the patch does address the issue, after discussion with nickm, the argument is better changed to an int.Tor: 0.2.6.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14922Kill tor_strclear() with fire, and replace it with memwipe().2020-06-27T14:01:44ZYawning AngelKill tor_strclear() with fire, and replace it with memwipe().Per nickm, "IMO: delete that function; change its three users to use memwipe".
Not sure about the milestone for this, tentatively setting it to 0.2.7.x, though previously stored client keys for rend services are sanitized using this, so...Per nickm, "IMO: delete that function; change its three users to use memwipe".
Not sure about the milestone for this, tentatively setting it to 0.2.7.x, though previously stored client keys for rend services are sanitized using this, so it might be a 0.2.6.x thing.Tor: 0.2.7.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15043Use acx_pthread.m4 to find pthreads library2020-06-27T14:01:40ZNick MathewsonUse acx_pthread.m4 to find pthreads libraryIn legacy/trac#9495, we noticed that (it seems) we aren't taking any efforts to compile with threading right on some platforms. Let's fix that by not trying to figure it out ourselves. The acx_pthread.m4 autoconf module is just fine; l...In legacy/trac#9495, we noticed that (it seems) we aren't taking any efforts to compile with threading right on some platforms. Let's fix that by not trying to figure it out ourselves. The acx_pthread.m4 autoconf module is just fine; let's use that in 0.2.7. (It's probably too late to do this in 0.2.6; this is a fiddly part of our build system)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15381cosmetic issue in log message : v0.1.2.3 versus 0.2.3.42020-06-27T14:01:30Ztoralfcosmetic issue in log message : v0.1.2.3 versus 0.2.3.4The following 2 subsequent log messages let me wonder, why there's a "v" in one, but not in the other (or why is there)
```
Mar 19 21:18:25.000 [notice] Tor 0.2.6.5-rc (git-e0b77cd3194d705f) opening log file. ...The following 2 subsequent log messages let me wonder, why there's a "v" in one, but not in the other (or why is there)
```
Mar 19 21:18:25.000 [notice] Tor 0.2.6.5-rc (git-e0b77cd3194d705f) opening log file.
Mar 19 21:18:25.258 [notice] Tor v0.2.6.5-rc (git-e0b77cd3194d705f) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.1l and Zlib 1.2.8.
```Tor: 0.2.9.x-final