The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-22T16:23:44Zhttps://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: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18689Fallback Directory Selection should exclude down relays earlier2020-06-27T13:59:19ZteorFallback Directory Selection should exclude down relays earlierThe updateFallbackDirs.py script uses OnionOO to find a list of candidate directory mirrors, then checks the consensus download speed from each mirror.
Previously, the script allowed relays that had a good uptime history, but just happe...The updateFallbackDirs.py script uses OnionOO to find a list of candidate directory mirrors, then checks the consensus download speed from each mirror.
Previously, the script allowed relays that had a good uptime history, but just happened to be down right now.
But this doesn't work any more, because those relays can't provide a consensus, so we exclude them in the final consensus download check.
We could be smarter, and avoid the effort of that check by eliminating relays that aren't running right now from the list of fallback candidates.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18582tor_addr_is_internal should never block PT dummy addresses2020-06-27T13:59:26Zteortor_addr_is_internal should never block PT dummy addressesIn legacy/trac#17674 and legacy/trac#8976, we block internal addresses when opening a connection.
In legacy/trac#18517, we chose 192.0.2.0/24 as a dummy address range for Tor Browser to use for pluggable transports to use when they don'...In legacy/trac#17674 and legacy/trac#8976, we block internal addresses when opening a connection.
In legacy/trac#18517, we chose 192.0.2.0/24 as a dummy address range for Tor Browser to use for pluggable transports to use when they don't have the actual remote address.
Let's add a comment near the IPv4 range in tor_addr_is_internal_ to never block those addresses (or, if we do, to change how Tor Browser and PTs work first).Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18529Fix duplicate check for "only allow internal addresses if we are on a network...2021-09-16T14:34:12ZNick MathewsonFix duplicate check for "only allow internal addresses if we are on a network with nonstandard authorities"We have this code in config.c:
```
if (tor_addr_is_internal(&myaddr, 0)) {
/* make sure we're ok with publishing an internal IP */
if (!options->DirAuthorities && !options->AlternateDirAuthority) {
/* if they are using th...We have this code in config.c:
```
if (tor_addr_is_internal(&myaddr, 0)) {
/* make sure we're ok with publishing an internal IP */
if (!options->DirAuthorities && !options->AlternateDirAuthority) {
/* if they are using the default authorities, disallow internal IPs
* always. */
log_fn(warn_severity, LD_CONFIG,
"Address '%s' resolves to private IP address '%s'. "
"Tor servers that use the default DirAuthorities must have "
"public IP addresses.", hostname, addr_string);
tor_free(addr_string);
return -1;
}
...
```
And we now have this code in router.c (since legacy/trac#17153):
```
/* Like IPv4, if the relay is configured using the default
* authorities, disallow internal IPs. Otherwise, allow them. */
const int default_auth = (!options->DirAuthorities &&
!options->AlternateDirAuthority);
if (! tor_addr_is_internal(&p->addr, 0) || ! default_auth) {
ipv6_orport = p;
break;
...
```
These two checks are similar and I'd prefer that they be merged when possible.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18491Stop logging identifying bridge info at 'notice'2020-06-27T13:59:28ZLinus Nordberglinus@torproject.orgStop logging identifying bridge info at 'notice'A client running with bridges logs "new bridge descriptor '$NICKNAME'" and the bridge IP address at level 'notice'.
If the bridge has both an IPv4 and an IPv6 ORPort, there's an additional log line, this too at the 'notice' level.
The...A client running with bridges logs "new bridge descriptor '$NICKNAME'" and the bridge IP address at level 'notice'.
If the bridge has both an IPv4 and an IPv6 ORPort, there's an additional log line, this too at the 'notice' level.
There might be more.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18462Rename tor_dup_addr to make it clear that it returns a string2020-06-27T13:59:29ZteorRename tor_dup_addr to make it clear that it returns a stringWe discovered in legacy/trac#18454 that it's easy to write code that assumes that tor_dup_addr duplicates an address, rather than formatting that address as a string and duplicating that string.
Let's change the name of that function to...We discovered in legacy/trac#18454 that it's easy to write code that assumes that tor_dup_addr duplicates an address, rather than formatting that address as a string and duplicating that string.
Let's change the name of that function to tor_addr_to_str_dup or something.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18398Check fallback directory performance before including them in the list2020-06-27T13:59:31ZteorCheck fallback directory performance before including them in the listOne fallback directory is quite slow to provide consensuses (~30s).
atagar suggested in legacy/trac#18177 that we check fallbacks' speeds before we add them to the list (and provided code!)
We need to add this to the updateFallbackDirs....One fallback directory is quite slow to provide consensuses (~30s).
atagar suggested in legacy/trac#18177 that we check fallbacks' speeds before we add them to the list (and provided code!)
We need to add this to the updateFallbackDirs.py script before we generate the next fallback list.
(One drawback of checking times is that we'll get slightly different results from different connections. This shouldn't be an issue if we download one at a time, and re-time failed connections.)Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18394Allow relays to have an IPv6 DirPort on the same port as the IPv4 DirPort2020-06-27T13:59:31ZteorAllow relays to have an IPv6 DirPort on the same port as the IPv4 DirPortCurrently, to do this, relay operators need to say `DirPort [IPv6-address]:80 NoAdvertise`, or they get a warning "Can't advertise more than one DirPort."
This supports clients on IPv6 in 0.2.8.Currently, to do this, relay operators need to say `DirPort [IPv6-address]:80 NoAdvertise`, or they get a warning "Can't advertise more than one DirPort."
This supports clients on IPv6 in 0.2.8.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18377connection_free_ of NULL dir_connection_t in test_dir_handle_get_status_vote_...2020-06-27T13:59:32Zteorconnection_free_ of NULL dir_connection_t in test_dir_handle_get_status_vote_next_consensus_signatures_not_foundThis normally wouldn't matter, but we call TO_CONN on it first, which dereferences a NULL pointer.This normally wouldn't matter, but we call TO_CONN on it first, which dereferences a NULL pointer.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18345Fix all doxygen "X is not documented" warnings2021-07-22T16:23:43ZteorFix all doxygen "X is not documented" warningsQuoting arma:
It occurred to me while looking at the doxygen comment for
router_is_already_dir_fetching_ds() that if we had something go through
and complain about all cases where there's a function argument that is
not mentione...Quoting arma:
It occurred to me while looking at the doxygen comment for
router_is_already_dir_fetching_ds() that if we had something go through
and complain about all cases where there's a function argument that is
not mentioned by `<b>parameter</b>` (with the markup) in the doxygen
comment... we would end up with a lot of complaints.
We could fix this by placing `<b></b>` around documented parameters, and by documented undocumented parameters.
There might even be a way to semi-automatically do this using a script, and then clean up any mismatches.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18312MapAddress should recommend fingerprints, not nicknames2021-07-22T16:23:43ZteorMapAddress should recommend fingerprints, not nicknamesSince we stopped voting on nicknames, they've become even less reliable as a way to identify a relay.
MapAddress (and similar man page entries) should be updated to recommend the use of fingerprints, not nicknames.Since we stopped voting on nicknames, they've become even less reliable as a way to identify a relay.
MapAddress (and similar man page entries) should be updated to recommend the use of fingerprints, not nicknames.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18300Tor shall explicitly report of Nickname is wrong length or contain illegal ch...2020-06-27T13:59:37ZnaifTor shall explicitly report of Nickname is wrong length or contain illegal characterI was trying to configure a Tor Relay nickname with 30 characters and i got:
Feb 11 08:40:04.779 [warn] Failed to parse/validate config: Nickname 'AViaNanoServerforTest' is wrong length or contains illegal characters.
I didn't know tha...I was trying to configure a Tor Relay nickname with 30 characters and i got:
Feb 11 08:40:04.779 [warn] Failed to parse/validate config: Nickname 'AViaNanoServerforTest' is wrong length or contains illegal characters.
I didn't know that there where a specific length limit on the nickname and had to find out with a trial and error.
This ticket is to:
- Explicitly report that there's a length problem in the nickname and which is the maximum length
- Add a comment in Torrc nearby Nickname section saying how longer it could behttps://gitlab.torproject.org/tpo/core/tor/-/issues/18298reduce warn loglevel entry for missing ed25519_master_id_public_key to notice...2022-06-17T17:42:02Zcypherpunksreduce warn loglevel entry for missing ed25519_master_id_public_key to notice loglevelWhen ed25519_master_id_public_key is not present on the system, tor issues the following log entry:
```
[warn] No key found in .../keys/ed25519_master_id_secret_key or
.../keys/ed25519_master_id_public_key.
[warn] Master public key was ...When ed25519_master_id_public_key is not present on the system, tor issues the following log entry:
```
[warn] No key found in .../keys/ed25519_master_id_secret_key or
.../keys/ed25519_master_id_public_key.
[warn] Master public key was absent; inferring from public key in
signing certificate and saving to disk.
```
Is that such bad after all?
https://lists.torproject.org/pipermail/tor-dev/2015-November/009961.htmlhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18263GETCONF provides incorrect value when undefined2021-07-09T17:22:00ZDamian JohnsonGETCONF provides incorrect value when undefinedThis is kinda subtle but CommaList and RouterList values mistakenly include a '=' when undefined...
```
GETCONF ExcludeNodes
250 ExcludeNodes=
```
By contrast here's what Bridge, a LineList value, provides...
```
GETCONF Bridge
250 Br...This is kinda subtle but CommaList and RouterList values mistakenly include a '=' when undefined...
```
GETCONF ExcludeNodes
250 ExcludeNodes=
```
By contrast here's what Bridge, a LineList value, provides...
```
GETCONF Bridge
250 Bridge
```https://gitlab.torproject.org/tpo/core/tor/-/issues/18248tor logging twice when --+Log argument and config are used2020-06-27T13:59:39ZTractor logging twice when --+Log argument and config are usedWhen specifying the Log option to the same place twice various messages will be logged twice.
Specifying
```
# On the command line:
--+Log notice file /var/log/tor
# In torrc:
Log notice file /var/log/tor
```
will result in messages...When specifying the Log option to the same place twice various messages will be logged twice.
Specifying
```
# On the command line:
--+Log notice file /var/log/tor
# In torrc:
Log notice file /var/log/tor
```
will result in messages like those:
```
Feb 05 11:05:41.000 [notice] Bootstrapped 0%: Starting
Feb 05 11:05:41.000 [notice] Bootstrapped 0%: Starting
Feb 05 11:05:54.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Feb 05 11:05:54.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Feb 05 11:05:54.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Feb 05 11:05:54.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Feb 05 11:05:54.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent.
Feb 05 11:05:54.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent.
```
In a way one could say that's expected, but I think equivalent options should maybe be deduplicated.
This occurs on: Tor v0.2.8.1-alpha (git-9093e3769746742f) running on FreeBSD with Libevent 2.0.22-stable, OpenSSL 1.0.2f and Zlib 1.2.8.
**Trac**:
**Username**: reezerTor: 0.2.9.x-final