The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:51:58Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/279830.3.2.x reached it's EOL date: remove version 0.3.2.x from recommended versions2020-06-27T13:51:58Znusenu0.3.2.x reached it's EOL date: remove version 0.3.2.x from recommended versionstor 0.3.2 reached end-of-life as of 2018-10-09
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases
let's remove these versions from the recommended versions list:
server-versions 0.2.9.14, 0.2.9.15, 0.2...tor 0.3.2 reached end-of-life as of 2018-10-09
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases
let's remove these versions from the recommended versions list:
server-versions 0.2.9.14, 0.2.9.15, 0.2.9.16, 0.2.9.17, ~~0.3.2.10, 0.3.2.11, 0.3.2.12~~, 0.3.3.2-alpha, 0.3.3.3-alpha, 0.3.3.4-alpha, 0.3.3.5-rc, 0.3.3.6, 0.3.3.7, 0.3.3.8, 0.3.3.9, 0.3.3.10, 0.3.4.1-alpha, 0.3.4.2-alpha, 0.3.4.3-alpha, 0.3.4.4-rc, 0.3.4.5-rc, 0.3.4.6-rc, 0.3.4.7-rc, 0.3.4.8, 0.3.5.1-alpha, 0.3.5.2-alphaTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27968SIGNAL HALT race condition in test-rebind.py2020-06-27T13:51:58ZteorSIGNAL HALT race condition in test-rebind.pyIf tor exits due to SIGNAL HALT, before the python subprocess module terminates it, then test-rebind.py can fail with OSError 3 (no such process).
This race condition causes make check failures on my laptop running Windows Subsystem for...If tor exits due to SIGNAL HALT, before the python subprocess module terminates it, then test-rebind.py can fail with OSError 3 (no such process).
This race condition causes make check failures on my laptop running Windows Subsystem for Linux. It could potentially cause CI failures on busy machines.
I have a patch that rewrites test-rebind.py to be more reliable.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27963Undefined symbol: "timeradd", first referenced in src/lib/libtor-thread.a2020-06-27T13:51:58ZTracUndefined symbol: "timeradd", first referenced in src/lib/libtor-thread.aWhen compiling tor-0.3.5.2-alpha on Solaris10, x64, with gcc 5.2.0 I'm getting an undefined symbole "timeradd", see below (or attached log file):
...
...
CC src/feature/dirauth/src_core_libtor_app_testing_a-shared_random_state.o
...When compiling tor-0.3.5.2-alpha on Solaris10, x64, with gcc 5.2.0 I'm getting an undefined symbole "timeradd", see below (or attached log file):
...
...
CC src/feature/dirauth/src_core_libtor_app_testing_a-shared_random_state.o
AR src/core/libtor-app-testing.a
CC src/tools/tor_runner.o
AR src/tools/libtorrunner.a
CC src/app/main/tor_main.o
CCLD src/app/tor
Undefined first referenced
symbol in file
timeradd src/lib/libtor-thread.a(compat_pthreads.o)
ld: fatal: symbol referencing errors. No output written to src/app/tor
gmake[1]: *** [src/app/tor] Error 1
gmake[1]: Leaving directory `/usr/local/lib/tor-0.3.5.2-alpha'
gmake: *** [all] Error 2
#
**Trac**:
**Username**: KnutTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27962Newline missing between between hs_client_get_random_intro_from_edge() and hs...2020-06-27T13:51:58ZNeel Chauhanneel@neelc.orgNewline missing between between hs_client_get_random_intro_from_edge() and hs_client_receive_introduce_ack()In `feature/hs/hs_client.c` on between lines 1733 and 1734, a newline is missing.In `feature/hs/hs_client.c` on between lines 1733 and 1734, a newline is missing.Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27953Authorization types for v3 onion service have to be clarified in documentation2021-09-30T13:25:25ZTracAuthorization types for v3 onion service have to be clarified in documentationProblem 1. Official [[https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt|spec]] mentions stealth auth:
> [TODO: Also specify stealth client authorization.].
However, stealth auth is only used for v2 onion services. It sh...Problem 1. Official [[https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt|spec]] mentions stealth auth:
> [TODO: Also specify stealth client authorization.].
However, stealth auth is only used for v2 onion services. It should be fixed.
----
Problem 2. According to teor's [[https://trac.torproject.org/projects/tor/ticket/20700#comment:23|comment]] the following auth types were planned: 'descriptor', 'intro', and 'standard'. However, only 'descriptor' type is documented by spec (man page for tor alpha refers to spec for details). Other auth types are not documented at all, though spec gives a strong impression that 'descriptor' is only one of possible authentication types.
If tor project already has some understanding of these future planned auth types, they must be described at least in tickets. If it is not the case, somewhere (e.g. in man page which now refers to spec) we should write that 'descriptor' is the only auth type which will be supported in foreseeable future.
**Trac**:
**Username**: geoiphttps://gitlab.torproject.org/tpo/core/tor/-/issues/27948Backtrace does not work on NetBSD2020-06-27T13:51:59ZTracBacktrace does not work on NetBSDI've run the self-tests on NetBSD-8.99.25/amd64, and I see two issues:
# TOTAL: 19
# PASS: 12
# SKIP: 5
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 0
... ...I've run the self-tests on NetBSD-8.99.25/amd64, and I see two issues:
# TOTAL: 19
# PASS: 12
# SKIP: 5
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 0
...
FAIL: src/test/test
===================
....
util/thread/conditionvar_timeout: [forking]
FAIL src/test/test_threads.c:285: assert(ti->n_timeouts OP_EQ 2): 1 vs 2Sep 10 14:30:54.789 [err] Error 16 destroying a mutex.
Sep 10 14:30:54.789 [err] tor_assertion_failed_(): Bug: src/common/compat_pthreads.c:172: tor_mutex_uninit: Assertion 0 failed; aborting. (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: Assertion 0 failed in tor_mutex_uninit at src/common/compat_pthreads.c:172. Stack trace: (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefe62985 <log_backtrace+0x4e> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefe7d021 <tor_assertion_failed_+0xa0> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefe80e3d <tor_mutex_uninit+0xa6> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefe693ff <tor_mutex_free_+0x2e> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefc92ee2 <test_threads_conditionvar+0xefa001f3> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefcedd21 <testcase_run_bare_+0xefa00051> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefcedecd <testcase_run_one+0x158> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefcee51c <tinytest_main+0x107> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefe99621 <main+0x2d1> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
[Lost connection!]
[conditionvar_timeout FAILED]
util/handle/basic: OK
...
FAIL: src/test/test_bt.sh
=========================
OK
[1] Abort trap "${builddir:-.}/src/test/test-bt-cl" assert 2>&1 |
Done "${PYTHON:-python}" "${abs_top_srcdir:-.}/src/...
BAD
============================================================ T= 1536589911
Tor died: Caught signal 11
0x94a0aa3d <crash_handler+0x94a00043> at ./src/test/test-bt-cl
0x94a0a8cd <crash+0x45> at ./src/test/test-bt-cl
[1] Abort trap "${builddir:-.}/src/test/test-bt-cl" crash 2>&1 |
Done(1) "${PYTHON:-python}" "${abs_top_srcdir:-.}/src/...
-158318
FAIL src/test/test_bt.sh (exit status: 1)
# gdb src/test/test test.core
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from src/test/test...done.
[New process 1]
[New process 5]
[New process 2]
bCore was generated by `test'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007500d531eeca in _lwp_kill () from /usr/lib/libc.so.12
[Current thread is 1 (process 1)]
(gdb) bt
#0 0x00007500d531eeca in _lwp_kill () from /usr/lib/libc.so.12
#1 0x00007500d531eb57 in abort () at /usr/src/lib/libc/stdlib/abort.c:74
legacy/trac#2 0x00000000efe80e42 in tor_mutex_uninit (m=m@entry=0x7500d3e0b080) at src/common/compat_pthreads.c:172
legacy/trac#3 0x00000000efe693ff in tor_mutex_free_ (m=0x7500d3e0b080) at src/common/compat_threads.c:55
legacy/trac#4 0x00000000efc92ee2 in cv_testinfo_free (i=0x7500d3e09080) at src/test/test_threads.c:186
legacy/trac#5 test_threads_conditionvar (arg=<optimized out>) at src/test/test_threads.c:290
legacy/trac#6 0x00000000efcedd21 in testcase_run_bare_ (testcase=testcase@entry=0xf0263850 <thread_tests+80>) at src/ext/tinytest.c:106
legacy/trac#7 0x00000000efcedecd in testcase_run_forked_ (group=<optimized out>, testcase=0xf0263850 <thread_tests+80>) at src/ext/tinytest.c:190
legacy/trac#8 testcase_run_one (group=<optimized out>, testcase=0xf0263850 <thread_tests+80>) at src/ext/tinytest.c:248
legacy/trac#9 0x00000000efcee51c in tinytest_main (c=<optimized out>, v=<optimized out>, groups=<optimized out>) at src/ext/tinytest.c:435
legacy/trac#10 0x00000000efe99621 in main (c=1, v=0x7f7fffc611d8) at src/test/testing_common.c:319
**Trac**:
**Username**: wizTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27946"ExitRelay 0" ignored if config files are in include directories2020-06-27T13:51:59Ztoralf"ExitRelay 0" ignored if config files are in include directoriesThis
```
%include /etc/tor/torrc.d/
ExitRelay 0
IPv6Exit 0
```
seems not to work if there'S a file in /etc/tor/torrc.d/ containing
```
ExitRelay 1
IPv6Exit 1
```This
```
%include /etc/tor/torrc.d/
ExitRelay 0
IPv6Exit 0
```
seems not to work if there'S a file in /etc/tor/torrc.d/ containing
```
ExitRelay 1
IPv6Exit 1
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27943Broken Appveyor build2020-06-27T13:51:59Zrl1987Broken Appveyor build```
checking for file conflicts...
error:
failed to commit transaction (conflicting files)
```
https://ci.appveyor.com/project/torproject/tor/build/1.0.1020/job/o62dw3iklb8da8wv```
checking for file conflicts...
error:
failed to commit transaction (conflicting files)
```
https://ci.appveyor.com/project/torproject/tor/build/1.0.1020/job/o62dw3iklb8da8wvTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27929Consider no longer calling routerlist_remove_old_routers() from check_descrip...2021-09-16T14:28:09Zrl1987Consider no longer calling routerlist_remove_old_routers() from check_descriptor_callback()```
2237 /* Remove dead routers. */
2238 /* XXXX This doesn't belong here, but it was here in the pre-
2239 * XXXX refactoring code. */
2240 routerlist_remove_old_routers();
2241 }
```
We should see if there's better ...```
2237 /* Remove dead routers. */
2238 /* XXXX This doesn't belong here, but it was here in the pre-
2239 * XXXX refactoring code. */
2240 routerlist_remove_old_routers();
2241 }
```
We should see if there's better place to call this function from.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27928Refrain from listener rebinding when address families differ2020-06-27T13:51:59Zrl1987Refrain from listener rebinding when address families differIn `retry_listener_ports`, we check if port matches exactly and *one* of the addresses is a wildcard address:
```
2795 const int may_need_rebind =
2796 port_matches_exact && bool_neq(tor_addr_is_null(&wanted->addr),
279...In `retry_listener_ports`, we check if port matches exactly and *one* of the addresses is a wildcard address:
```
2795 const int may_need_rebind =
2796 port_matches_exact && bool_neq(tor_addr_is_null(&wanted->addr),
2797 tor_addr_is_null(&conn->addr));
```
We should also check if address family is the same between old and new listener. If they differ, we don't need to do rebinding. See discussion on legacy/trac#17873.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27924Split up routerparse.c2020-06-27T13:51:59ZNick MathewsonSplit up routerparse.cIt's one of the largest files still in tor, and it should divide up nicely.It's one of the largest files still in tor, and it should divide up nicely.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27921apparent DOS / impairment-of-service against FallbackDirs using DIR requests,...2022-10-11T23:39:49Zstarlightapparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigationEarly this year I noticed excessive DIR requests against my relay and also in the Relay Search usage graphs of other fallback directory nodes. Wrote an iptables rule and put an end to it.
The attacker enhanced their botware to request ...Early this year I noticed excessive DIR requests against my relay and also in the Relay Search usage graphs of other fallback directory nodes. Wrote an iptables rule and put an end to it.
The attacker enhanced their botware to request via OR port and the problem is back. In the previous 24-hour stats window DIR requests increased output load on the relay by 17%. In the current cycle the increase is 12%.
Opening this ticket to put the problem on the radar. When time permits (never enough time, I know) and/or the attack escalates please investigate an enhancement to DOS mitigation to address this issue.https://gitlab.torproject.org/tpo/core/tor/-/issues/27915Make rust doctests get linked in same way as other rust tests2020-07-28T23:11:23ZNick MathewsonMake rust doctests get linked in same way as other rust testsTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27913Add test-stem to travis-ci if possible2020-06-27T13:52:00ZNick MathewsonAdd test-stem to travis-ci if possibleTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27908PrivCount proof of concept with existing statistics2020-07-28T23:11:11ZteorPrivCount proof of concept with existing statisticsLet's implement a proof-of-concept implementation of PrivCount that adds some noise to existing relay statistics, and then aggregates them.
This proof of concept will help us answer open questions, find bugs and unexpected issues, and g...Let's implement a proof-of-concept implementation of PrivCount that adds some noise to existing relay statistics, and then aggregates them.
This proof of concept will help us answer open questions, find bugs and unexpected issues, and get started on the metrics analysis. (But it doesn't need to be secure, because the stats are already public for each relay.)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27907PrivCount config and version spec2022-06-17T18:02:05ZteorPrivCount config and version specSpecify how:
* PrivCount is configured
* How we transition between PrivCount versionsSpecify how:
* PrivCount is configured
* How we transition between PrivCount versionshttps://gitlab.torproject.org/tpo/core/tor/-/issues/27906PrivCount noise specification2022-06-17T18:02:00ZteorPrivCount noise specificationLet's write a spec for PrivCount noise:
* how noise is determined for each statistic
* how much noise each relay adds
* how to interpret the final result
* how to avoid obvious pitfallsLet's write a spec for PrivCount noise:
* how noise is determined for each statistic
* how much noise each relay adds
* how to interpret the final result
* how to avoid obvious pitfallshttps://gitlab.torproject.org/tpo/core/tor/-/issues/27901Build fails on FreeBSD/mips, but succeeds when auroreconf is run before the b...2020-07-28T23:10:39Zyurivict271Build fails on FreeBSD/mips, but succeeds when auroreconf is run before the buildDiscussion: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231779#c8Discussion: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231779#c8Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27900Please establish which C standard tor code complies with2020-06-27T13:52:00Zyurivict271Please establish which C standard tor code complies withCurrently, tor is built without the -std=xx flag, and it isn't clear what C standard is compiler expected to use.
Please add one of -std=c90, -std=c99, -std=c11, -std=c17 to compilation lines, add the corresponding macro to configure.ac...Currently, tor is built without the -std=xx flag, and it isn't clear what C standard is compiler expected to use.
Please add one of -std=c90, -std=c99, -std=c11, -std=c17 to compilation lines, add the corresponding macro to configure.ac:
> AX_CHECK_COMPILE_FLAG([-std=cNN], [CFLAGS="$CFLAGS -std=cNN"])
Reason#1: in FreeBSD we have several architectures some of which use different compilers (gcc/clang/etc) It is good to take guessing from the process and establish what standard the code complies with.
Reason#2: Some compilers might default to the older standard where a newer standard is required.
My guess is that the standard is c11.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27896base32 padding inconsistency between client and server in HS v3 client auth p...2022-06-22T15:22:37ZTracbase32 padding inconsistency between client and server in HS v3 client auth previewThere seems to be some base32 padding tolerance inconsistency between client and server for the HS v3 client auth preview in tor-0.3.5.1-alpha
The server seems to accept base32-encoded client public keys padded with = signs to 56 charac...There seems to be some base32 padding tolerance inconsistency between client and server for the HS v3 client auth preview in tor-0.3.5.1-alpha
The server seems to accept base32-encoded client public keys padded with = signs to 56 characters in length and won't work otherwise (i.e., if = signs are removed), while the client would work without the padding (i.e., = signs removed) but will ignore the client's private key if the padding is present.
I don't think this affects how the feature works (which I haven't been able to test anyway because it doesn't seem to enforce authorization at this stage - it still seems to let everyone in), but at least it seems to affect which values are valid and allowed to be loaded when reading the config.
**Trac**:
**Username**: jchevali