The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:55:43Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23455hs: hs_circuitmap_get_rend_circ_client_side() doesn't consider REND_JOINED pu...2020-06-27T13:55:43ZDavid Gouletdgoulet@torproject.orghs: hs_circuitmap_get_rend_circ_client_side() doesn't consider REND_JOINED purposeIt is possible that we get a `RENDEZVOUS2` cell from the service _before_ we get the `INTRODUCE_ACK` from the intro point. Which means that the rend circuit at that point, when the ack is received, its purpose is set to `CIRCUIT_PURPOSE_...It is possible that we get a `RENDEZVOUS2` cell from the service _before_ we get the `INTRODUCE_ACK` from the intro point. Which means that the rend circuit at that point, when the ack is received, its purpose is set to `CIRCUIT_PURPOSE_C_REND_JOINED` which `hs_circuitmap_get_rend_circ_client_side()` doesn't consider.
Here is the dicy part. It actually turns out that the legacy system has also this bug but was using `log_info()` instead of warn so it probably went unnoticed.
In any cases, it doesn't matter much because once the ACK has been received, it would only warn and then exit the function correctly by closing the intro circuit and not doing more.
That being said, I think the fix here is to make `hs_circuitmap_get_rend_circ_client_side()` consider REND_JOINED circuit but we should simply ignore the returned rendezvous circuit if it has been joined and warn if not so we can catch an issue like that in the future.
As for legacy, I propose we do not do anything because it's actually doing the right thing in the end and the log info doesn't alarm any user.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/23448ECDH performance warning with LibreSSL2020-06-27T13:55:43ZTracECDH performance warning with LibreSSLTor 0.3.0.10 running with LibreSSL 2.5.5 (latest stable):
```
[notice] Tor 0.3.0.10 (git-c33db290a9d8d0f9) running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.5.5 and Zlib 1.2.11.
```
```
[notice] We were built to run on a ...Tor 0.3.0.10 running with LibreSSL 2.5.5 (latest stable):
```
[notice] Tor 0.3.0.10 (git-c33db290a9d8d0f9) running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.5.5 and Zlib 1.2.11.
```
```
[notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster.
```
LibreSSL doesn't have this configure option and I don't think that there are any problems with ECDH.
Maybe its time to remove the warning?
**Trac**:
**Username**: svengohttps://gitlab.torproject.org/tpo/core/tor/-/issues/23445dir-spec: "protocols" line has been remove (past not future)2020-06-27T13:55:43Zcypherpunksdir-spec: "protocols" line has been remove (past not future)
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n699
says:
```
[NOTE: No version of Tor uses this protocol list. It will be removed
in a future version of Tor.]
```
This happened in 0.2.9, so this sentenc...
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n699
says:
```
[NOTE: No version of Tor uses this protocol list. It will be removed
in a future version of Tor.]
```
This happened in 0.2.9, so this sentence can be updated.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23441make test: fgets_eagain FAILED2020-06-27T13:55:43ZTracmake test: fgets_eagain FAILEDI've compiled tor-0.3.0.10 in an alpine:3.6 docker container, the complete source is available from https://raw.githubusercontent.com/svengo/docker-tor/master/Dockerfile. Everything is fine but make test failed:
```
# make test
[...]
ut...I've compiled tor-0.3.0.10 in an alpine:3.6 docker container, the complete source is available from https://raw.githubusercontent.com/svengo/docker-tor/master/Dockerfile. Everything is fine but make test failed:
```
# make test
[...]
util/fgets_eagain:
FAIL src/test/test_util.c:3970: assert(retptr OP_EQ buf): 0 vs 0x7ffc7aa12174
[fgets_eagain FAILED]
[...]
1/868 TESTS FAILED. (30 skipped)
make: *** [Makefile:9727: test] Error 1
```
I don't know if that is the same bug as legacy/trac#20988 and legacy/trac#21416.
**Trac**:
**Username**: svengoTor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23440Enhancement: Replace CookieAuthFileGroupReadable option with flag for CookieA...2022-06-17T17:36:09ZTracEnhancement: Replace CookieAuthFileGroupReadable option with flag for CookieAuthFileMaking Tor's cookie auth file group-readable currently requires the use of two separate options:
```
# (1) Current (as of Tor 0.3.0.10) and unwieldy
CookieAuthFile /path/to/file
CookieAuthFileGroupReadable 1
```
I suggest to replace the ...Making Tor's cookie auth file group-readable currently requires the use of two separate options:
```
# (1) Current (as of Tor 0.3.0.10) and unwieldy
CookieAuthFile /path/to/file
CookieAuthFileGroupReadable 1
```
I suggest to replace the option CookieAuthFileGroupReadable with a flag GroupReadable for the CookieAuthFile option:
```
# (2) Feature request: GroupReadable flag, replaces (1)
CookieAuthFile /path/to/file GroupReadable
```
This enhancement would feel more "natural" and is consistent with a similar flag for the ControlPort option:
```
# (3) Current (as of Tor 0.3.0.10) and natural:
ControlPort unix:/path/to/socket GroupWritable
```
**Trac**:
**Username**: Ralphhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23438Use better status codes for HTTP CONNECT proxy errors2020-07-28T04:56:13ZNick MathewsonUse better status codes for HTTP CONNECT proxy errorsThe current list of status codes was gathered by combining the RFCs with guesswork; many things are 404/403/502. Perhaps there is a better list? (See end_reason_to_http_connect_response_line().)The current list of status codes was gathered by combining the RFCs with guesswork; many things are 404/403/502. Perhaps there is a better list? (See end_reason_to_http_connect_response_line().)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23433Windows relay: 85% of CPU power is wasted inside select() call2020-07-28T04:56:48ZTracWindows relay: 85% of CPU power is wasted inside select() callSince I have eliminated the network slowdown with patch from legacy/trac#22798, I have started to face another problem:
As connection count began to grow, CPU resources consumption start growing too.
Now, with 3700 connections and 1 MiB/...Since I have eliminated the network slowdown with patch from legacy/trac#22798, I have started to face another problem:
As connection count began to grow, CPU resources consumption start growing too.
Now, with 3700 connections and 1 MiB/s of Tor traffic, CPU is [tor_cpu.png|loaded at 15%](None/tor_cpu.png|loaded at 15%).
With 3 MiB/s of traffic, CPU load goes up to maximum 25% (full load of 1 CPU core).
It is possible to think that Tor uses much cryptography and that thing is overloading my PC. But no.
Much of the time (88 hours of total 102 hours) tor.exe process spends in kernel mode. Most probably, inside `WS2_32.dll!select` function (called from libevent library).
This specificity limits maximum speeds, which can be achieved using Tor relay with Windows.
And, most likely, it can be fixed by using the different approaches for network API interaction.
CPU: Intel Core i5-4690
OS: Windows 7 SP1 x64
**Trac**:
**Username**: VortTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23430Update to September GeoIP2 database2020-06-27T13:55:43ZKarsten LoesingUpdate to September GeoIP2 database[geoip-sep2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-sep2017) 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-sep2017](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-sep2017) 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/23429hs: assert on rend_data when pruning the v2 service list2020-06-27T13:55:44ZDavid Gouletdgoulet@torproject.orghs: assert on rend_data when pruning the v2 service listReported by ahf:
```
Sep 07 18:02:40.000 [err] tor_assertion_failed_(): Bug: src/or/rendservice.c:561: rend_service_prune_list_impl_: Assertion ocirc->rend_data failed; aborting. (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:...Reported by ahf:
```
Sep 07 18:02:40.000 [err] tor_assertion_failed_(): Bug: src/or/rendservice.c:561: rend_service_prune_list_impl_: Assertion ocirc->rend_data failed; aborting. (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: Assertion ocirc->rend_data failed in rend_service_prune_list_impl_ at src/or/rendservice.c:561. Stack trace: (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: ./bin/tor(log_backtrace+0x42) [0x7fa7d0ad0f52] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: ./bin/tor(tor_assertion_failed_+0x94) [0x7fa7d0aeb594] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: ./bin/tor(rend_service_prune_list+0x32f) [0x7fa7d09da46f] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: ./bin/tor(hs_config_service_all+0x87c) [0x7fa7d0ab583c] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: ./bin/tor(set_options+0x16ca) [0x7fa7d0a4b98a] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: ./bin/tor(options_init_from_string+0x3e0) [0x7fa7d0a4cb40] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: ./bin/tor(options_init_from_torrc+0x1e2) [0x7fa7d0a4cde2] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: ./bin/tor(+0x51c79) [0x7fa7d09a9c79] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0xa7b) [0x7fa7cffde24b] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: ./bin/tor(do_main_loop+0x24d) [0x7fa7d09a841d] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: ./bin/tor(tor_main+0x1c25) [0x7fa7d09abbb5] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: ./bin/tor(main+0x19) [0x7fa7d09a3d59] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7fa7cf3cff45] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
Sep 07 18:02:40.000 [err] Bug: ./bin/tor(+0x4bdab) [0x7fa7d09a3dab] (on Tor 0.3.2.0-alpha-dev acfdc4afc126ba23)
```
The reason is because we iterate over intro circuit in the pruning process so we can remove any intro circuit for a service that has been removed. However, by doing so we were asserting on `rend_data` but now we have `hs_ident` for v3 services.
Another occurrence of this can be found in `rend_service_del_ephemeral()` which also iterates over all circuits...Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/23427Add new Ubuntu packager to ReleasingTor.md2021-07-22T16:22:26ZDavid Gouletdgoulet@torproject.orgAdd new Ubuntu packager to ReleasingTor.mdAn Ubuntu packager has been found and is super willing to continue his great work already.
Here is some of the ongoing work to get Xenial (16.04 LTS) to migrate to 029.
https://bugs.launchpad.net/ubuntu/+source/tor/+bug/1710753
That b...An Ubuntu packager has been found and is super willing to continue his great work already.
Here is some of the ongoing work to get Xenial (16.04 LTS) to migrate to 029.
https://bugs.launchpad.net/ubuntu/+source/tor/+bug/1710753
That being said, we should add him to the `ReleasingTor.md` so he gets notified when a new tarball is released.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/23426Remove AllowDotExit2020-06-27T13:55:44ZNick MathewsonRemove AllowDotExitThis option has been deprecated since 0.2.9.x. We can remove it.This option has been deprecated since 0.2.9.x. We can remove it.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23423Remove redundant calls to connection_or_digest_is_known_relay()2021-09-16T14:31:39ZNick MathewsonRemove redundant calls to connection_or_digest_is_known_relay()Many calls to this function occur along with, and are redundant with, channel_is_client().Many calls to this function occur along with, and are redundant with, channel_is_client().https://gitlab.torproject.org/tpo/core/tor/-/issues/23420prop224: Pad RENDEZVOUS1 cell to match legacy cell length2020-06-27T13:55:44ZGeorge Kadianakisprop224: Pad RENDEZVOUS1 cell to match legacy cell lengthWe should do what proposal 224 section 4.3 says and pad rend cells to 168 bytes so that they all look the same.We should do what proposal 224 section 4.3 says and pad rend cells to 168 bytes so that they all look the same.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/23416Document the precision and limits of sample_laplace_distribution()2021-09-16T14:31:39ZteorDocument the precision and limits of sample_laplace_distribution()The function documentation of sample_laplace_distribution() should answer the following questions:
* what is the range of outputs?
* what is the precision of the outputs?
add_laplace_noise() should document, and possible enforce:
* what...The function documentation of sample_laplace_distribution() should answer the following questions:
* what is the range of outputs?
* what is the precision of the outputs?
add_laplace_noise() should document, and possible enforce:
* what is the maximum `delta_f / epsilon` value that can be used within the limits of double precision arithmetic?
* to preserve differential privacy, the low bits have to be obscured by the noise. So this can be at most 2^53^.
* what is the minimum `delta_f / epsilon` value that can be used within the limits of double precision arithmetic?
* (zero provides no differential privacy)https://gitlab.torproject.org/tpo/core/tor/-/issues/23415sample_laplace_distribution() should take multiple random inputs2021-09-16T14:32:00Zteorsample_laplace_distribution() should take multiple random inputsCurrently, sample_laplace_distribution() takes a random double as input, and then extracts the following random values:
* a random sign
* a random value in (0.0, 1.0]
This reduces the precision of the result. For details, see:
https://t...Currently, sample_laplace_distribution() takes a random double as input, and then extracts the following random values:
* a random sign
* a random value in (0.0, 1.0]
This reduces the precision of the result. For details, see:
https://trac.torproject.org/projects/tor/ticket/23061#comment:32
Instead, the function could take a random boolean sign and p, and the transform becomes:
```
result = mu - b * (sign ? 1.0 : -1.0)
* tor_mathlog(1.0 - p);
```
This would increase the precision by one bit, plus whatever precision is lost in `2.0 * fabs(p - 0.5)`.
This may have been introduced in dad5eb7.https://gitlab.torproject.org/tpo/core/tor/-/issues/23414rep_hist_format_hs_stats() should add noise, then round2021-09-16T14:32:00Zteorrep_hist_format_hs_stats() should add noise, then roundIn order to guarantee differential privacy, we need to:
* sample at the scale of the noise (not unit scale)
* add the noise to the signal
* round the noisy signal
This is the "snapping" mitigation from "On Significance of the Least Sign...In order to guarantee differential privacy, we need to:
* sample at the scale of the noise (not unit scale)
* add the noise to the signal
* round the noisy signal
This is the "snapping" mitigation from "On Significance of the Least Significant Bits For Differential Privacy" by Ilya Mironov
https://pdfs.semanticscholar.org/2f2b/7a0d5000a31f7f0713a3d20919f9703c9876.pdf
rep_hist_format_hs_stats() rounds once to the bin size, then adds noise which has been rounded to the nearest integer. This isn't ideal, because it makes the least significant bits of the noise meaningless.
Instead, we should:
* round the noise to integer precision
* add the signal to the noise
* round the noisy signal to the bin size
I think this was introduced in 14e83e6.https://gitlab.torproject.org/tpo/core/tor/-/issues/23406Sampled guards are not re-weighted when a new consensus arrives2020-06-27T13:55:45ZteorSampled guards are not re-weighted when a new consensus arrivesReplying to [https://trac.torproject.org/projects/tor/ticket/23318#comment:5]:
> It's not only case when code bypassing limits, as noticed by pastly in IRC. Guard nodes weights only if new guard added by `entry_guards_expand_sample`. Sam...Replying to [https://trac.torproject.org/projects/tor/ticket/23318#comment:5]:
> It's not only case when code bypassing limits, as noticed by pastly in IRC. Guard nodes weights only if new guard added by `entry_guards_expand_sample`. Sample guard or subsets never being re-weighted: once sampled non-Exit Guard will be used as Exit+Guard (if operator change it policy) by client.
This is probably the behaviour we want: re-weighting based on the latest consensus allows Guard operators to detect exactly when a client downloads the next consensus (because it would stop using that Guard).
That said, keeping old weights might allow attacks based on knowing the weightings in a really old consensus.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23398My relay Consensus Weight went from around 11000 to 202020-06-27T13:55:45ZTracMy relay Consensus Weight went from around 11000 to 20My relay Consensus Weight went from around 11000 to 20, this happened overnight and the relay was online the whole time.
https://atlas.torproject.org/#details/39F5044735BFA39FD959BB0A1161CC3E51225377
**Trac**:
**Username**: DbryrtfbcbhgfMy relay Consensus Weight went from around 11000 to 20, this happened overnight and the relay was online the whole time.
https://atlas.torproject.org/#details/39F5044735BFA39FD959BB0A1161CC3E51225377
**Trac**:
**Username**: Dbryrtfbcbhgfhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23387prop224: HSdir index desynch between client and service2020-06-27T13:55:45ZGeorge Kadianakisprop224: HSdir index desynch between client and serviceDavid found his client unable to connect to his service. Apparently, they compute different hsdir indices, since it was 12:20UTC (non-overlap period) and the live consensus had valid-after at 11:00UTC (overlap period). Apparently somethi...David found his client unable to connect to his service. Apparently, they compute different hsdir indices, since it was 12:20UTC (non-overlap period) and the live consensus had valid-after at 11:00UTC (overlap period). Apparently something got confused.
Theory: We use `time(NULL)` as the time in `node_set_hsdir_index()` whereas we use the live consensus `valid-after` in `rotate_all_descriptors()`. This can cause desynch within the same tor instance. We should probably use the live consensus `valid-after` in all cases to have a common point of reference, and avoid problems with clock skews.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23379Atlas marked my relay as a hsdir even though I disabled DirPort2020-06-27T13:55:45ZTracAtlas marked my relay as a hsdir even though I disabled DirPortAtlas marked my relay as a hsdir even though I disabled DirPort. it says that my Dir Address = none
but it also says that the relay is a HSDir. So is my relay being used as a HSDir or not?
Tor 0.3.0.10
Here is the relay.
https://atlas.t...Atlas marked my relay as a hsdir even though I disabled DirPort. it says that my Dir Address = none
but it also says that the relay is a HSDir. So is my relay being used as a HSDir or not?
Tor 0.3.0.10
Here is the relay.
https://atlas.torproject.org/#details/89F609074A761DA176FFD364FA289BC6F9462D7D
**Trac**:
**Username**: Dbryrtfbcbhgf