Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:37Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34245Declare variables in for loops in rend_service_dump_stats()2020-06-13T15:53:37ZNeel Chauhanneel@neelc.orgDeclare variables in for loops in rend_service_dump_stats()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34238Space out some function calls in parse_short_policy()2020-06-13T15:53:36ZNeel Chauhanneel@neelc.orgSpace out some function calls in parse_short_policy()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34237Fix spacing in if statement in tor_version_parse()2020-06-13T15:53:36ZNeel Chauhanneel@neelc.orgFix spacing in if statement in tor_version_parse()This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```This if statement in tor_version_parse():
```
if ( hexlen == 0 || (hexlen % 2) == 1)
```
should be:
```
if (hexlen == 0 || (hexlen % 2) == 1)
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34236Fix spacing in if statement in port_parse_config()2020-06-13T15:53:35ZNeel Chauhanneel@neelc.orgFix spacing in if statement in port_parse_config()This line in `port_parse_config()`:
```
if ( has_used_unix_socket_only_option && ! unix_socket_path) {
```
should be:
```
if (has_used_unix_socket_only_option && !unix_socket_path) {
```This line in `port_parse_config()`:
```
if ( has_used_unix_socket_only_option && ! unix_socket_path) {
```
should be:
```
if (has_used_unix_socket_only_option && !unix_socket_path) {
```Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/34233Fix use of == in configure.ac2020-06-13T15:53:35ZNick MathewsonFix use of == in configure.acA user points out that we're now using == in configure.ac, which isn't portable.
We'll need to backport a fix everywhere that we backported our #34078 fix.A user points out that we're now using == in configure.ac, which isn't portable.
We'll need to backport a fix everywhere that we backported our #34078 fix.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34232Make summarize_protover_flags() handle NULL and empty string the same2020-06-13T15:53:34ZteorMake summarize_protover_flags() handle NULL and empty string the samesummarize_protover_flags(NULL, NULL) doesn't set protocols_known, but summarize_protover_flags("", "") does.
While this situation probably won't happen in practice, it could be a source of subtle bugs.
And we have a general guideline t...summarize_protover_flags(NULL, NULL) doesn't set protocols_known, but summarize_protover_flags("", "") does.
While this situation probably won't happen in practice, it could be a source of subtle bugs.
And we have a general guideline that functions should treat NULL and "" in similar ways. (Or the difference should be clearly documented.)
So we should ignore "" protovers, the same way we ignore NULL protovers. (Relays with empty protovers won't end up in the consensus, and clients can't use them for anything. So this change should have no real impact.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34220Return to stem master once stem issue 63 is resolved.2020-06-13T15:53:34ZNick MathewsonReturn to stem master once stem issue 63 is resolved.When stem fixes https://github.com/torproject/stem/issues/63 , we should revert the travis.yml change of #34204.When stem fixes https://github.com/torproject/stem/issues/63 , we should revert the travis.yml change of #34204.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34211Add support for control signals (ex. Ctrl+C) in Windows2020-06-13T15:53:33ZTracAdd support for control signals (ex. Ctrl+C) in WindowsHi everyone!
I am working on a [cross-platform Tor controller/wrapper](https://github.com/DcodingTheWeb/ProxAllium/tree/next-gen), and I encountered a minor inconvenience while writing code for stopping Tor in Windows.
Currently the on...Hi everyone!
I am working on a [cross-platform Tor controller/wrapper](https://github.com/DcodingTheWeb/ProxAllium/tree/next-gen), and I encountered a minor inconvenience while writing code for stopping Tor in Windows.
Currently the only way to gracefully terminate Tor in Windows is to use the control port to issue the `SIGINT` signal, it would be beneficial for 3rd party programs which work with Tor to be able to invoke this procedure by using the native "control signals" provided to console programs in Windows.
I have made a patch which implements this functionality, I will post it soon, I am creating this ticket so that I can create a corresponding file in the `changes` directory :)
Thanks to nickm for some pointers about using the libevent `event_active` function to trigger the event, I decided to use the `activate_signal` function as it internally calls the suggested function and simplifies the code.
**Trac**:
**Username**: TheDcoderTor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34204Downgrade Travis stem version to a commit where tests pass.2020-06-13T15:53:32ZNick MathewsonDowngrade Travis stem version to a commit where tests pass.Due to https://github.com/torproject/stem/issues/63 our CI is failing. Let's downgrade to a working version of Stem unless it gets fixed right away.
I have a test PR at https://github.com/torproject/tor/pull/1889 ; if CI passes, I'll m...Due to https://github.com/torproject/stem/issues/63 our CI is failing. Let's downgrade to a working version of Stem unless it gets fixed right away.
I have a test PR at https://github.com/torproject/tor/pull/1889 ; if CI passes, I'll make PRs for the other branches and put this in needs_review.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34200Refactor tor's circuit path node selection checks2020-06-13T15:53:32ZteorRefactor tor's circuit path node selection checksIn #33222, we added an extra "can extend over IPv6" check to tor's circuit path node selection code.
To make sure it's applied consistently, I did a refactor of that code, so all those checks are in one function.In #33222, we added an extra "can extend over IPv6" check to tor's circuit path node selection code.
To make sure it's applied consistently, I did a refactor of that code, so all those checks are in one function.Tor: 0.4.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/34171possible single circuit maximum transfer rate regression in typical circuit p...2020-06-13T15:53:31Zstarlightpossible single circuit maximum transfer rate regression in typical circuit path casesIn late 2018 at the time 0.3.4 phased in the maximum transfer rate for single circuits dropped sharply. A performance regression appears likely imo.In late 2018 at the time 0.3.4 phased in the maximum transfer rate for single circuits dropped sharply. A performance regression appears likely imo.https://gitlab.torproject.org/legacy/trac/-/issues/34167PublishServerDescriptor via IPv62020-06-13T15:53:30ZTracPublishServerDescriptor via IPv6let my relay node configurable by what protocol the upload to authorities is done. similiar to
```
PublishServerDescriptor
```
option.
perhaps add option like
```
PublishServerDescriptorProtocol auto|4|6|or
# This option specifi...let my relay node configurable by what protocol the upload to authorities is done. similiar to
```
PublishServerDescriptor
```
option.
perhaps add option like
```
PublishServerDescriptorProtocol auto|4|6|or
# This option specifies how descriptors Tor will publish when acting as
# a relay. You can
# choose multiple arguments, separated by commas.
#
# If this option is set to 4, Tor will publish its
# descriptors to any directories over IPv4. (This is useful if you're not IPv6 connectable
# out your server, or if you're using a IPv6 Translation Tunnel)
# Otherwise, Tor will publish its
# descriptors via IPv6. The default is "auto", which
# means "if running as a relay or bridge, publish descriptors to the
# appropriate authorities over what's reachable". Other possibilities are "or", meaning
# "publish as if you're a OnionService", "publish over onion circuit".
```
_may Sponsor55 or prop311-prop313 already covered if i missed or could be relevant for_
**Trac**:
**Username**: ϲypherpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34139Build Tor without warnings or test failures with OpenSSL 3.0.02020-06-13T15:53:30ZNick MathewsonBuild Tor without warnings or test failures with OpenSSL 3.0.0According to the OpenSSL release strategy [release-strat] they're planning to release openssl 3.0.0 in early Q4 of this year.
Currently, many of the APIs that Tor uses are deprecated in OpenSSL 3.0.0-alpha [openssl-3]. It's still poss...According to the OpenSSL release strategy [release-strat] they're planning to release openssl 3.0.0 in early Q4 of this year.
Currently, many of the APIs that Tor uses are deprecated in OpenSSL 3.0.0-alpha [openssl-3]. It's still possible to build Tor with it, but you get a lot of deprecated-item warnings. We should fix those warnings before OpenSSL 3 is released.
Further, if we build without fatal warnings, there are some test failures. We should see if they are tor bugs or new openssl bugs, and fix them in the first case or report them in the second.
I don't think we necessarily need to backport this: OpenSSL 1.1 will be supported until 2023-09-11 [release-strat], whereas support for 0.3.5 is scheduled to end on 2020-02-02.
[release-strat] https://www.openssl.org/policies/releasestrat.html
[openssl-3] https://www.openssl.org/blog/blog/2020/04/23/OpenSSL3.0Alpha1/Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34137Make sure inform_testing_reachability() reports the correct ports2020-06-13T15:53:29ZteorMake sure inform_testing_reachability() reports the correct portsIn #33222, we added IPv6 ORPort support to inform_testing_reachability(). But that function checks the ORPorts and DirPort itself, rather than logging the reachability checks that were actually launched.
We'd like to pass flags so that ...In #33222, we added IPv6 ORPort support to inform_testing_reachability(). But that function checks the ORPorts and DirPort itself, rather than logging the reachability checks that were actually launched.
We'd like to pass flags so that it logs the actual reachability tests that are being run. (Rather than re-checking the relay's own routerinfo, which may have changed since the most recent reachability checks were launched.)
But inform_testing_reachability() is called when:
* the first circuit finishes building, or
* tor is reconfigured, and some circuits have already finished building.
So we need to do a bit of a refactor.
The refactor should preserve this behaviour:
* don't log until after the first circuit has finished building (rather than logging as soon as we start building reachability circuits)
And introduce this new behaviour:
* log the ports that were tested recently, rather than the ports that are currently available.
As an alternative, we could move some of the logging into the functions that actually launch the checks. And elevate some of those logs to notice level. (Note that these checks can be launched from at least 4 different locations in tor's code.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34135Feature suggestion: SOCKS5 internal DNS resolver.2020-06-13T15:53:28ZTracFeature suggestion: SOCKS5 internal DNS resolver.There are many programs that forward DNS request over SOCKS5 proxies, to work with tor the most of them send the queries in TCP format.
But they cannot use the DNS of Tor relays, they can only send to an external DNS server, so disablin...There are many programs that forward DNS request over SOCKS5 proxies, to work with tor the most of them send the queries in TCP format.
But they cannot use the DNS of Tor relays, they can only send to an external DNS server, so disabling access to .onion sites.
That's why a virtual DNS server in the TOR SOCKS5 server would be useful, so these programs can use relays DNS and handle .onion queries.
Another case are transparent forwarders that use a upstream SOCKS5 address, DNS should be provided by a kind of program like above or a DNS over TCP scheme (available in the Linux GLIBC since 2015, see https://web.archive.org/web/20150518063349/http://man7.org:80/linux/man-pages/man5/resolv.conf.5.html).
By adding the option "use-vc" in the Linux /etc/resolv.conf file, DNS queries can be done over the transparent proxy using external DNS servers, BUT NOT DNS of Tor relays and it cannot resolves .onion sites.
For these cases a virtual DNS resolver in the TOR SOCKS port would be useful, it can be only TCP (not UDP).
This is for DNS forwarders that use SOCKS proxies, and provide DNS in TCP mode to environments over transparent proxies.
The virtual addresses could be 224.0.0.1 for IPv4 and [2001:db8::1] for IPv6.
**Trac**:
**Username**: pcrhttps://gitlab.torproject.org/legacy/trac/-/issues/34133Tor documentation missing sandbox and %include limitations2020-06-13T15:53:28ZJigsaw52Tor documentation missing sandbox and %include limitationsThe tor manpage and documentation do not tell the user that is not possible to add new configuration files to %included directories in its config files when the seccomp sandbox is enabled.The tor manpage and documentation do not tell the user that is not possible to add new configuration files to %included directories in its config files when the seccomp sandbox is enabled.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34131Fix logic error in parse_extended_hostname2020-06-13T15:53:27ZNick MathewsonFix logic error in parse_extended_hostnameFound with a new clang warning:
```
log_warn(LD_APP, "Invalid %shostname %s; rejecting",
(*type_out == (ONION_V2_HOSTNAME || ONION_V3_HOSTNAME) ? "onion " : ""),
safe_str_client(address));
```Found with a new clang warning:
```
log_warn(LD_APP, "Invalid %shostname %s; rejecting",
(*type_out == (ONION_V2_HOSTNAME || ONION_V3_HOSTNAME) ? "onion " : ""),
safe_str_client(address));
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/34130Tor won't start with seccomp sandbox when compiled with --enable-nss2020-06-13T15:53:27ZJigsaw52Tor won't start with seccomp sandbox when compiled with --enable-nssAfter compiling tor with the --enable-nss flag, starting tor with "Sandbox 1" on torrc results on the following error:
```
May 06 21:47:46.198 [notice] Tor 0.4.4.0-alpha-dev (git-42dfcd0ae3f7a872) running on Linux with Libevent 2.1.8-st...After compiling tor with the --enable-nss flag, starting tor with "Sandbox 1" on torrc results on the following error:
```
May 06 21:47:46.198 [notice] Tor 0.4.4.0-alpha-dev (git-42dfcd0ae3f7a872) running on Linux with Libevent 2.1.8-stable, NSS 3.35, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3.
May 06 21:47:46.198 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 06 21:47:46.198 [notice] This version is not a stable Tor release. Expect more bugs than usual.
May 06 21:47:46.198 [notice] Read configuration file "/home/daniel/Desktop/torrc_sandbox".
May 06 21:47:46.200 [notice] Opening Socks listener on 127.0.0.1:9050
May 06 21:47:46.200 [notice] Opened Socks listener on 127.0.0.1:9050
May 06 21:47:46.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
May 06 21:47:46.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
May 06 21:47:46.000 [warn] TLS error PR_NO_ACCESS_RIGHTS_ERROR while constructing a client TLS context: Access Denied
May 06 21:47:46.000 [err] Error creating TLS context for Tor client.
May 06 21:47:46.000 [err] Error initializing keys; exiting
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34088circuit_build_times_update_alpha(): Bug: Could not determine largest build time2020-06-13T15:53:26Zs7rcircuit_build_times_update_alpha(): Bug: Could not determine largest build timeI don't think this is HSv3 ONLY related, but I can only make it happen while building large amounts of rendezvous circuits with reasonable concurrency (over 50). I am not assigning the tor-hs keyword for this reason, but sticking it to s...I don't think this is HSv3 ONLY related, but I can only make it happen while building large amounts of rendezvous circuits with reasonable concurrency (over 50). I am not assigning the tor-hs keyword for this reason, but sticking it to same master parent ticket.
All lines are the same. It is seen for like 130-160 times during the build of little over 100.000 rendezvous circuits.
```
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 136 circuits. (on Tor 0.4.4.0-alpha-dev )
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 137 circuits. (on Tor 0.4.4.0-alpha-dev )
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 138 circuits. (on Tor 0.4.4.0-alpha-dev )
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 139 circuits. (on Tor 0.4.4.0-alpha-dev )
Apr 03 04:05:33.000 [warn] circuit_build_times_update_alpha(): Bug: Could not determine largest build time (0). Xm is 20025ms and we've abandoned 0 out of 140 circuits. (on Tor 0.4.4.0-alpha-dev )
```
EDIT: All lines are the same except it always abandons 0 out of N circuits and N is always different of course, increasing with +1 most of the times until the Bug warn disappears.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/34087HSv3: Bug: Non-fatal assertion in hs_client.c:981: close_or_reextend_intro_circ2020-06-13T15:53:26Zs7rHSv3: Bug: Non-fatal assertion in hs_client.c:981: close_or_reextend_intro_circClient side HSv3 non fatal bug. It occurs like between ~20 - 30 times in a total of 100.000 built rendezvous circuits:
```
Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_c...Client side HSv3 non fatal bug. It occurs like between ~20 - 30 times in a total of 100.000 built rendezvous circuits:
```
Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_circ: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion !(desc == NULL) failed in close_or_reextend_intro_circ at ../src/feature/hs/hs_client.c:981. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(log_backtrace_impl+0x56) [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(tor_bug_occurred_+0x16c) [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(hs_client_receive_introduce_ack+0x2f5) [0x55d8749cfe95] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(rend_process_relay_cell+0x226) [0x55d874a1e796] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0xbe368) [0x55d874966368] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4) [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(command_process_cell+0x2c8) [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb) [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(connection_handle_read+0xa92) [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(do_main_loop+0xff) [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(tor_run_main+0x10b5) [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_circ: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.4.4.0-alpha-dev )
```Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org