Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:51:31Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33358Update dir-spec for consensus voting improvements2020-06-13T15:51:31ZteorUpdate dir-spec for consensus voting improvementsIn #4631, we change how authorities handle late posted votes. We need to update the dir-spec for this change.In #4631, we change how authorities handle late posted votes. We need to update the dir-spec for this change.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33286update recommended relay protocols & recommended client protocols2020-06-13T15:51:21Zcypherpunksupdate recommended relay protocols & recommended client protocols0.2.9 clients and relays don't print any warning that they're obsolete.
Since 0.2.9 is EOL, the following protocols are in all supported versions of Tor, but aren't currently recommended:
* Desc=2, Microdesc=2, and Cons=2 are supported...0.2.9 clients and relays don't print any warning that they're obsolete.
Since 0.2.9 is EOL, the following protocols are in all supported versions of Tor, but aren't currently recommended:
* Desc=2, Microdesc=2, and Cons=2 are supported [since 0.2.7.x](https://gitweb.torproject.org/tor.git/tree/src/or/protover.c?h=maint-0.2.9#n761)
* HSRend=2 is supported [since 0.2.9.1-alpha](https://github.com/torproject/tor/commit/4cbfee14d40221a25545d2d2c3d6e6ce76f6afe9)
* LinkAuth=3 is supported [since 0.3.0.1-alpha](https://github.com/torproject/tor/commit/b7a1e793e69e540e0377fa4418810ff1c02d50f9) (LinkAuth=1 was removed in #27286)
* HSDir=2 and HSIntro=4 are supported [since 0.3.0.4-rc](https://github.com/torproject/tor/commit/3f005c0433c56a540c211c9b6be1cf45a8185bc7)
* DirCache=2 is supported since [0.3.1.1-alpha](https://github.com/torproject/tor/commit/f9d8ade91242a702589e4e2ff2a280836fabb4da)
* Link=5 is supported [since 0.3.1.1-alpha / 0.3.1.10](https://github.com/torproject/tor/commit/a8e5e3a492378f6a9a2b4d55a4e7e5bab3f9dca4)https://gitlab.torproject.org/legacy/trac/-/issues/33239Prop 312: 3.2.3 Limit Directory Authority Addresses to Address and ORPort2020-06-13T15:51:06ZteorProp 312: 3.2.3 Limit Directory Authority Addresses to Address and ORPortFor security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Since local interface addresses are
implicit, and may depend on DHCP, directory authorities do not use this
address resolution ...For security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Since local interface addresses are
implicit, and may depend on DHCP, directory authorities do not use this
address resolution method (or any of the other, lower-priority address
resolution methods).
See proposal 312, section 3.2.3, directory authority case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n388https://gitlab.torproject.org/legacy/trac/-/issues/33237Prop 312: 3.2.2. Stop Directory Authorities Resolving *Port Hostnames2020-06-13T15:51:04ZteorProp 312: 3.2.2. Stop Directory Authorities Resolving *Port HostnamesFor security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory
authorities only accept IPv4 or IPv6 address literals in the address part
of the ORPort an...For security reasons, directory authorities only use addresses that are
explicitly configured in their torrc. Therefore, we propose that directory
authorities only accept IPv4 or IPv6 address literals in the address part
of the ORPort and DirPort options.
As part of this fix, we may also ban DNS resolution on all configured Ports. (We should try to avoid banning DNS resolution entirely on authorities, because some test networks use Authority/Exits.)
See proposal 312, section 3.2.2, directory authority case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n340
Directory authorities must not attempt to resolve these
addresses using DNS. It is a config error to provide a hostname as a
directory authority's ORPort or DirPort.
If directory authorities don't have an IPv4 address literal in their
Address or ORPort, they should issue a configuration error, and refuse to
launch. If directory authorities don't have an IPv6 address literal in their
Address or ORPort, they should issue a notice-level log, and fall back to
only using IPv4.Tor: 0.4.5.x-finalhttps://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/33029dir-auth: Dir auths should resume sending 503's but never to relays or other ...2020-11-13T13:39:33ZDavid Gouletdgoulet@torproject.orgdir-auth: Dir auths should resume sending 503's but never to relays or other dir authsThis is a child ticket from #33018.
The idea here is that even if we hit the global write limit (bw), we should not return 503 code but rather answer another directory authority.
Dirauth _must_ be able to talk to each other at all time...This is a child ticket from #33018.
The idea here is that even if we hit the global write limit (bw), we should not return 503 code but rather answer another directory authority.
Dirauth _must_ be able to talk to each other at all time regardless of the bandwidth state.
Setting 043 milestone because this should be considered a bug and could even be considered for backport since dirauth are suffering from this at the moment.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31964Dir auths could withhold HSIntro 4 in their votes if the relay would be a bug...2020-06-13T15:46:21ZRoger DingledineDir auths could withhold HSIntro 4 in their votes if the relay would be a buggy v3 intro pointIn #27841 we learned that some old relays have a buggy implementation when they're used as a new-style intro point, which is causing misery -- both inconsistent reachability for v3 onion services and extra load on the network.
In
https...In #27841 we learned that some old relays have a buggy implementation when they're used as a new-style intro point, which is causing misery -- both inconsistent reachability for v3 onion services and extra load on the network.
In
https://trac.torproject.org/projects/tor/ticket/27841#comment:33 we thought that withholding the HSIntro 4 vote for buggy relays would require a new consensus method, but I don't think that is so: in networkstatus_compute_consensus() when we're crafting the consensus out of the votes, we do
```
smartlist_sort_strings(protocols);
chosen_protocol_list = get_most_frequent_member(protocols);
```
So all we need to do is change authorities to vote different protovers for those relays in their votes, and once a majority of them are voting the new protovers, that's it.
Mind you, the implementation looks a bit tricky at first, because right now the vote is simply created by passing through the protovers volunteered in the relay descriptor: see routerstatus_format_entry()'s
```
if (protocols) {
smartlist_add_asprintf(chunks, "pr %s\n", protocols);
}
```
but we could avoid all the parsing mess by some simpler logic like "if it's a bad version, and it's claiming the expected full protover string x, use the full string y instead".
I'm waiting to hear from dgoulet what versions remain buggy with the HSIntro protocol 4. It might be that we have nothing to fix here, once we've bumped out all the obsolete relays from the network, and instead we should just keep in mind for the future that this situation is what protovers were meant for.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31549Authorities should stop listing relays running pre-0.2.9, or running 0.3.0 th...2020-06-13T15:44:49ZNick MathewsonAuthorities should stop listing relays running pre-0.2.9, or running 0.3.0 through 0.3.4The release series 0.3.0 through 0.3.4 are no longer supported, and we have encountered at least one bug (#27841) caused by them lingering on the network.
We should have the authorities stop listing them in their votes. The patch here...The release series 0.3.0 through 0.3.4 are no longer supported, and we have encountered at least one bug (#27841) caused by them lingering on the network.
We should have the authorities stop listing them in their votes. The patch here is simple enough -- we just edit dirserv_get_status_impl to reject everything newer than "0.3.0.0" and less new than "0.3.5.x" (for some well chosen "x").
But before we do this, we should take necessary steps to contact operators and let them know that they really really need to upgrade.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31088Check IPv4 and IPv6 private addresses in descriptors2020-06-13T15:43:24ZteorCheck IPv4 and IPv6 private addresses in descriptorsTor should check for private relay IPv6 addresses:
When authorities check descriptors:
https://github.com/torproject/tor/blob/e9d99d2e15f09a394ad01189b7965af4888a61a6/src/feature/dirauth/process_descs.c#L429
Note: these changes require...Tor should check for private relay IPv6 addresses:
When authorities check descriptors:
https://github.com/torproject/tor/blob/e9d99d2e15f09a394ad01189b7965af4888a61a6/src/feature/dirauth/process_descs.c#L429
Note: these changes require IPv6 extends from #24403:
When relays extend:
https://github.com/torproject/tor/blob/f7e8b3b68c8e2cecfc7ff4072e9f00d316aaba4f/src/core/or/circuitbuild.c#L1253
And when clients connect:
https://github.com/torproject/tor/blob/f7e8b3b68c8e2cecfc7ff4072e9f00d316aaba4f/src/core/or/circuitbuild.c#L552Tor: 0.4.1.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31000Authorities should cap relay consensus weight as a new consensus method2020-06-13T15:43:03ZteorAuthorities should cap relay consensus weight as a new consensus methodarma says on IRC:
```
armadev: teor4: is there a ticket for capping the total weight a given relay can get? i remember you mentioning that this should happen as a new consensus method, i.e. so the authorities actually collectively cap it...arma says on IRC:
```
armadev: teor4: is there a ticket for capping the total weight a given relay can get? i remember you mentioning that this should happen as a new consensus method, i.e. so the authorities actually collectively cap it, rather than relying on each vote individually to do it. i think that's a compelling idea.
```
I'm not sure if the cap should be the same across the network, or if it should be different based on each relay's MaxAdvertisedBandwidth.
If we want to base it on MaxAdvertisedBandwidth, we should also make MaxAdvertisedBandwidth a separate number in relay descriptor bandwidth lines, rather than combining it with bandwidth rate and bandwidth burst.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30782Cache outdated fetched descriptors on directory authorities2020-06-13T15:42:14ZteorCache outdated fetched descriptors on directory authoritiesWhen tor starts fetching a descriptor due to a consensus, then replaces its consensus before the descriptor arrives, the descriptor is unrecognised.
Directory caches keep the descriptor in the old descriptor cache, but clients and autho...When tor starts fetching a descriptor due to a consensus, then replaces its consensus before the descriptor arrives, the descriptor is unrecognised.
Directory caches keep the descriptor in the old descriptor cache, but clients and authorities drop it.
But I think authorities should keep the descriptor, in case it is used in a future vote or consensus.
This is a bug on tor 0.1.1.13-alpha.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30638Test banning ed25519 keys in the approved-routers file on moria12020-06-13T15:41:47ZteorTest banning ed25519 keys in the approved-routers file on moria1After #22029 merges to master, we should test that we can ban ed25519 keys on the public tor network.
We should email arma after the merge, and close this ticket once he confirms that the feature works.After #22029 merges to master, we should test that we can ban ed25519 keys on the public tor network.
We should email arma after the merge, and close this ticket once he confirms that the feature works.Tor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/30522Update to May GeoIP2 database2020-06-13T15:41:33ZKarsten LoesingUpdate to May GeoIP2 database[My geoip-2019-05-13 branch](https://gitweb.torproject.org/user/karsten/tor.git/log/?h=geoip-2019-05-13) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other b...[My geoip-2019-05-13 branch](https://gitweb.torproject.org/user/karsten/tor.git/log/?h=geoip-2019-05-13) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branches that are still maintained.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30219Add Tom's bandwidth file archive to CollecTor2020-06-13T17:52:15ZirlAdd Tom's bandwidth file archive to CollecTorWe should think about how best to do this, but once we've transitioned to fetching bandwidth files from the dir auths we can probably do a simple backfill of Tom's data.We should think about how best to do this, but once we've transitioned to fetching bandwidth files from the dir auths we can probably do a simple backfill of Tom's data.https://gitlab.torproject.org/legacy/trac/-/issues/30218Add bandwidth files archiving to CollecTor2020-06-13T17:52:14ZirlAdd bandwidth files archiving to CollecTorThese are referenced by votes, and available via the directory protocol. Unfortunately there is no "current" URL yet, only "next", so we might have to be proactive in downloading these independently of the relaydescs module.These are referenced by votes, and available via the directory protocol. Unfortunately there is no "current" URL yet, only "next", so we might have to be proactive in downloading these independently of the relaydescs module.https://gitlab.torproject.org/legacy/trac/-/issues/30217Extend CollecTor filesystem protocol for bandwidth files2020-06-13T17:52:13ZirlExtend CollecTor filesystem protocol for bandwidth filesWe should be careful which timestamps we are using, and how we are identifying the bandwidth scanners.We should be careful which timestamps we are using, and how we are identifying the bandwidth scanners.irlirlhttps://gitlab.torproject.org/legacy/trac/-/issues/30216Add bandwidth file parser to metrics-lib2020-06-13T17:58:15ZirlAdd bandwidth file parser to metrics-libIdeally we can parse both 1.0.0 and 1.4.0 files, but I'm not sure that we have any of the versions in between that would ever end up in our archive.
The specification is at:
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file...Ideally we can parse both 1.0.0 and 1.4.0 files, but I'm not sure that we have any of the versions in between that would ever end up in our archive.
The specification is at:
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txtKarsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/29897Refactor handle_get_next_bandwidth() to use connection_dir_buf_add()2020-06-13T15:39:50ZteorRefactor handle_get_next_bandwidth() to use connection_dir_buf_add()After #21377 merges, we want to refactor handle_get_next_bandwidth() to use connection_dir_buf_add().
If we backport this refactor to 0.4.0 or earlier, we'll also need #29896 for the connection_dir_buf_add() backport.After #21377 merges, we want to refactor handle_get_next_bandwidth() to use connection_dir_buf_add().
If we backport this refactor to 0.4.0 or earlier, we'll also need #29896 for the connection_dir_buf_add() backport.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29896Backport connection_dir_buf_add() to 0.3.4 and later2020-06-13T15:39:49ZteorBackport connection_dir_buf_add() to 0.3.4 and laterWe need connection_dir_buf_add() in 0.3.4 for #21377.
But I don't want to backport all the refactoring, just the new function.We need connection_dir_buf_add() in 0.3.4 for #21377.
But I don't want to backport all the refactoring, just the new function.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29147Update dir-spec with the correct Tor version when bandwidth-file-digest is me...2020-06-13T15:37:07ZteorUpdate dir-spec with the correct Tor version when bandwidth-file-digest is mergedIt currently says 0.4.0.1-alpha, but this feature didn't make it:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2162It currently says 0.4.0.1-alpha, but this feature didn't make it:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2162Tor: 0.4.0.x-final