The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-22T16:25:48Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15543Undocumented + and / for config options2021-07-22T16:25:48ZDamian JohnsonUndocumented + and / for config optionsFrom legacy/trac#14742, we have special behaviour when a config option when a config option is passed on the commandline with a '+' or '/'...
https://gitweb.torproject.org/stem.git/tree/test/integ/process.py#n199
This looks to presentl...From legacy/trac#14742, we have special behaviour when a config option when a config option is passed on the commandline with a '+' or '/'...
https://gitweb.torproject.org/stem.git/tree/test/integ/process.py#n199
This looks to presently be undocumented. Obvious guess is 'adds/removed from existing config rather than replacing' but I'm getting some unexpected behavior when I pass '/PublishServerDescriptor'. Probably only works properly for LineList arguments.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15518Tor considers routers in the same IPv6 /16 to be "in the same subnet"2020-06-27T14:01:27ZIsis 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 legacy/trac#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/tpo/core/tor/-/issues/15471Tor should prctl(PR_SET_PDEATHSIG, SIGTERM) background processes.2020-06-27T14:01:28ZYawning AngelTor should prctl(PR_SET_PDEATHSIG, SIGTERM) background processes.From the man page:
```
PR_SET_PDEATHSIG (since Linux 2.1.57)
Set the parent process death signal of the calling process to
arg2 (either a signal value in the range 1..maxsig, or 0 to
...From the man page:
```
PR_SET_PDEATHSIG (since Linux 2.1.57)
Set the parent process death signal of the calling process to
arg2 (either a signal value in the range 1..maxsig, or 0 to
clear). This is the signal that the calling process will get
when its parent dies. This value is cleared for the child of a
fork(2) and (since Linux 2.4.36 / 2.6.23) when executing a set-
user-ID or set-group-ID binary, or a binary that has associated
capabilities (see capabilities(7)). This value is preserved
across execve(2).
```
This will ensure at least on Linux that all background processes will get a `SIGTERM` if Tor dies, and can cleanup appropriately.
I don't think this behavior would be particularly shocking to PT developers (who should be handling SIGTERM already), so this probably doesn't even need a spec patch since "tor dying" invoking the normal termination signaling is appropriate.
The choice of `SIGTERM` over `SIGKILL` here is so that PTs have the option to trap it and terminate their own children as appropriate.
Pros:
* Easy to do.
* The kernel does all of the heavy lifting for us, as a catchall.
* Fixes certain nasty issues in unmodified pt code on the relevant platform automatically.
Cons:
* Non-portable (legacy/trac#15435 aka legacy/trac#10047 is a portable fix that requires pt modification).
* We have pts (obfs4proxy in particular) that can be ran with elevated capabilities.Tor: 0.2.7.x-finalhttps://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-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15333Minor control-spec.txt corrections.2021-07-22T16:25:47ZYawning AngelMinor control-spec.txt corrections.Re: SETCONF:
> Tor responds with a "250 configuration values set" reply on success.
> If some of the listed keywords can't be found, Tor replies with a
According to git blame that hasn't been the case since... 2008? 2007?
```
...Re: SETCONF:
> Tor responds with a "250 configuration values set" reply on success.
> If some of the listed keywords can't be found, Tor replies with a
According to git blame that hasn't been the case since... 2008? 2007?
```
case SETOPT_OK:
config_free_lines(lines);
send_control_done(conn);
return 0;
```
> Sent from the client to the server. The syntax is as for GETCONF:
> "GETINFO" 1*(SP keyword) CRLF
> one or more NL-terminated strings. The server replies with an INFOVALUE
> message, or a 551 or 552 error.
"one or nor NL-terminated strings" is confusing. Did a newline and a word get cutoff somewhere, or am I just being dense?Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15214networkstatus_compute_consensus() is unreasonably large and should be refactored2021-09-16T14:35:00ZAndrea Shepardnetworkstatus_compute_consensus() is unreasonably large and should be refactoredI count 874 lines (while auditing strlcat()/strlcpy() calls). Did Minicode raise our function call ration from 25 to 20 per 100 kloc the week this was written?I count 874 lines (while auditing strlcat()/strlcpy() calls). Did Minicode raise our function call ration from 25 to 20 per 100 kloc the week this was written?Tor: unspecifiedhttps://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/15019Most FooStatistics entries in the man page don't mention ExtraInfo descriptors2021-07-22T16:25:47ZRoger DingledineMost FooStatistics entries in the man page don't mention ExtraInfo descriptors```
ConnDirectionStatistics 0|1
When this option is enabled, Tor writes statistics on the
bidirectional use of connections to disk every 24 hours. (Default:
0)
HiddenServiceStatistics 0|1
...```
ConnDirectionStatistics 0|1
When this option is enabled, Tor writes statistics on the
bidirectional use of connections to disk every 24 hours. (Default:
0)
HiddenServiceStatistics 0|1
When this option is enabled, a Tor relay writes obfuscated
statistics on its role as hidden-service directory, introduction
point, or rendezvous point to disk every 24 hours. If
ExtraInfoStatistics is also enabled, these statistics are further
published to the directory authorities. (Default: 0)
ExtraInfoStatistics 0|1
When this option is enabled, Tor includes previously gathered
statistics in its extra-info documents that it uploads to the
directory authorities. (Default: 1)
```
Most of the man page entries for FooStatistics are like ConnDirectionStatistics -- they just talk about writing to disk. Then tucked away elsewhere is this ExtraInfoStatistics thing that says "previously gathered statistics".
It sounds like we should make much clearer that some of these go into the extrainfo descriptor and get published to the outside world?
And are there some of them that *don't* get published to the outside world? It's not immediately obvious from looking at the code.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15015tor --verify-config should not bind to ports2021-09-16T14:35:00Zcypherpunkstor --verify-config should not bind to portshttps://lists.torproject.org/pipermail/tor-talk/2015-February/036973.html
maybe we can also get rid of the 'requires root privileges' - thing?
https://lists.torproject.org/pipermail/tor-talk/2015-February/036970.htmlhttps://lists.torproject.org/pipermail/tor-talk/2015-February/036973.html
maybe we can also get rid of the 'requires root privileges' - thing?
https://lists.torproject.org/pipermail/tor-talk/2015-February/036970.htmlTor: 0.3.4.x-finalrl1987rl1987https://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/14854Document the hardlimit of HiddenServiceAuthorizeClient basic2022-02-07T19:38:03ZcypherpunksDocument the hardlimit of HiddenServiceAuthorizeClient basicI ran some tests on HiddenServiceAuthorizeClient basic auth-type and found that it stopped working when I created 49 or more clients.
I started with 10 clients and kept adding 10 more at a time. When I had 39 clients, the hidden service ...I ran some tests on HiddenServiceAuthorizeClient basic auth-type and found that it stopped working when I created 49 or more clients.
I started with 10 clients and kept adding 10 more at a time. When I had 39 clients, the hidden service worked, but when I added 10 more, the hostname and client_keys were generated as expected, but hidden service stopped working for all of the clients.
HiddenServiceDir /var/lib/tor/test_public/ # tlxnxx74fpmkw2qh.onion
HiddenServicePort 80 127.0.0.1:80
HiddenServiceAuthorizeClient basic \
tlx_cl01, \
tlx_cl02, \
tlx_cl03, \
...
tlx_cl47, \
tlx_cl48, \
tlx_cl49
According to the man page and the specs, the stealth mode doesn't work for more than 16 clients, but implied that the basic mode should work.https://gitlab.torproject.org/tpo/core/tor/-/issues/14828Multiple hidden services can share a pk_digest/service_id.2021-09-16T14:35:00ZYawning AngelMultiple hidden services can share a pk_digest/service_id.This may be a duplicate, it's past my bed time, so I don't have time to check.
The current rendservice code's duplication check doesn't enforce uniqueness of `pk_digest` and `service_id`. It probably should do so for both things, since...This may be a duplicate, it's past my bed time, so I don't have time to check.
The current rendservice code's duplication check doesn't enforce uniqueness of `pk_digest` and `service_id`. It probably should do so for both things, since I can't think of a reason why this would ever be well defined, or desirable behavior.
The trivial fix would be to add a pair of checks to `rendservice.c:rend_service_load_keys(s)`, that log on LD_CONFIG, and return an error if a collision is detected.https://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/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/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/14164Controller method to get our own descriptor2022-06-17T13:39:26ZtoralfController method to get our own descriptorI'm wondering why this pythin snippet
```
def main():
ControlPort = 9051
ProcessName = 'tor'
with Controller.from_port(port = ControlPort) as controller:
controller.authenticate()
#print " Tor version %s" % controller.get_...I'm wondering why this pythin snippet
```
def main():
ControlPort = 9051
ProcessName = 'tor'
with Controller.from_port(port = ControlPort) as controller:
controller.authenticate()
#print " Tor version %s" % controller.get_version()
try:
desc = controller.get_microdescriptor()
print " flags : %s" % desc.flags()
print " measured bandwidth : %i" % desc.measured()
except Exception as exc:
print exc
#pass
```
gives
```
Tor was unable to provide the descriptor for 'F1BE15429B3CE696D6807F4D4A58B1BFEC45C822'
```
Does this means that stems asks tor and tor doesn't know itself ?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/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/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/13913Undocumented HS behavior with relative paths2021-07-22T16:25:47ZDamian JohnsonUndocumented HS behavior with relative pathsTor accepts relative paths for HiddenServiceDir...
```
>>> GETCONF HiddenServiceOptions
250-HiddenServiceDir=hidden_service_example
250 HiddenServicePort=80 127.0.0.1:5000
```
This seems to result in the HiddenServiceDir being relative...Tor accepts relative paths for HiddenServiceDir...
```
>>> GETCONF HiddenServiceOptions
250-HiddenServiceDir=hidden_service_example
250 HiddenServicePort=80 127.0.0.1:5000
```
This seems to result in the HiddenServiceDir being relative of the tor process' cwd, rather than the DataDir which I kinda expected. This is all well and good, but should be [noted in the manpage](https://www.torproject.org/docs/tor-manual.html.en#HiddenServiceDir).
It's a tiny bit unfortunate that 'GETCONF HidddenServiceOptions' then provides back relative paths, since controllers need to read the HiddenServiceDir to determine the hostname (at least until legacy/trac#1949), but not a terribly big whoop. :)Tor: 0.2.6.x-final