Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:41Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34299man page has wrong default for MinUptimeHidServDirectoryV22020-06-13T15:53:41ZRoger Dingledineman page has wrong default for MinUptimeHidServDirectoryV2In #14149 (Tor 0.2.6.3-alpha) we changed the default for MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory authorities had already changed it manually. We changed the spec too. But we forgot to change the man page.In #14149 (Tor 0.2.6.3-alpha) we changed the default for MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory authorities had already changed it manually. We changed the spec too. But we forgot to change the man page.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/34255Doxygen warnings on 0.4.32020-06-13T15:53:40ZNick MathewsonDoxygen warnings on 0.4.3There are some doxygen warnings about unclosed or unbalanced groups.There are some doxygen warnings about unclosed or unbalanced groups.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://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/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/33839Correct 'was not internal' to 'was internal' in test_external_ip()2020-06-13T15:52:57ZTracCorrect 'was not internal' to 'was internal' in test_external_ip()source: https://github.com/torproject/tor/pull/1856
Fixing a typo in a string that is printed on event of a test failing, in `src/test/test_addr.c`.
**Trac**:
**Username**: kimimarosource: https://github.com/torproject/tor/pull/1856
Fixing a typo in a string that is printed on event of a test failing, in `src/test/test_addr.c`.
**Trac**:
**Username**: kimimaroTor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33837Tor.framework Unknown type name 'dispatch_queue_t'2020-06-13T15:52:56ZteorTor.framework Unknown type name 'dispatch_queue_t'From https://trac.torproject.org/projects/tor/ticket/33522#comment:2
>
> Replying to [tla](#33522):
> > It has a Travis-CI configuration, which I just updated to work on the latest macOS/Xcode image:
> >
> > https://github.com/iCepa/To...From https://trac.torproject.org/projects/tor/ticket/33522#comment:2
>
> Replying to [tla](#33522):
> > It has a Travis-CI configuration, which I just updated to work on the latest macOS/Xcode image:
> >
> > https://github.com/iCepa/Tor.framework/blob/master/.travis.yml
> >
> >
> > Currently, we have issues in getting past Tor 0.4.0.6 on iOS. When I try to use a newer core, I get this error message:
> >
> > > Unknown type name 'dispatch_queue_t'
> >
> > in CFStream of Apple's CoreFoundation framework.
> >
> >
> > But "dispatch_queue_t" is actually a valid symbol from Apple's Foundation libraries.
> >
> > So somehow, it gets cancelled out through something which changed in Tor recently.
>
> This looks like a bug in tor's code, or perhaps in the Tor.framework embedding scripts.
>
> We'd be happy to help you diagnose this issue.
>
> Can you tell us the first release that has this issue? Is it 0.4.1, 0.4.2, or 0.4.3 ?
> Have you done a git bisect, to track down the commit that introduced the issue?
>
> Let's open a separate ticket, so we can fix this bug in tor's code.
> Or help you find a workaround when you embed tor.
I can't see dispatch_queue_t in Tor's code.
Perhaps we're defining some preprocessor symbols, or including a header that conflicts with dispatch_queue_t's header.
We don't know which release this bug was introduced in. But Tor 0.4.0.6 does not have this error.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33804Defer "PreferIPv6 by default" to 0.4.42020-06-13T15:52:47ZteorDefer "PreferIPv6 by default" to 0.4.4In #32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in #33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement IPv4-only and IPv6-onl...In #32637, we made clients default to "PreferIPv6" on SOCKSPorts (and other client ports).
But in #33796, we discovered that this change broke torsocks.
We want to defer this change to 0.4.4, so tor can implement IPv4-only and IPv6-only resolves for torsocks.
Since #32637, we have also merged:
* #33608, which removes a forced PreferIPv6 for non-SOCKSPorts
* #32994, which puts the PreferIPv6 default in port_parse_config(), rather than in 2 different places in the code
So it should be very easy to change the default for PreferIPv6.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33782Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions2020-06-13T15:52:43ZTracIncreases TEST_CONN_FD_INIT to make tests working on GitHub ActionsWith the current value, which is 50; it will cause some tests to fail on GitHub Actions:
```
hs_client/e2e_rend_circuit_setup_legacy: [forking] Mar 31 17:01:17.348 [warn] tor_bug_occurred_(): Bug: src/lib/net/socket.c:237: tor_close_soc...With the current value, which is 50; it will cause some tests to fail on GitHub Actions:
```
hs_client/e2e_rend_circuit_setup_legacy: [forking] Mar 31 17:01:17.348 [warn] tor_bug_occurred_(): Bug: src/lib/net/socket.c:237: tor_close_socket__real: Non-fatal assertion n_sockets_open >= 0 failed. (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: Tor 0.4.2.5: Non-fatal assertion n_sockets_open >= 0 failed in tor_close_socket__real at src/lib/net/socket.c:237. Stack trace: (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(log_backtrace_impl+0x56) [0x55d2831c7696] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tor_bug_occurred_+0x17f) [0x55d2831c2fcf] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tor_close_socket__real+0xd7) [0x55d2831ba3f7] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(connection_free_minimal+0x1c7) [0x55d28302a507] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(+0x2d5dff) [0x55d282e91dff] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(+0x444c66) [0x55d283000c66] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(testcase_run_one+0x2f1) [0x55d283000fb1] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tinytest_main+0x10c) [0x55d28300156c] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(main+0x2a0) [0x55d282cad9f0] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f65fdf83b97] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(_start+0x2a) [0x55d282cadb1a] (on Tor 0.4.2.5 )
[e2e_rend_circuit_setup_legacy FAILED]
```
The reason is because of a process running in GitHub Actions doing something that caused a lot of file descriptors to open. So, when Tor is trying to close a fake socket it ends up closing a real one that was opened by GitHub Actions.
I already tried with 100 and it does not work. So I tried 200 and it works.
**Trac**:
**Username**: ultimaweaponTor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33678Disable practracker in git hooks in maint-0.4.32020-06-13T15:52:27ZteorDisable practracker in git hooks in maint-0.4.3Let's remove .enable_practracker_in_hooks to disable practracker in hooks in maint-0.4.3.Let's remove .enable_practracker_in_hooks to disable practracker in hooks in maint-0.4.3.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33668--disable-module-relay yields to a Bug:2020-06-13T15:52:24Ztoralf--disable-module-relay yields to a Bug:At a hardened Gentoo Linux the configure option yields to a
```
# tor --verify-config
Mar 19 19:44:35.839 [notice] Tor 0.4.3.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and L...At a hardened Gentoo Linux the configure option yields to a
```
# tor --verify-config
Mar 19 19:44:35.839 [notice] Tor 0.4.3.3-alpha running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A.
Mar 19 19:44:35.840 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 19 19:44:35.840 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Mar 19 19:44:35.840 [notice] Read configuration file "/etc/tor/torrc".
Mar 19 19:44:35.843 [err] tor_assertion_failed_(): Bug: src/app/config/config.c:1473: options_switch_id: Assertion have_low_ports != -1 failed; aborting. (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.844 [err] Bug: Tor 0.4.3.3-alpha: Assertion have_low_ports != -1 failed in options_switch_id at src/app/config/config.c:1473: . Stack trace: (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(log_backtrace_impl+0x59) [0x5564677d3ab9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(tor_assertion_failed_+0x150) [0x5564677cecb0] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(set_options+0x404) [0x5564677535d4] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(+0x1648a0) [0x5564677548a0] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(options_init_from_string+0x119) [0x556467754af9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(options_init_from_torrc+0x359) [0x5564677550f9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.845 [err] Bug: tor(tor_init+0x1c7) [0x55646764ade7] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(tor_run_main+0x71) [0x55646764b4e1] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(tor_main+0x46) [0x55646764a006] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(main+0x19) [0x556467649bd9] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xeb) [0x7ff9817b8f1b] (on Tor 0.4.3.3-alpha )
Mar 19 19:44:35.846 [err] Bug: tor(_start+0x2a) [0x556467649c2a] (on Tor 0.4.3.3-alpha )
Aborted
```
The same tarball at the same system works fine with that option being enabled.
The config is
```
cat /etc/tor/torrc
User tor
PIDFile /var/run/tor/tor.pid
Log notice file /tmp/notice.log
DataDirectory /var/lib/tor/data
CookieAuthentication 1
ControlPort 9051
SocksPort 9050
SandBox 1
```Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33646Wrong list of enabled modules2020-06-13T15:52:22ZTracWrong list of enabled modulesWhen I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth...When I build tor 0.4.3.3-alpha with
`./autogen.sh && ./configure --disable-unittests --disable-module-dirauth && make`
line, I see following text:
```
Modules
relay (--disable-module-relay): yes
dirauth (--disable-module-dirauth): yes
dircache (--disable-module-dircache): yes
```
Which is wrong, since I have enabled relay and disabled dirauth.
Looks like problem is located in commit [9c33d36113447d38decd22d177e62fb225826d78](https://gitweb.torproject.org/tor.git/commit/?id=9c33d36113447d38decd22d177e62fb225826d78).
Related: #32230.
Please recheck.
**Trac**:
**Username**: VortTor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33608Stop forcing prefer IPv6 on non-SOCKSPorts2020-06-13T15:52:11ZteorStop forcing prefer IPv6 on non-SOCKSPortsIn #32637 we forced PreferIPv6 on all non-SOCKSPorts.
That could be a breaking change for some users, and they will have no way to recover. We should just set a sensible default, and let users tweak it if it doesn't work for them.In #32637 we forced PreferIPv6 on all non-SOCKSPorts.
That could be a breaking change for some users, and they will have no way to recover. We should just set a sensible default, and let users tweak it if it doesn't work for them.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33545assertion failure when "all zero" client auth key provided2020-06-13T15:53:04ZMark Smithassertion failure when "all zero" client auth key providedWhile doing some Tor Browser testing for Sponsor 27, I experienced the following after I intentionally used an incorrect client auth key for a v3 onion service:
```
... [err] tor_assertion_failed_: Bug: src/feature/hs/hs_descriptor.c:142...While doing some Tor Browser testing for Sponsor 27, I experienced the following after I intentionally used an incorrect client auth key for a v3 onion service:
```
... [err] tor_assertion_failed_: Bug: src/feature/hs/hs_descriptor.c:1423: decrypt_descriptor_cookie: Assertion !fast_mem_is_zero((char *) client_auth_sk, sizeof(*client_auth_sk)) failed; aborting. (on Tor 0.4.4.0-alpha-dev 1da0b05a5cace6ed)
```
As it turns out, I happened to enter a key that is consists entirely of zero bits. This is an unusual thing to do, but I do not think tor should exit.
Steps to reproduce in Tor Browser:
1. Try to load an http or https page for a v3 onion service that requires client authentication, e.g., dgoulet's test server.
2. Enter 56 'A's when prompted for a client auth key.
Result: tor exits due to the assertion failure. Behind the scenes, the browser installs the key via a control port command like the following:
```
onion_client_auth_add <onion-addr> x25519:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
```
and then tries to access the onion service again (page reload).Tor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/33460confmgt: include variable name in all complaints.2020-06-13T15:51:52ZNick Mathewsonconfmgt: include variable name in all complaints.When we give a msg about failing to parse a variable, we should say what the variable was, and ideally what was wrong with it.
Compare the results for running `./src/app/tor UseBridges 99` in 0.3.5 and in master. With 0.3.5 you got: `B...When we give a msg about failing to parse a variable, we should say what the variable was, and ideally what was wrong with it.
Compare the results for running `./src/app/tor UseBridges 99` in 0.3.5 and in master. With 0.3.5 you got: `Boolean 'UseBridges 99' expects 0 or 1.` but now you get `Unrecognized value 99.`
Let's make that better.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33427Link to the auto-generated documentation in GettingStarted.md2020-06-13T15:51:47ZteorLink to the auto-generated documentation in GettingStarted.mdOur GettingStarted.md developer document still links to the old torguts git repository:
https://gitweb.torproject.org/tor.git/tree/doc/HACKING/GettingStarted.md#n53
But it should link to our new auto-generated documentation.
I don't kn...Our GettingStarted.md developer document still links to the old torguts git repository:
https://gitweb.torproject.org/tor.git/tree/doc/HACKING/GettingStarted.md#n53
But it should link to our new auto-generated documentation.
I don't know the details of the new docs website. But it would be nice to have it done for Outreachy.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33374Fix unicode warnings in practracker using python 22020-06-13T15:51:36ZteorFix unicode warnings in practracker using python 2When I run practracker using python 2, I get the following unicode warning:
```
$ scripts/maint/practracker/practracker.py --regen-overbroad
Traceback (most recent call last):
File "scripts/maint/practracker/practracker.py", line 324, ...When I run practracker using python 2, I get the following unicode warning:
```
$ scripts/maint/practracker/practracker.py --regen-overbroad
Traceback (most recent call last):
File "scripts/maint/practracker/practracker.py", line 324, in <module>
main(sys.argv)
File "scripts/maint/practracker/practracker.py", line 268, in main
for item in filt.filter(consider_all_metrics(files_list)):
File "/Users/hyper/dev/tor/scripts/maint/practracker/problem.py", line 147, in filter
for item in iter(sequence):
File "scripts/maint/practracker/practracker.py", line 110, in consider_all_metrics
for item in consider_metrics_for_file(fname, f):
File "scripts/maint/practracker/practracker.py", line 134, in consider_metrics_for_file
for item in consider_function_size(fname, f):
File "scripts/maint/practracker/practracker.py", line 91, in consider_function_size
for name, lines in metrics.get_function_lines(f):
File "/Users/hyper/dev/tor/scripts/maint/practracker/metrics.py", line 58, in get_function_lines
if line.startswith("}"):
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 22: ordinal not in range(128)
Exit 1
```
We can fix this issue by using the codecs module to open files in unicode mode.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33339Add script to check ordering of options in manpage2020-06-13T15:51:26ZTaylor YuAdd script to check ordering of options in manpageAdd a script to check the ordering of option names within a manpage section.
This will be an initial version that doesn't restrict section names and doesn't recognize pragma comments that mark intentionally out-of-order option names.
#...Add a script to check the ordering of option names within a manpage section.
This will be an initial version that doesn't restrict section names and doesn't recognize pragma comments that mark intentionally out-of-order option names.
#32621 will contain a more fully-functional script suitable for automation.Tor: 0.4.3.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/33218Add Jenkins builders for 0.4.32020-06-13T17:00:50ZNick MathewsonAdd Jenkins builders for 0.4.3Tor 0.4.3.x development now proceeds on its own branches (maint-0.4.3 and release-0.4.3); let's add them to Jenkins too.Tor 0.4.3.x development now proceeds on its own branches (maint-0.4.3 and release-0.4.3); let's add them to Jenkins too.Tor: 0.4.3.x-finalweasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/legacy/trac/-/issues/33217Update scripts to add 0.4.3 and remove 0.4.02020-06-13T15:50:52ZNick MathewsonUpdate scripts to add 0.4.3 and remove 0.4.0Tor: 0.4.3.x-finalNick MathewsonNick Mathewson