The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-11-09T21:13:39Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23119Make Tors no longer warn if they're running a newer-than-recommended version?2023-11-09T21:13:39ZRoger DingledineMake Tors no longer warn if they're running a newer-than-recommended version?Right now, we need to get three dir auths to add lines to their torrc files before we can put out a new release. Sometimes, we screw that up (legacy/trac#23118). The rest of the time, it's still a hassle.
One option is just to drop the ...Right now, we need to get three dir auths to add lines to their torrc files before we can put out a new release. Sometimes, we screw that up (legacy/trac#23118). The rest of the time, it's still a hassle.
One option is just to drop the recommendedversions thing entirely. I heard Sebastian and weasel discussing doing that.
An intermediate option would be to have Tors stop warning when they're running a newer version in a series. That is, we mostly focus on having the recommendedversions thing warn you when you're too old, and we stop minding when we're too new.
That way the dir auths only need to mess with their recommendedversions config when they're *un*recommending a version, which is an active decision that it's reasonable for directory authority operators to take. They never need to mess with them when some newer thing comes out (which should not need to involve a dir auth operator).Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23118release checklist should include "make sure the new version got recommended"2020-06-27T13:55:57ZRoger Dingledinerelease checklist should include "make sure the new version got recommended"In doc/HACKING/ReleasingTor.md we have
```
1. Get at least three of weasel/arma/Sebastian/Sina to put the new
version number in their approved versions list.
```
But there's no follow-up step later in the checklist, to make sure that...In doc/HACKING/ReleasingTor.md we have
```
1. Get at least three of weasel/arma/Sebastian/Sina to put the new
version number in their approved versions list.
```
But there's no follow-up step later in the checklist, to make sure that it really happened.
For Tor 0.3.0.10, it didn't happen -- moria1 recommended the new version, but nobody else did. So in retrospect, it would have been wise to do some sort of follow-up to check that the new version actually got recommended, before releasing.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23116tor stops responding to Ctrl-C and circuits while in infinite descriptor down...2020-07-28T03:59:00Zteortor stops responding to Ctrl-C and circuits while in infinite descriptor download loopI'm running tor master (ce07b4dd9) and 0.3.0.9 on macOS 10.12.5 x86_64 on a relay with a private IP address over a slow link.
It seems to get in an infinite loop with these kinds of messages, and stops responding on the ORPort and to Ct...I'm running tor master (ce07b4dd9) and 0.3.0.9 on macOS 10.12.5 x86_64 on a relay with a private IP address over a slow link.
It seems to get in an infinite loop with these kinds of messages, and stops responding on the ORPort and to Ctrl-C (shutdown):
```
Aug 05 09:04:10.000 [info] handle_response_fetch_microdesc: Received answer to microdescriptor request (status 200, body size 40905) from server '149.172.149.170:9030'
Aug 05 09:04:10.000 [info] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for some of our primary entry guards
Aug 05 09:04:10.000 [info] update_consensus_router_descriptor_downloads: 0 router descriptors downloadable. 0 delayed; 0 present (0 of those were in old_routers); 0 would_reject; 0 wouldnt_use; 6960 in progress.
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23114Circuit Build Timeout should apply at circuit completion2020-06-27T13:55:57ZMike PerryCircuit Build Timeout should apply at circuit completionBack when the CBT code was first written, circuit build times were around 10 seconds. This meant it was fine to check if the timeout had passed in circuit_expire_building(), which was called once per second.
However, now that the typica...Back when the CBT code was first written, circuit build times were around 10 seconds. This meant it was fine to check if the timeout had passed in circuit_expire_building(), which was called once per second.
However, now that the typical timeout is more like 2 seconds or less, we actually let a significantly larger fraction of circuits through by waiting for this once-per-second callback.
The fix is to switch the purpose of circuits as they are being built and/or opened to MEASUREMENT circuits as soon as they pass the timeout, but before use. This will cause us to actually discard the proper fraction of slow paths.Tor: 0.3.3.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23113Manage DNS state better when "All nameservers have failed"2022-09-01T21:31:33ZteorManage DNS state better when "All nameservers have failed"We should downgrade this warning when it only happens for a short period of time (or a small number of requests), or when it happens in response to a malformed request.
This warning is causing operators to make sub-optimal DNS server ch...We should downgrade this warning when it only happens for a short period of time (or a small number of requests), or when it happens in response to a malformed request.
This warning is causing operators to make sub-optimal DNS server choices: for example, avoiding using a local cache in favour of remote resolvers.
Sometimes changing the local resolver makes a difference:
https://trac.torproject.org/projects/tor/ticket/1936#comment:12
Sometimes it happens in response to malformed requests:
https://trac.torproject.org/projects/tor/ticket/11600#comment:6
Sometimes it's harmless:
https://trac.torproject.org/projects/tor/ticket/11600#comment:7
Because it's followed by:
```
[notice] eventdns: Nameserver <ISP-resolver2>:53 is back up
```https://gitlab.torproject.org/tpo/core/tor/-/issues/23110prop224: Rate limit HS descriptor reuploads2020-06-27T13:55:58ZGeorge Kadianakisprop224: Rate limit HS descriptor reuploadsprop224 services currently re-upload their HS descriptor everytime they receive new dir info (descriptors) if they are close to 100% visibility of the network.
This is done to make sure we always publish to the right HSDir nodes, but it...prop224 services currently re-upload their HS descriptor everytime they receive new dir info (descriptors) if they are close to 100% visibility of the network.
This is done to make sure we always publish to the right HSDir nodes, but it could also lead to uploading lots of descriptors in a small time frame.
A good fix for this would be to cache the previous set of responsible HSDirs (maybe on the desc), and avoid reuploading the same descriptor if the set of HSDirs is the same even if we received new dirinfo.
Also we should probably add a cache to avoid publishing the same descriptor multiple times in a small timeframe anyway.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23109prop224: Do we need to re-encode HS desc everytime we upload it?2020-06-27T13:55:58ZGeorge Kadianakisprop224: Do we need to re-encode HS desc everytime we upload it?Nick is worrying that we are spending cycles needlessly when we re-encode the descriptor in every `upload_descriptor_to_hsdir()`. Instead we could encode the desc once and use it for all uploads.Nick is worrying that we are spending cycles needlessly when we re-encode the descriptor in every `upload_descriptor_to_hsdir()`. Instead we could encode the desc once and use it for all uploads.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23108prop224: Don't rotate all service descriptors at once2020-08-03T12:28:24ZGeorge Kadianakisprop224: Don't rotate all service descriptors at onceIn `rotate_all_descriptors()` there is the following XXX that needs to be resolved:
```
/* XXX We rotate all our service descriptors at once. In the future it might
* be wise, to rotate service descriptors independently to hide ...In `rotate_all_descriptors()` there is the following XXX that needs to be resolved:
```
/* XXX We rotate all our service descriptors at once. In the future it might
* be wise, to rotate service descriptors independently to hide that all
* those descriptors are on the same tor instance */
```https://gitlab.torproject.org/tpo/core/tor/-/issues/23107prop224: Optimize hs_circ_service_get_intro_circ() digest calculation2020-06-27T13:55:58ZGeorge Kadianakisprop224: Optimize hs_circ_service_get_intro_circ() digest calculationOur prop224 function for getting an intro circ given its intro object re-calculates the relay identity fpr all the time:
```
if (ip->base.is_only_legacy) {
uint8_t digest[DIGEST_LEN];
if (BUG(crypto_pk_get_digest(ip->legacy_key...Our prop224 function for getting an intro circ given its intro object re-calculates the relay identity fpr all the time:
```
if (ip->base.is_only_legacy) {
uint8_t digest[DIGEST_LEN];
if (BUG(crypto_pk_get_digest(ip->legacy_key, (char *) digest) < 0)) {
goto end;
}
circ = hs_circuitmap_get_intro_circ_v2_service_side(digest);
```
We could shove that in the `hs_service_intro_point_t` object as well to cut some digest calculations.Tor: 0.3.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/23106Audit code for swapped ntoh*/hton* calls2020-06-27T13:55:58ZNick MathewsonAudit code for swapped ntoh*/hton* callsI grepped for this, and found one in ~~extended_cell_parse~~extend_cell_format(). (It's a ntohs that should be a htons.)
This is not a high-urgency item, since we don't support platforms where ntoh* and hton* behave differently.I grepped for this, and found one in ~~extended_cell_parse~~extend_cell_format(). (It's a ntohs that should be a htons.)
This is not a high-urgency item, since we don't support platforms where ntoh* and hton* behave differently.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23105Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.2020-06-27T13:55:58ZcypherpunksBug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.Got the following warn msg while browsing,
```
[warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL. Dropping. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
```Got the following warn msg while browsing,
```
[warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL. Dropping. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
```Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23101Predict and build specific HS purpose circuits (rather than GENERAL)2020-06-27T13:55:58ZMike PerryPredict and build specific HS purpose circuits (rather than GENERAL)circuit_predict_and_launch_new() builds CIRCUIT_PURPOSE_C_GENERAL circuits, even for hidden service circuits. When we implement Proposa247/#9001, we will need to give all hidden service circuits their specific purposes right from build t...circuit_predict_and_launch_new() builds CIRCUIT_PURPOSE_C_GENERAL circuits, even for hidden service circuits. When we implement Proposa247/#9001, we will need to give all hidden service circuits their specific purposes right from build time, in order to ensure that they are build using Vanguards. We will also need to disable cannibalization for them, since cannibalized GENERAL circuits will not use our vanguards, either.
This means we need to change the prediction recording and circuit building to record, predict, and build each HS circuit type independently.Tor: 0.3.3.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23100Circuit Build Timeout needs to count hidden service circuits2020-06-27T13:55:59ZMike PerryCircuit Build Timeout needs to count hidden service circuitsThe Circuit Build Timeout code currently ignores all circuits with a desired_path_len other than 3. This causes it not to count hidden service circuits of longer path lengths.
When we change the path selection for Proposal247/#9001, we ...The Circuit Build Timeout code currently ignores all circuits with a desired_path_len other than 3. This causes it not to count hidden service circuits of longer path lengths.
When we change the path selection for Proposal247/#9001, we are going to want to count those circuits, because we want the circuit build timeout to prune 20% of Prop247 circuits, too. If we omit those circuits from the CBT calculation, we risk timing out either too few, too many, or even *all* of them.
The simplest way to fix this is to change circuit_timeout_want_to_count_circ() to decide to count every circuit once it has completed 3 hops, even if it plans to build more.
We may also want to alter the timeout application in circuit_expire_building(), depending on the prop247 implementation we choose. In some versions of the proposal, we can end up creating what are technically 5 hop paths (though these topologies were not very popular in Wilmington).Tor: 0.3.3.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23098FTBFS again on Hurd2020-06-27T13:55:59ZcypherpunksFTBFS again on HurdThis is another case of legacy/trac#5355 which was introduced by [ba3a5f82f11388237a3ba4995ddf0b6ffaaf492a](https://gitweb.torproject.org/tor.git/commit/?id=ba3a5f82f11388237a3ba4995ddf0b6ffaaf492a). Found this while looking at the Tor b...This is another case of legacy/trac#5355 which was introduced by [ba3a5f82f11388237a3ba4995ddf0b6ffaaf492a](https://gitweb.torproject.org/tor.git/commit/?id=ba3a5f82f11388237a3ba4995ddf0b6ffaaf492a). Found this while looking at the Tor builds on Debian (see https://buildd.debian.org/status/logs.php?pkg=tor&arch=hurd-i386).Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23097The circuit timeout prediction is not working properly2020-06-27T13:55:59ZDavid Gouletdgoulet@torproject.orgThe circuit timeout prediction is not working properlyDuring prop224 service testing (legacy/trac#20657), I've encountered a weird behavior. Tor will start closing circuits with `circuit_expire_old_circuits_clientside()` and then open new ones for internal use (prediction) but set their tim...During prop224 service testing (legacy/trac#20657), I've encountered a weird behavior. Tor will start closing circuits with `circuit_expire_old_circuits_clientside()` and then open new ones for internal use (prediction) but set their timeout to 1 sec which leads to closing the circuit 30 sec later (`NewCircuitPeriod` defaults to 30 sec).
Condensed log info:
```
Aug 03 19:59:30.000 [info] circuit_expire_old_circuits_clientside(): Closing circuit 320 that has been unused for 27997 msec.
Aug 03 19:59:30.000 [info] circuit_expire_old_circuits_clientside(): Closing circuit 318 that has been unused for 29997 msec.
Aug 03 19:59:30.000 [info] circuit_expire_old_circuits_clientside(): Closing circuit 319 that has been unused for 28979 msec.
Aug 03 19:59:30.000 [info] circuit_predict_and_launch_new(): Have 0 clean circs (0 internal), need another internal circ for my hidden service.
Aug 03 19:59:30.000 [info] origin_circuit_new(): Circuit 321 chose an idle timeout of 1 based on 0 seconds of predictive building remaining.
...
Aug 03 20:00:01.000 [info] circuit_expire_old_circuits_clientside(): Closing circuit 321 that has been unused for 30991 msec.
```
So notice the circuit 321 with a timeout of 1 sec and then being closed 30 sec later... Basically, it's looping like that non stop. What I think is happening is this:
`predicted_ports_prediction_time_remaining()` returns 0 so the following computation always results in 1 sec (in `origin_circuit_new()`):
```
int prediction_time_remaining =
predicted_ports_prediction_time_remaining(time(NULL));
circ->circuit_idle_timeout = prediction_time_remaining+1+
crypto_rand_int(1+prediction_time_remaining/20);
```
We call `rep_hist_note_used_internal()` in the hs subsystem when we launch intro point and rendezvous circuits. That function sets `last_prediction_add_time = now`. Which is what we want because then `predicted_ports_prediction_time_remaining()` computes a `idle_delta` that is below the `prediction_timeout` (set between 30 and 60 mins by default, see `channelpadding_get_circuits_available_timeout()`).
Which means that after let's say 61 min for a `prediction_timeout = 60min`, `idle_delta` becomes bigger than `prediction_timeout` and thus returning 0 everytime ultimately making every new circuit timeout to 1 sec. See why below:
```
int
predicted_ports_prediction_time_remaining(time_t now)
{
time_t idle_delta = now - last_prediction_add_time;
/* Protect against overflow of return value. This can happen if the clock
* jumps backwards in time. Update the last prediction time (aka last
* active time) to prevent it. This update is preferable to using monotonic
* time because it prevents clock jumps into the past from simply causing
* very long idle timeouts while the monotonic time stands still. */
if (last_prediction_add_time > now) {
last_prediction_add_time = now;
idle_delta = 0;
}
/* Protect against underflow of the return value. This can happen for very
* large periods of inactivity/system sleep. */
if (idle_delta > prediction_timeout)
return 0;
[RIGHT HERE, we return 0]
...
```
This is pretty bad because it means that every HS that sees no client for at least 30 to 60 min, will enter this loop of create/close circuits raising flags at the Guard but also putting pressure on the network.
Seems that this was introduced with the channel padding in tor-0.3.1.1-alpha.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23094prop224: Optimize hsdir_index calculation2020-06-27T13:55:59ZGeorge Kadianakisprop224: Optimize hsdir_index calculationLet's include `hsdir_index_t` in the node_t instead of a pointer that we allocate, since that structure is always present anyway.
See here for more details:
https://oniongit.eu/dgoulet/tor/merge_requests/6#note_412Let's include `hsdir_index_t` in the node_t instead of a pointer that we allocate, since that structure is always present anyway.
See here for more details:
https://oniongit.eu/dgoulet/tor/merge_requests/6#note_412Tor: 0.3.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/23093Update to August GeoIP2 database2020-06-27T13:55:59ZKarsten LoesingUpdate to August GeoIP2 database[geoip-aug2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-aug2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.[geoip-aug2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-aug2017) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23092Stop ignoring CircuitIdleTimeout when it's lower than IDLE_TIMEOUT_WHILE_LEAR...2020-06-27T13:55:59ZteorStop ignoring CircuitIdleTimeout when it's lower than IDLE_TIMEOUT_WHILE_LEARNINGWhen I set CircuitIdleTimeout in chutney, it doesn't always work, because IDLE_TIMEOUT_WHILE_LEARNING is used instead. We should document this.
Or maybe we should use min(CircuitIdleTimeout, IDLE_TIMEOUT_WHILE_LEARNING) when learning?When I set CircuitIdleTimeout in chutney, it doesn't always work, because IDLE_TIMEOUT_WHILE_LEARNING is used instead. We should document this.
Or maybe we should use min(CircuitIdleTimeout, IDLE_TIMEOUT_WHILE_LEARNING) when learning?Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23091Broken condition in check_expired_networkstatus_callback()2020-06-27T13:55:59ZDavid Gouletdgoulet@torproject.orgBroken condition in check_expired_networkstatus_callback()Turns out that this condition in `check_expired_networkstatus_callback()`:
```
if (ns && ns->valid_until < now+NS_EXPIRY_SLOP &&
router_have_minimum_dir_info()) {
router_dir_info_changed();
}
```
... is always true if we ...Turns out that this condition in `check_expired_networkstatus_callback()`:
```
if (ns && ns->valid_until < now+NS_EXPIRY_SLOP &&
router_have_minimum_dir_info()) {
router_dir_info_changed();
}
```
... is always true if we have all our needed directory info which means that `router_dir_info_changed()` is called every 2 minutes (the callback interval).
Nick suggested that it should be `now - NS_EXPIRY_SLOP` which goes like this:
If `valid_until` is 6am today, then `now - 24h` == 1pm yesterday, and `valid_until < (now - 24h)` is false. But at 6:01am tomorrow, `valid_until < now - 24h` becomes true.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23090Sandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.322020-06-27T13:55:59ZteorSandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.32A relay operator reports a sandbox failure on Tor 0.3.0.9 with the following log lines:
```
sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
sandbox_getaddrinfo(): (Sandbox) getaddrinfo failed.
sandbox_getaddrinfo(): (Sandbox) get...A relay operator reports a sandbox failure on Tor 0.3.0.9 with the following log lines:
```
sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
sandbox_getaddrinfo(): (Sandbox) getaddrinfo failed.
sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
install_syscall_filter(): Bug: (Sandbox) failed to load: -22 (Invalid argument)! (on Tor 0.3.0.9 )
tor_main(): Bug: Failed to create syscall sandbox filter (on Tor 0.3.0.9 )
main process exited, code=exited, status=1/FAILURE
```
See https://lists.torproject.org/pipermail/tor-relays/2017-August/012694.htmlTor: 0.3.2.x-final