The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:58:57Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19167torrc parsing b0rks on carriage-return2020-06-27T13:58:57Zcypherpunkstorrc parsing b0rks on carriage-returnWindows still terminates text files with '\r\n' by default, this seems to break the handling of quoted values in torrc.
https://gitweb.torproject.org/tor.git/tree/src/common/util.c#n2899
It consumes the quoted string, then consumes any...Windows still terminates text files with '\r\n' by default, this seems to break the handling of quoted values in torrc.
https://gitweb.torproject.org/tor.git/tree/src/common/util.c#n2899
It consumes the quoted string, then consumes any trailing whitespace (tabs or spaces), then it expects either a comment '#' or an '\n'. However if a file edited through notepad.exe for example, the first character it encounters would be '\r', preceding the '\n'.
This results in tor throwing: "[warn] Error while parsing configuration: Excess data after quoted string" then erroring out.
Testing on 0.2.7.6.
Steps to reproduce:
`$ printf "SocksPort 54321\nDataDirectory \"/tmp/datadir\"\r\n" > /tmp/conf`
`$ tor -f /tmp/conf`
`...[notice] Tor v0.2.7.6 (git-605ae665009853bd) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2h and Zlib 1.2.8`
`...[notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning`
`...[notice] Read configuration file "/tmp/conf".`
`...[warn] Error while parsing configuration: Excess data after quoted string`
`...[err] Reading config failed--see warnings above.`
`$`Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19153man page spells --enable-tor2web-mode --enable-tor2webmode2021-07-22T16:23:44ZTracman page spells --enable-tor2web-mode --enable-tor2webmode```
l@tp ~/code/tor [master] $ ack enable-tor2webmode
doc/tor.1.txt
1429: To enable this option the compile time flag --enable-tor2webmode must be
```
```
l@tp ~/code/tor [master] $ ack enable-tor2w...```
l@tp ~/code/tor [master] $ ack enable-tor2webmode
doc/tor.1.txt
1429: To enable this option the compile time flag --enable-tor2webmode must be
```
```
l@tp ~/code/tor [master] $ ack enable-tor2web-mode
configure.ac
171: AS_HELP_STRING(--enable-tor2web-mode, [support tor2web non-anonymous mode]),
config.status
430:ac_cs_config="'--enable-tor2web-mode' '--disable-asciidoc'"
522: set X /bin/bash './configure' '--enable-tor2web-mode' '--disable-asciidoc' $ac_configure_extra_args --no-create --no-recursion
configure
1456: --enable-tor2web-mode support tor2web non-anonymous mode
3485:# Check whether --enable-tor2web-mode was given.
config.log
7: $ ./configure --enable-tor2web-mode --disable-asciidoc
src/or/config.c
1516: "--enable-tor2web-mode option.");
```
**Trac**:
**Username**: joelandersTor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19138Received extra server info (size 0)2021-07-09T17:22:00ZteorReceived extra server info (size 0)What is a size 0 server info?
Should we mention it at all?
```
May 15 23:02:05.000 [info] connection_dir_client_reached_eof: Received extra server info (size 0) from server 'address redacted'
```What is a size 0 server info?
Should we mention it at all?
```
May 15 23:02:05.000 [info] connection_dir_client_reached_eof: Received extra server info (size 0) from server 'address redacted'
```https://gitlab.torproject.org/tpo/core/tor/-/issues/19122Documentation for "User" option specifies wrong kind of argument2021-07-22T16:23:44ZTracDocumentation for "User" option specifies wrong kind of argumenthttps://www.torproject.org/docs/tor-manual.html.en
User UID
On startup, setuid to this user and setgid to their primary group.
A UID is an integer in unix speak, not a username. The description of
the value uses "uid" correctly in t...https://www.torproject.org/docs/tor-manual.html.en
User UID
On startup, setuid to this user and setgid to their primary group.
A UID is an integer in unix speak, not a username. The description of
the value uses "uid" correctly in the function names, but the option
should say "username" because that is the only value it supports.
**Trac**:
**Username**: chadmillerTor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19063The tor_parse_* functions should check and warn on max < min2020-06-27T13:59:03ZteorThe tor_parse_* functions should check and warn on max < minIf a developer mistakenly calls:
```
tor_parse_long(value, 10, 1, UINT32_MAX, NULL, NULL);
```
It effectively becomes:
```
tor_parse_long(value, 10, 1, -1, NULL, NULL);
```
We can detect this by making sure `min <= max`, and warning if...If a developer mistakenly calls:
```
tor_parse_long(value, 10, 1, UINT32_MAX, NULL, NULL);
```
It effectively becomes:
```
tor_parse_long(value, 10, 1, -1, NULL, NULL);
```
We can detect this by making sure `min <= max`, and warning if that's not the case. (I really don't think we should assert.)
We should do this for all similar tor_parse_* functions.
But are there any circumstances where we should allow min to be greater than max? (it will always fail)
Existing callers pass constants to this function, so it's not going to trigger for them.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19060Should SafeLogging hide bridge IP addresses in logs?2020-06-27T13:59:03ZteorShould SafeLogging hide bridge IP addresses in logs?Bridge relay operators sometimes post logs containing their bridge's IP address.
We could make this less likely by making `SafeLogging 1` (the default) filter bridge IP addresses in messages like:
* "Your server (%s:%d) has not managed ...Bridge relay operators sometimes post logs containing their bridge's IP address.
We could make this less likely by making `SafeLogging 1` (the default) filter bridge IP addresses in messages like:
* "Your server (%s:%d) has not managed to confirm that its ORPort is reachable" ...
* "Your server (%s:%d) has not managed to confirm that its DirPort is reachable" ...
* "Now checking whether ORPort %s:%d"...
* "and DirPort %s:%d"
* anything else that lists a bridge's IP or fingerprint
This could be implemented by creating safe_str_bridge and escaped_safe_str_bridge similar to safe_str and escaped_safe_str, but with a check if BridgeRelay is 1 as well. It would also need a tor manual page update that says that we escape bridge information when SafeLogging is anything besides "0".
Or, we could add "bridge" to the options for SafeLogging, but that seems over-complicated, because we'd have to define 1 vs relay vs bridge semantics in a way that makes sense.Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/19034Declaring authorities with matching relay keys should fail2020-07-27T19:17:38ZteorDeclaring authorities with matching relay keys should failIf a:
* hard-coded entry or
* config entry,
tries to add:
* an authority,
* a bridge authority, or
* a fallback directory,
with the same:
* relay key,
* v3ident key,
* IPv4 address and ORPort (matching any other IPv4 address and port)...If a:
* hard-coded entry or
* config entry,
tries to add:
* an authority,
* a bridge authority, or
* a fallback directory,
with the same:
* relay key,
* v3ident key,
* IPv4 address and ORPort (matching any other IPv4 address and port), or
* IPv4 address and DirPort (matching any other IPv4 address and port),
* IPv6 address and ORPort (matching any other IPv6 address and port), or
* IPv6 address and (IPv4) DirPort (matching any other IPv6 address and port),
as an existing entry, tor should warn and refuse to start.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19013Authorities should log a more accurate message when reachability checks fail2020-07-27T19:12:58ZteorAuthorities should log a more accurate message when reachability checks failAuthorities check reachability even though they assume they are reachable:
```
May 10 01:31:46.000 [warn] Your server (52.27.2.173:8299) has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until the...Authorities check reachability even though they assume they are reachable:
```
May 10 01:31:46.000 [warn] Your server (52.27.2.173:8299) has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
May 10 01:31:46.000 [warn] Your server (52.27.2.173:34237) has not managed to confirm that its DirPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
```
We should improve these messages for authorities.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18988log error level messages if relay (self) is not in consensus2021-06-18T18:13:21Zcypherpunkslog error level messages if relay (self) is not in consensusTor (relay mode) should check once an hour if his fingerprint is included in the consensus and if that is not the case log a prominent error level entry telling the operator about the problem.
In the past I noticed such a log but appare...Tor (relay mode) should check once an hour if his fingerprint is included in the consensus and if that is not the case log a prominent error level entry telling the operator about the problem.
In the past I noticed such a log but apparently it is not done every hour.
I.e. relay dropped out of consensus >4 hours ago, but there is no log entry about it.
Is HeartbeatPeriod (default 6 hours) relevant for that?https://gitlab.torproject.org/tpo/core/tor/-/issues/18982Tor should log 1-based hop numbers2020-06-27T13:59:08ZteorTor should log 1-based hop numbersThe control-spec says hops are 1-based, and we often log "first hop":
```
If HOP=HopNum is specified, Tor will choose the HopNumth hop in the
circuit as the exit node, rather than the last node in the circuit.
Hops are 1-indexed; g...The control-spec says hops are 1-based, and we often log "first hop":
```
If HOP=HopNum is specified, Tor will choose the HopNumth hop in the
circuit as the exit node, rather than the last node in the circuit.
Hops are 1-indexed; generally, it is not permitted to attach to hop 1.
```
But the following functions log 0-based hops:
* choose_good_middle_server
* onion_extend_cpath (which also logs a 1-based hop message as well)
We need to add 1 to the 0-based hop counts in these functions.
Credit to Xiaofan Li for discovering this issue.Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18938Authorities should reject non-UTF-8 content in ExtraInfo descriptors2020-06-27T13:59:09ZteorAuthorities should reject non-UTF-8 content in ExtraInfo descriptorsIn legacy/trac#18656, we discovered that authorities don't validate that ExtraInfo descriptors are printable ASCII before accepting them.
Authorities (and HSDirs) should check every ~~directory~~ extrainfo document they receive consists...In legacy/trac#18656, we discovered that authorities don't validate that ExtraInfo descriptors are printable ASCII before accepting them.
Authorities (and HSDirs) should check every ~~directory~~ extrainfo document they receive consists only of ~~"printing ASCII"~~ UTF-8, as defined in ~~torspec...~~ prop285:
https://gitweb.torproject.org/torspec.git/tree/proposals/285-utf-8.txt
~~I've heard others say that the following lines allow non-ASCII content, but I'm not sure if that's actually the case, and if it is, how many relays this would affect:~~
* ~~the "platform" line in relay descriptors, which is a "human-readable string",~~
* ~~the contact "info" line in relay descriptors, which has an undefined format.~~
Edit: allowing users to spell their names correctly is important. That's why we'll use utf-8 for relay descriptors, votes, and consensuses.
~~If it is, I'd recommend we make them all ASCII for consistency, and update torspec to clarify, and include it as a "major" change in an 0.2.x tor release.~~
~~(This means that some users will be unable to spell their names correctly. But there was never any guarantee that 8-bit characters in "info" would be interpreted as users intended. I think security is more important here.)~~Tor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/18918Clarify directory and ORPort checking functions2021-09-16T14:34:12ZteorClarify directory and ORPort checking functionsThe OR and dir checking functions in router.c are somewhat confusing. We could document them better, or modify their names, or restructure.
In legacy/trac#18616, we added:
* decide_to_advertise_begindir
We already had:
* check_whether_...The OR and dir checking functions in router.c are somewhat confusing. We could document them better, or modify their names, or restructure.
In legacy/trac#18616, we added:
* decide_to_advertise_begindir
We already had:
* check_whether_orport_reachable
* check_whether_dirport_reachable
* router_has_bandwidth_to_be_dirserver
* router_should_be_directory_server
* dir_server_mode
* decide_to_advertise_dirport
* consider_testing_reachabilityTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18902Avoid variable shadowing in Tor2021-09-16T14:34:12ZteorAvoid variable shadowing in TorTor sure does shadow a lot of local and global variables with its block-level variable declarations.
I spot-checked a few of these and they look harmless.
Still, it would be great if we removed them by renaming the variables in the inn...Tor sure does shadow a lot of local and global variables with its block-level variable declarations.
I spot-checked a few of these and they look harmless.
Still, it would be great if we removed them by renaming the variables in the innermost scope. This would avoid confusion, and remove the possibility of bugs where the declaration is removed, and the identifier references the outer scope.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18892Add IP versions to man page2021-07-22T16:23:44ZteorAdd IP versions to man pageReview the tor manual page for uses of "IP address", and clarify whether it's IPv4 or IPv6 or both.Review the tor manual page for uses of "IP address", and clarify whether it's IPv4 or IPv6 or both.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18891Make it clear that Address only works for IPv42021-07-22T16:23:44ZteorMake it clear that Address only works for IPv4Some operators expect Address to work with an IPv6 address, either a literal, or a DNS name with an AAAA record.
We should make this clearer in the manual.Some operators expect Address to work with an IPv6 address, either a literal, or a DNS name with an AAAA record.
We should make this clearer in the manual.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18823Sanity check on the fallback dir torrc values2020-07-27T19:12:18ZDavid Gouletdgoulet@torproject.orgSanity check on the fallback dir torrc valuesThis is part of legacy/trac#18481. torrc options were added to control the fallback directories schedule and behavior. We need to sanity check those once set.This is part of legacy/trac#18481. torrc options were added to control the fallback directories schedule and behavior. We need to sanity check those once set.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18812[warn] Tried connecting to router at 81.7.17.171:443, but identity key was no...2020-06-27T13:59:14ZRoger Dingledine[warn] Tried connecting to router at 81.7.17.171:443, but identity key was not as expected: wanted 00C4B4731658D3B4987132A3F77100CFCB190D97 but got CFECDDCA990E3EF7B7EC958B22441386B6B8D820.I'm running git master, but I think this applies to Tor 0.2.8.2-alpha. On bootstrap, I got
```
[...]
Apr 13 03:17:50.542 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
...I'm running git master, but I think this applies to Tor 0.2.8.2-alpha. On bootstrap, I got
```
[...]
Apr 13 03:17:50.542 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Apr 13 03:17:50.620 [warn] Tried connecting to router at 81.7.17.171:443, but identity key was not as expected: wanted 00C4B4731658D3B4987132A3F77100CFCB190D97 but got CFECDDCA990E3EF7B7EC958B22441386B6B8D820.
Apr 13 03:17:52.147 [notice] Bootstrapped 40%: Loading authority key certs
[...]
```
So I think everything is going according to plan (cool, I even used a fallback dir!), except my fallback dir seems to have changed its key since it went into fallback_dirs.inc.
Maybe it isn't so reliably stable after all? :) :/
I wonder if we should consider a) doing periodic full checks of the fallback relays, to catch issues like this one preemptively, and then b) making the warning less scary for normal users.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18757Memunit config defaults say "KB" rather than "KBytes"2022-06-17T18:36:26ZRoger DingledineMemunit config defaults say "KB" rather than "KBytes"E.g.
```
V(AuthDirFastGuarantee, MEMUNIT, "100 KB"),
V(AuthDirGuardBWGuarantee, MEMUNIT, "2 MB"),
```
and others. These should say "100 KBytes", "2 MBytes", etc, in the same way that we've updated the documentation and s...E.g.
```
V(AuthDirFastGuarantee, MEMUNIT, "100 KB"),
V(AuthDirGuardBWGuarantee, MEMUNIT, "2 MB"),
```
and others. These should say "100 KBytes", "2 MBytes", etc, in the same way that we've updated the documentation and sample configs and so on.https://gitlab.torproject.org/tpo/core/tor/-/issues/18736[Manual] Add some information about sub-domain rules2021-07-22T16:23:44Zcypherpunks[Manual] Add some information about sub-domain ruleshttps://www.torproject.org/docs/tor-manual.html.en
> HIDDEN SERVICE OPTIONS
> The following options are used to configure a hidden service.
We need official statement about second-level domain(subdomain) of .onion.
Likely,
> this one(1...https://www.torproject.org/docs/tor-manual.html.en
> HIDDEN SERVICE OPTIONS
> The following options are used to configure a hidden service.
We need official statement about second-level domain(subdomain) of .onion.
Likely,
> this one(1) and,
> git.xxxxxxxxx.onion
are using second level domain.
I know only two URLs.
1: https://tor.stackexchange.com/questions/10068/sub-domain-of-onion-is-allowed-officialyTor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18721Define accessors for connection_t's address fields2021-09-16T14:34:12ZteorDefine accessors for connection_t's address fieldsIn legacy/trac#18460, we noted that connection_t's address fields are confusing.
we should open a ticket to add comments explaining the real story of what's going on above in the code, and that we also open a ticket to define a few ac...In legacy/trac#18460, we noted that connection_t's address fields are confusing.
we should open a ticket to add comments explaining the real story of what's going on above in the code, and that we also open a ticket to define a few accessor functions to provide tor_addr_t and string representations of the final target address, proxy-or-final, or whatever other things we actually need.Tor: unspecified