The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-09T17:22:00Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24876Directory Authorities should test reachability of relays in their family2021-07-09T17:22:00ZteorDirectory Authorities should test reachability of relays in their familySebastian reported on #tor-dev that directory authorities can't set MyFamily, because it makes the relays in the family get marked as not Running.
I'm not sure if this restriction is in the connecting code on authorities or relays, or t...Sebastian reported on #tor-dev that directory authorities can't set MyFamily, because it makes the relays in the family get marked as not Running.
I'm not sure if this restriction is in the connecting code on authorities or relays, or the accepting code on relays.
If it's on the connecting side, we can disable it on authorities.
If it is in the accepting code on relays, maybe we need to keep it as a defence in depth measure. But we could disable it for authority IP addresses. (It wouldn't work with multiple authority IPs or OutboundBindAddress, but that's getting obscure.)https://gitlab.torproject.org/tpo/core/tor/-/issues/24874Running out of disk space triggers BUG(ent == NULL) at consdiffmgr.c:13162020-06-27T13:54:26ZRoger DingledineRunning out of disk space triggers BUG(ent == NULL) at consdiffmgr.c:1316```
Jan 11 03:30:10.350 [warn] Error writing to "freeBogatov/diff-cache/1090": No space left on device
Jan 11 03:30:10.350 [warn] tor_bug_occurred_(): Bug: src/or/consdiffmgr.c:1316: store_multiple: Non-fatal assertion !(ent == NULL) fai...```
Jan 11 03:30:10.350 [warn] Error writing to "freeBogatov/diff-cache/1090": No space left on device
Jan 11 03:30:10.350 [warn] tor_bug_occurred_(): Bug: src/or/consdiffmgr.c:1316: store_multiple: Non-fatal assertion !(ent == NULL) failed. (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.397 [warn] Bug: Non-fatal assertion !(ent == NULL) failed in store_multiple at src/or/consdiffmgr.c:1316. Stack trace: (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(log_backtrace+0x42) [0x7f8075292e82] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(tor_bug_occurred_+0xca) [0x7f80752ae21a] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(+0x11b718) [0x7f8075223718] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(+0x11b9cd) [0x7f80752239cd] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(replyqueue_process+0x52) [0x7f80752b1272] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(+0x2014f4) [0x7f80753094f4] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(+0x201805) [0x7f8075309805] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.397 [warn] Bug: ../tor/src/or/tor(+0x201e95) [0x7f8075309e95] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.408 [warn] Bug: ../tor/src/or/tor(event_base_loop+0x2c8) [0x7f807530a5f9] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.408 [warn] Bug: ../tor/src/or/tor(do_main_loop+0x41b) [0x7f807515aa8b] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.408 [warn] Bug: ../tor/src/or/tor(tor_run_main+0x28b) [0x7f807515b06b] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.408 [warn] Bug: ../tor/src/or/tor(tor_main+0x43) [0x7f8075155953] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.408 [warn] Bug: ../tor/src/or/tor(main+0x19) [0x7f80751557e9] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.408 [warn] Bug: /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f8073c78d1d] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
Jan 11 03:30:10.408 [warn] Bug: ../tor/src/or/tor(+0x4d6f9) [0x7f80751556f9] (on Tor 0.3.3.0-alpha-dev 943134e886d9cef2)
```
I hit the bug on master, but it looks like it is present in 0.3.2 and 0.3.1 as well.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24868Check a consensus parameter before activating onion service IPv6 features2021-09-30T13:50:08ZteorCheck a consensus parameter before activating onion service IPv6 featuresWe've implemented legacy/trac#23577, but it looks like none of the other onion service IPv6 code will be ready for 0.3.3.
(We want to do the relay IPv6 code first.)
If we merge this in 0.3.3, then services will be able to distinguish 0...We've implemented legacy/trac#23577, but it looks like none of the other onion service IPv6 code will be ready for 0.3.3.
(We want to do the relay IPv6 code first.)
If we merge this in 0.3.3, then services will be able to distinguish 0.3.2 and 0.3.3 (and later) clients, when the rend point is dual-stack.
Do we want to add a torrc option / consensus parameter for v3 onion service IPv6? Or are we happy with this information leak?Tor: unspecifiedteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24867Do relays keep more than one canonical connection when they extend over IPv6?2020-07-28T16:38:02ZteorDo relays keep more than one canonical connection when they extend over IPv6?We should find out, and fix any issues.
The warnings would look something like legacy/trac#24841.We should find out, and fix any issues.
The warnings would look something like legacy/trac#24841.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24864directory authorities take a while to update relays' Tor versions because the...2020-07-28T16:39:02Zcypherpunksdirectory authorities take a while to update relays' Tor versions because they use old descriptors for votescopy from
https://lists.torproject.org/pipermail/tor-dev/2018-January/012786.html
Hi,
the goal of this email is to avoid a false positive warning for relay operators
on atlas but the root cause might be in core tor.
background:
I re...copy from
https://lists.torproject.org/pipermail/tor-dev/2018-January/012786.html
Hi,
the goal of this email is to avoid a false positive warning for relay operators
on atlas but the root cause might be in core tor.
background:
I really liked when irl added the big red warning to atlas when a tor relay
runs an outdated (aka not running a "recommended") tor version
because it actually triggered operators to upgrade, an important step toward a more healthy network.
The problem is: This big red banner on atlas has false-positives which confuses operators [0].
Originally this has been an onionoo bug which
has been fixed in v1.8.0, but it happens again and Karsten had the feeling
that tor dir auths do not update the version information of a relay after it
upgraded (and uploaded a new descriptor). I looked into one example and can confirm what Karsten suggested [1].
Let me show you that example of FP 1283EBDEEC2B9D745F1E7FBE83407655B984FD66.
Data has been provided by Karsten and is available here: [2].
That relay was running 0.3.0.10 and upgraded to 0.3.0.13 and uploaded his first
descriptor with 0.3.0.13 on:
```
2018-01-09 10:14:00,server,,0.3.0.13
```
except for bastet dir auths did not care and still said this relay runs
0.3.0.10:
```
2018-01-09 11:00:00,consensus,,0.3.0.10
2018-01-09 11:00:00,vote,bastet,0.3.0.13 <<<< note
2018-01-09 11:00:00,vote,dannenberg,0.3.0.10
2018-01-09 11:00:00,vote,dizum,0.3.0.10
2018-01-09 11:00:00,vote,Faravahar,0.3.0.10
2018-01-09 11:00:00,vote,gabelmoo,0.3.0.10
2018-01-09 11:00:00,vote,longclaw,0.3.0.10
2018-01-09 11:00:00,vote,maatuska,0.3.0.10
2018-01-09 11:00:00,vote,moria1,0.3.0.10
2018-01-09 11:00:00,vote,tor26,0.3.0.10
2018-01-09 12:00:00,consensus,,0.3.0.10
2018-01-09 12:00:00,vote,bastet,0.3.0.13 <<<<<<
2018-01-09 12:00:00,vote,dannenberg,0.3.0.10
2018-01-09 12:00:00,vote,dizum,0.3.0.10
2018-01-09 12:00:00,vote,Faravahar,0.3.0.10
2018-01-09 12:00:00,vote,gabelmoo,0.3.0.10
2018-01-09 12:00:00,vote,longclaw,0.3.0.10
2018-01-09 12:00:00,vote,maatuska,0.3.0.10
2018-01-09 12:00:00,vote,moria1,0.3.0.10
2018-01-09 12:00:00,vote,tor26,0.3.0.10
```
even 6 hours later this is unchanged.
Then the operator upgraded from 0.3.0.13 to 0.3.1.9
and uploaded his first descriptor:
```
2018-01-09 16:39:01,server,,0.3.1.9
```
this remained "unnoticed" by all dir auths until
longclaw voted for the new version:
```
2018-01-09 23:00:00,consensus,,0.3.0.10
2018-01-09 23:00:00,vote,bastet,0.3.0.10
2018-01-09 23:00:00,vote,dannenberg,0.3.0.10
2018-01-09 23:00:00,vote,dizum,0.3.0.10
2018-01-09 23:00:00,vote,Faravahar,0.3.0.10
2018-01-09 23:00:00,vote,gabelmoo,0.3.0.10
2018-01-09 23:00:00,vote,longclaw,0.3.1.9 <<<<<
2018-01-09 23:00:00,vote,maatuska,0.3.0.10
2018-01-09 23:00:00,vote,moria1,0.3.0.10
2018-01-09 23:00:00,vote,tor26,0.3.0.10
```
On 2018-01-10 02:38:07 the relay uploaded a second descriptor with
v0.3.1.9 and almost all dir auths agreed immediately:
```
2018-01-10 02:38:07,server,,0.3.1.9
2018-01-10 03:00:00,consensus,,0.3.1.9
2018-01-10 03:00:00,vote,bastet,0.3.0.10
2018-01-10 03:00:00,vote,dannenberg,0.3.1.9
2018-01-10 03:00:00,vote,dizum,0.3.1.9
2018-01-10 03:00:00,vote,Faravahar,0.3.1.9
2018-01-10 03:00:00,vote,gabelmoo,0.3.1.9
2018-01-10 03:00:00,vote,longclaw,0.3.1.9
2018-01-10 03:00:00,vote,maatuska,0.3.1.9
2018-01-10 03:00:00,vote,moria1,0.3.1.9
2018-01-10 03:00:00,vote,tor26,0.3.1.9
```
So it took the operator 17 hours to convince enough
dir auths that he upgraded.
I can see multiple reasons why this can make sense (as the tor version
is actually not that relevant consensus data) but maybe it was
not clear what the side effects of not updating that field are.
While I believe there is still another onionoo issue,
this should also be improved.
Thoughts?
[0] http://lists.nycbug.org/pipermail/tor-bsd/2018-January/000620.html
[1] https://trac.torproject.org/projects/tor/ticket/22488#comment:11
[2] https://trac.torproject.org/projects/tor/attachment/ticket/22488/task-22488-relay-versions.csv.gz
legacy/trac#24862 aims to help track and debug this.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24863Travis CI environment change breaks clang builds2020-06-27T13:54:27ZTaylor YuTravis CI environment change breaks clang buildsIt looks like an unannounced environment change in Travis CI's workers prevents LeakSanitizer from working correctly, breaking our Travis builds on clang. This seems to disable ptrace capabilities, which for some reason LeakSanitizer ne...It looks like an unannounced environment change in Travis CI's workers prevents LeakSanitizer from working correctly, breaking our Travis builds on clang. This seems to disable ptrace capabilities, which for some reason LeakSanitizer needs to run properly on our forking tests. (See https://github.com/travis-ci/travis-ci/issues/9033).
We can hope they fix this soon, or we can try to work around it by changing our `.travis.yml` to use a sudo-enabled build environment. (This has the drawback that some of our tests depend on running as non-root, but I think they all get skipped if running as root.)Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24861Using %zu seems to break mingw :/2020-06-27T13:54:27ZNick MathewsonUsing %zu seems to break mingw :/It looks like we found out why we weren't using `%zu` before:
```
17:55:39 In file included from src/or/or.h:72:0,
17:55:39 from src/or/circuitlist.c:54:
17:55:39 src/or/circuitlist.c: In function 'circuits_handle_oom':
...It looks like we found out why we weren't using `%zu` before:
```
17:55:39 In file included from src/or/or.h:72:0,
17:55:39 from src/or/circuitlist.c:54:
17:55:39 src/or/circuitlist.c: In function 'circuits_handle_oom':
17:55:39 src/or/circuitlist.c:2407:26: error: unknown conversion type character 'z' in format [-Werror=format=]
17:55:39 log_notice(LD_GENERAL, "We're low on memory (cell queues total alloc: %zu,"
17:55:39 ^
17:55:39 ./src/common/torlog.h:232:45: note: in definition of macro 'log_notice'
17:55:39 log_fn_(LOG_NOTICE, domain, __FUNCTION__, args, ##__VA_ARGS__)
17:55:39 ^~~~
17:55:39 src/or/circuitlist.c:2407:26: error: unknown conversion type character 'z' in format [-Werror=format=]
17:55:39 log_notice(LD_GENERAL, "We're low on memory (cell queues total alloc: %zu,"
17:55:39 ^
```
(from https://jenkins.torproject.org/job/tor-ci-mingwcross-master/1577/ARCHITECTURE=amd64,SUITE=stretch/consoleFull)
In theory we can select a more c99 one with `__USE_MINGW_ANSI_STDIO`, but that would change our stdio everywhere. (Which is a little scary.)
We could also define a PRIsz macro that has the correct format for whatever compiler we are using. That might be a better choice.Tor: 0.3.3.x-finalffmanceraffmancerahttps://gitlab.torproject.org/tpo/core/tor/-/issues/24860Bug: Assertion cmux failed in circuitmux_get_policy at src/or/circuitmux.c2020-06-27T13:54:27ZDavid Gouletdgoulet@torproject.orgBug: Assertion cmux failed in circuitmux_get_policy at src/or/circuitmux.cThis was triggered during an heavy load on my relay for which all the RAM and disk space has been consumed:
```
Dec 15 20:44:20.612 [err] tor_assertion_failed_(): Bug: src/or/circuitmux.c:630: circuitmux_get_policy: Assertion cmux faile...This was triggered during an heavy load on my relay for which all the RAM and disk space has been consumed:
```
Dec 15 20:44:20.612 [err] tor_assertion_failed_(): Bug: src/or/circuitmux.c:630: circuitmux_get_policy: Assertion cmux failed; aborting. (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: Assertion cmux failed in circuitmux_get_policy at src/or/circuitmux.c:630. Stack trace: (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(log_backtrace+0x42) [0x55cac920c342] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(tor_assertion_failed_+0x8d) [0x55cac922768d] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(circuitmux_get_policy+0x57) [0x55cac9167d57] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(+0xb7f41) [0x55cac913ff41] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(smartlist_pqueue_pop+0x156) [0x55cac9217196] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(+0xb9d7e) [0x55cac9141d7e] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(+0xb805f) [0x55cac914005f] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x819) [0x7f38ac2544c9] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(do_main_loop+0x24f) [0x55cac90db53f] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(tor_run_main+0x265) [0x55cac90dc9c5] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(tor_main+0x3a) [0x55cac90d621a] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(main+0x19) [0x55cac90d5f89] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f38aaf6d830] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
Dec 15 20:44:20.678 [err] Bug: /home/relay/tor/src/or/tor(_start+0x29) [0x55cac90d5fd9] (on Tor 0.3.3.0-alpha-dev b1682551a6860a2b)
```Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24859Bug: Non-fatal assertion !(ent == NULL) failed in store_multiple at src/or/co...2020-06-27T13:54:27ZDavid Gouletdgoulet@torproject.orgBug: Non-fatal assertion !(ent == NULL) failed in store_multiple at src/or/consdiffmgr.cDuring an heavy DoS on my relay, it ran out of RAM and disk space which I believe might have triggered this assert:
```
Dec 16 17:37:47.562 [warn] Error writing to "/home/tor/diff-cache/1224": Disk quota exceeded
Dec 16 17:37:47.562 [wa...During an heavy DoS on my relay, it ran out of RAM and disk space which I believe might have triggered this assert:
```
Dec 16 17:37:47.562 [warn] Error writing to "/home/tor/diff-cache/1224": Disk quota exceeded
Dec 16 17:37:47.562 [warn] tor_bug_occurred_(): Bug: src/or/consdiffmgr.c:1316: store_multiple: Non-fatal assertion !(ent == NULL) failed. (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
Dec 16 17:37:47.563 [warn] Bug: Non-fatal assertion !(ent == NULL) failed in store_multiple at src/or/consdiffmgr.c:1316. Stack trace: (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(log_backtrace+0x42) [0x55994d4a8382] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(tor_bug_occurred_+0xb9) [0x55994d4c3619] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(+0x11a0c2) [0x55994d43e0c2] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(+0x11a7de) [0x55994d43e7de] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(replyqueue_process+0x51) [0x55994d4ca3c1] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
Dec 16 17:37:47.563 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x819) [0x7f800d7404c9] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(do_main_loop+0x24f) [0x55994d37726f] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(tor_run_main+0x265) [0x55994d3786f5] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(tor_main+0x3a) [0x55994d371f4a] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(main+0x19) [0x55994d371cb9] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
Dec 16 17:37:47.563 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f800c65f830] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
Dec 16 17:37:47.563 [warn] Bug: /root/git/tor/src/or/tor(_start+0x29) [0x55994d371d09] (on Tor 0.3.3.0-alpha-dev 424572ee0a161428)
```Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24857Tor uses 100% CPU when accessing the cache directory on Windows2022-03-16T17:59:01ZTracTor uses 100% CPU when accessing the cache directory on WindowsHi,
I have tor 0.3.1.9 running as non-exit relay.
From time to time it starts consuming 100% of CPU. Even though network traffic is minimal.
Is it normal? If not, how can I help you to investigate it?
My system is Win 7 x64 SP1, cpu i...Hi,
I have tor 0.3.1.9 running as non-exit relay.
From time to time it starts consuming 100% of CPU. Even though network traffic is minimal.
Is it normal? If not, how can I help you to investigate it?
My system is Win 7 x64 SP1, cpu is Core i5-3570.
**Trac**:
**Username**: Eugene646Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24854Extract the authority list from config.c2020-07-28T16:25:42ZteorExtract the authority list from config.cThere is a list of default_authorities in src/or/config.c.
We want it in a separate file at src/or/auth_dirs.inc.
This should be implemented like the default_fallbacks array, which includes the fallback list from src/or/fallback_dirs.in...There is a list of default_authorities in src/or/config.c.
We want it in a separate file at src/or/auth_dirs.inc.
This should be implemented like the default_fallbacks array, which includes the fallback list from src/or/fallback_dirs.inc.
We will need to implement two branches for backporting:
* a branch on maint-0.2.9 for 0.2.9 and later. It has IPv6 addresses.
* ~~a branch on maint-0.2.5 for 0.2.5. It has no IPv6 addresses.~~
(Then, after we have moved it into a separate file, we want to automatically generate the file, in a new format. See the rest of the children of legacy/trac#24818.)Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24853backport the new authority and fallback file formats2020-07-28T16:30:39Zteorbackport the new authority and fallback file formatsAfter doing legacy/trac#24851 and legacy/trac#24852.
* backport them to all supported tor releases:
* authorities: ~~0.2.5 (EOL 1 May 2018),~~ 0.2.9, ~~0.3.0 (EOL 1 Feb 2018),~~ 0.3.1, 0.3.2, 0.3.3
* fallbacks: 0.2.9, ~~0.3.0 (EOL 1 ...After doing legacy/trac#24851 and legacy/trac#24852.
* backport them to all supported tor releases:
* authorities: ~~0.2.5 (EOL 1 May 2018),~~ 0.2.9, ~~0.3.0 (EOL 1 Feb 2018),~~ 0.3.1, 0.3.2, 0.3.3
* fallbacks: 0.2.9, ~~0.3.0 (EOL 1 Feb 2018),~~ 0.3.1, 0.3.2, 0.3.3
* make sure all supported tor releases parse the files correctly (unit tests)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24852update the fallback script to generate the new format2020-08-17T14:21:27Zteorupdate the fallback script to generate the new format* increment the version
* modify the structure of the current list, but not the content
* check that all supported Tor versions (0.2.9 and later) can parse the list (existing unit tests)* increment the version
* modify the structure of the current list, but not the content
* check that all supported Tor versions (0.2.9 and later) can parse the list (existing unit tests)https://gitlab.torproject.org/tpo/core/tor/-/issues/24850tor2web option without the corresponding tag in torrc causes tor to fail with...2020-07-28T16:30:12Zyurivict271tor2web option without the corresponding tag in torrc causes tor to fail with confusing console outputThe log file explains it:
```
Jan 09 17:12:29.000 [warn] This copy of Tor was compiled or configured to run in a non-anonymous mode. It will provide NO ANONYMITY.
Jan 09 17:12:29.000 [err] This copy of Tor was compiled to run in 'tor2web...The log file explains it:
```
Jan 09 17:12:29.000 [warn] This copy of Tor was compiled or configured to run in a non-anonymous mode. It will provide NO ANONYMITY.
Jan 09 17:12:29.000 [err] This copy of Tor was compiled to run in 'tor2web mode'. It can only be run with the Tor2webMode torrc option enabled.
Jan 09 17:12:29.000 [err] set_options: Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.3.2.9 9e8b762fcecfece6)
```
But the console output looks like it fails for no reason:
```
Starting tor.
Jan 09 17:12:29.178 [notice] Tor 0.3.2.9 (git-9e8b762fcecfece6) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL 1.0.2n, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd 1.3.3.
Jan 09 17:12:29.178 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jan 09 17:12:29.178 [notice] Read configuration file "/usr/local/etc/tor/torrc".
Jan 09 17:12:29.187 [notice] Scheduler type KISTLite has been enabled.
Jan 09 17:12:29.187 [notice] Opening Socks listener on 127.0.0.1:9050
/usr/local/etc/rc.d/tor: WARNING: failed to start tor
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24849Added -1 signatures to consensus2022-10-11T23:40:03ZteorAdded -1 signatures to consensusThis line is also in the logs from legacy/trac#24815.
```
Jan 09 08:57:32.637 [info] dirvote_add_signatures_to_pending_consensus: Added -1 signatures to consensus.
```This line is also in the logs from legacy/trac#24815.
```
Jan 09 08:57:32.637 [info] dirvote_add_signatures_to_pending_consensus: Added -1 signatures to consensus.
```Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24847Merge HS v3 prop284 into control-spec.txt2020-06-27T13:54:28ZDavid Gouletdgoulet@torproject.orgMerge HS v3 prop284 into control-spec.txtProposal 284 has now been merged, it needs to be put in the control-spec.txt.Proposal 284 has now been merged, it needs to be put in the control-spec.txt.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24844Add HS v3 status to the SIGUSR1 dumpstats()2020-06-27T13:54:29ZDavid Gouletdgoulet@torproject.orgAdd HS v3 status to the SIGUSR1 dumpstats()Only v2 is supported with `rend_service_dump_stats()`. Would be nice to have one for v3 as well.Only v2 is supported with `rend_service_dump_stats()`. Would be nice to have one for v3 as well.Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24841Your relay has a very large number of connections to other relays. Is your ou...2020-06-27T13:54:29ZTracYour relay has a very large number of connections to other relays. Is your outbound address the same as your relay address?debian-tor-0.3.2.8-rc-1
SOCKSPort 9050
ORPort 80.67.176.53:9001
ORPort [2001:910:1035::1]:9001
ExitRelay 0
https://atlas.torproject.org/#details/A2547D13A3659ECF23AF8B9456B2E277110BF136
```
janv. 08 20:41:35 alex Tor[21674]: Tor 0.3.2...debian-tor-0.3.2.8-rc-1
SOCKSPort 9050
ORPort 80.67.176.53:9001
ORPort [2001:910:1035::1]:9001
ExitRelay 0
https://atlas.torproject.org/#details/A2547D13A3659ECF23AF8B9456B2E277110BF136
```
janv. 08 20:41:35 alex Tor[21674]: Tor 0.3.2.8-rc (git-3696eb720795a666) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.0g, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.3.3.
janv. 08 20:41:35 alex Tor[21674]: Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
janv. 08 20:41:35 alex Tor[21674]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
janv. 08 20:41:35 alex Tor[21674]: Read configuration file "/etc/tor/torrc".
janv. 08 20:41:35 alex Tor[21674]: Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
janv. 08 20:41:35 alex Tor[21674]: Scheduler type KIST has been enabled.
janv. 08 20:41:35 alex Tor[21674]: Opening Socks listener on 127.0.0.1:9050
janv. 08 20:41:35 alex Tor[21674]: Opening OR listener on 80.67.176.53:9001
janv. 08 20:41:35 alex Tor[21674]: Opening OR listener on [2001:910:1035::1]:9001
janv. 08 20:41:35 alex Tor[21674]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
janv. 08 20:41:35 alex Tor[21674]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
janv. 08 20:41:35 alex Tor[21674]: Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
janv. 08 20:41:35 alex Tor[21674]: Your Tor server's identity key fingerprint is 'tyng A2547D13A3659ECF23AF8B9456B2E277110BF136'
janv. 08 20:41:35 alex Tor[21674]: Bootstrapped 0%: Starting
janv. 08 20:41:38 alex Tor[21674]: Starting with guard context "default"
janv. 08 20:41:38 alex Tor[21674]: Bootstrapped 80%: Connecting to the Tor network
janv. 08 20:41:38 alex Tor[21674]: Signaled readiness to systemd
janv. 08 20:41:38 alex Tor[21674]: Opening Control listener on /var/run/tor/control
janv. 08 20:41:39 alex Tor[21674]: Bootstrapped 85%: Finishing handshake with first hop
janv. 08 20:41:39 alex Tor[21674]: Bootstrapped 90%: Establishing a Tor circuit
janv. 08 20:41:42 alex Tor[21674]: Tor has successfully opened a circuit. Looks like client functionality is working.
janv. 08 20:41:42 alex Tor[21674]: Bootstrapped 100%: Done
janv. 08 20:41:42 alex Tor[21674]: Now checking whether ORPort 80.67.176.53:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
janv. 08 20:41:43 alex Tor[21674]: Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
janv. 08 20:42:41 alex Tor[21674]: Performing bandwidth self-test...done.
janv. 08 23:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 11 connections to 7 relays. Found 11 current canonical connections, in 0 of which we were a non-canonical peer. 4 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 02:41:38 alex Tor[21674]: Heartbeat: Tor's uptime is 5:59 hours, with 2 circuits open. I've sent 4.61 MB and received 16.47 MB.
janv. 09 02:41:38 alex Tor[21674]: Circuit handshake stats since last time: 0/0 TAP, 5/5 NTor.
janv. 09 02:41:38 alex Tor[21674]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 2 v4 connections; and received 0 v1 connections, 0 v2 connections, 1 v3 connections, and 37 v4 connections.
janv. 09 02:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 14 connections to 9 relays. Found 14 current canonical connections, in 0 of which we were a non-canonical peer. 5 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 04:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 15 connections to 10 relays. Found 15 current canonical connections, in 0 of which we were a non-canonical peer. 5 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 05:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 11 connections to 7 relays. Found 11 current canonical connections, in 0 of which we were a non-canonical peer. 4 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 06:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 9 connections to 6 relays. Found 9 current canonical connections, in 0 of which we were a non-canonical peer. 3 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 08:41:38 alex Tor[21674]: Heartbeat: Tor's uptime is 11:59 hours, with 0 circuits open. I've sent 8.13 MB and received 24.95 MB.
janv. 09 08:41:38 alex Tor[21674]: Average packaged cell fullness: 93.781%. TLS write overhead: 16%
janv. 09 08:41:38 alex Tor[21674]: Circuit handshake stats since last time: 0/0 TAP, 1/1 NTor.
janv. 09 08:41:38 alex Tor[21674]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 4 v4 connections; and received 0 v1 connections, 0 v2 connections, 4 v3 connections, and 74 v4 connections.
```
**Trac**:
**Username**: tyngTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24840Hidden service xxx exceeded launch limit with 10 intro points in the last 35 ...2020-06-27T13:54:29ZTracHidden service xxx exceeded launch limit with 10 intro points in the last 35 seconds. Intro circuit launches are limited to 10 per 300 secondsI've checked this ticket: https://trac.torproject.org/projects/tor/ticket/22159
It marked fixed at branch 0.3.1, My tor version is 0.3.2.6-alpha-dev.
It looks like there's still a problem.
This the log:
Jan 09 10:51:21.015 [notice] Tor ...I've checked this ticket: https://trac.torproject.org/projects/tor/ticket/22159
It marked fixed at branch 0.3.1, My tor version is 0.3.2.6-alpha-dev.
It looks like there's still a problem.
This the log:
Jan 09 10:51:21.015 [notice] Tor 0.3.2.6-alpha-dev running on Windows 7 [server] with Libevent 2.1.5-beta, OpenSSL 1.0.1s, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
...
Jan 09 10:51:21.031 [notice] Opening Socks listener on 127.0.0.1:9050
Jan 09 10:51:21.000 [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.
Jan 09 10:51:22.000 [notice] Bootstrapped 0%: Starting
Jan 09 10:51:24.000 [notice] Starting with guard context "default"
Jan 09 10:51:24.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Jan 09 10:51:28.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Jan 09 10:51:30.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Jan 09 10:51:30.000 [warn] Your Guard radia4 ($xxxxxxxx) is failing an extremely large amount of circuits. This could indicate a route manipulation attack, extreme network overload, or a bug. Success counts are 37/297. Use counts are 76/83. 250 circuits completed, 1 were unusable, 213 collapsed, and 2 timed out. For reference, your timeout cutoff is 60 seconds.
Jan 09 10:51:31.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jan 09 10:51:31.000 [notice] Bootstrapped 100%: Done
Jan 09 10:51:56.000 [warn] Hidden service xxxxxxx exceeded launch limit with 10 intro points in the last 35 seconds. Intro circuit launches are limited to 10 per 300 seconds.
Jan 09 10:51:56.000 [warn] Service configured in "D:\\xxxxx\\Data":
Jan 09 10:51:56.000 [warn] Intro point 0 at [scrubbed]: circuit is open
Jan 09 10:51:56.000 [warn] Intro point 1 at [scrubbed]: circuit is connecting to server
Jan 09 10:51:56.000 [warn] Intro point 2 at [scrubbed]: circuit is connecting to server
I can't run for a long time on the same server?
Thanks
**Trac**:
**Username**: sx5486510Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24839Add a torrc option and descriptor line to opt-in as a FallbackDir2022-03-22T13:28:46ZteorAdd a torrc option and descriptor line to opt-in as a FallbackDirThis needs:
* a proposal and a design
* a patch to dir-spec.txt
* a patch to the tor man page
* a tor code patch
* an updateFallbackDirs.py code patch
* a wiki update to [[doc/UpdatingFallbackDirectoryMirrors]]
Here's a quick sketch of ...This needs:
* a proposal and a design
* a patch to dir-spec.txt
* a patch to the tor man page
* a tor code patch
* an updateFallbackDirs.py code patch
* a wiki update to [[doc/UpdatingFallbackDirectoryMirrors]]
Here's a quick sketch of a design:
1. Relay operators set `OfferFallbackDir 1` to offer their relay as a potential FallbackDir.
2. Relays with this option set put `offer-fallback-dir` in their descriptors
3. updateFallbackDirs.py loads relay fingerprints with `offer-fallback-dir`, and from the legacy offer list
4. updateFallbackDirs.py does stability checks, and generates the fallback list