The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:53:33Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25981Conflicting ports cause tor to crash2020-06-27T13:53:33ZDamian JohnsonConflicting ports cause tor to crashHi Nick, here's the bug I've been nagging about on irc the last few days. :P
Recent regression is causing stem's integ tests to fail. This should be easily reproducible with tor's stem integ target (maybe we could run that prior to push...Hi Nick, here's the bug I've been nagging about on irc the last few days. :P
Recent regression is causing stem's integ tests to fail. This should be easily reproducible with tor's stem integ target (maybe we could run that prior to pushes?).
Here's a standalone repro...
```
atagar@morrigan:~/Desktop/stem$ cat ~/bad_torrc
SocksPort 1234
ControlPort 1234
atagar@morrigan:~/Desktop/stem$ tor -f ~/bad_torrc
Apr 30 11:43:32.107 [notice] Tor 0.3.4.0-alpha-dev (git-d1a0534649be02e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
Apr 30 11:43:32.107 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 30 11:43:32.107 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Apr 30 11:43:32.107 [notice] Read configuration file "/home/atagar/bad_torrc".
Apr 30 11:43:32.110 [warn] ControlPort is open, but no authentication method has been configured. This means that any program on your computer can reconfigure your Tor. That's bad! You should upgrade your Tor controller as soon as possible.
Apr 30 11:43:32.110 [notice] Scheduler type KIST has been enabled.
Apr 30 11:43:32.110 [notice] Opening Socks listener on 127.0.0.1:1234
Apr 30 11:43:32.110 [notice] Opening Control listener on 127.0.0.1:1234
Apr 30 11:43:32.110 [warn] Could not bind to 127.0.0.1:1234: Address already in use. Is Tor already running?
Apr 30 11:43:32.110 [notice] Closing partially-constructed Socks listener on 127.0.0.1:1234
Apr 30 11:43:32.110 [err] tor_assertion_failed_(): Bug: src/common/compat_libevent.c:388: mainloop_event_activate: Assertion event failed; aborting. (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: Assertion event failed in mainloop_event_activate at src/common/compat_libevent.c:388. Stack trace: (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: tor(log_backtrace+0x42) [0x55d0990d98b2] (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: tor(tor_assertion_failed_+0x8d) [0x55d0990f440d] (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: tor(mainloop_event_activate+0x5f) [0x55d09913857f] (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: tor(connection_mark_for_close_internal_+0x6c) [0x55d0990590fc] (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: tor(set_options+0x1b3) [0x55d09904d573] (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: tor(options_init_from_string+0x37e) [0x55d09904febe] (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: tor(options_init_from_torrc+0x433) [0x55d099050513] (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: tor(tor_init+0x2f0) [0x55d098faa620] (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: tor(tor_run_main+0x65) [0x55d098fab0c5] (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: tor(tor_main+0x3a) [0x55d098fa47da] (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: tor(main+0x19) [0x55d098fa4549] (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f7a12ab4830] (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Apr 30 11:43:32.111 [err] Bug: tor(_start+0x29) [0x55d098fa4599] (on Tor 0.3.4.0-alpha-dev d1a0534649be02e3)
Aborted (core dumped)
```Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25978UseEntryGuards 0 disables EntryNodes2021-07-22T16:20:51ZTracUseEntryGuards 0 disables EntryNodesUseEntryNodes {se} should allow UseEntryGuards 0
But UseEntryGuards 0 breaks UseEntryNodes unless it can find a GuardNode which is against the purpose of UseEntryNodes in TORRC.
**Trac**:
**Username**: tortracUseEntryNodes {se} should allow UseEntryGuards 0
But UseEntryGuards 0 breaks UseEntryNodes unless it can find a GuardNode which is against the purpose of UseEntryNodes in TORRC.
**Trac**:
**Username**: tortracTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25977Cross-compiling tor rust for macOS is broken2020-06-27T13:53:33ZGeorg KoppenCross-compiling tor rust for macOS is brokenUsing our cross-compile setup for compiling tor with Rust support for macOS results in a build failure. It seems the macOS cross-compile Rust support is missing:
```
CCLD src/tools/tor-resolve
/var/tmp/dist/macosx-toolchain/cctools...Using our cross-compile setup for compiling tor with Rust support for macOS results in a build failure. It seems the macOS cross-compile Rust support is missing:
```
CCLD src/tools/tor-resolve
/var/tmp/dist/macosx-toolchain/cctools/bin/x86_64-apple-darwin10-ranlib: file: src/or/libtor.a(protover.o) has no symbols
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
/var/tmp/dist/macosx-toolchain/cctools/bin/x86_64-apple-darwin10-ranlib: file: src/or/libtor-testing.a(src_or_libtor_testing_a-protover.o) has no symbols
x86_64-apple-darwin10-ranlib: file: src/or/libtor.a(protover.o) has no symbols
CCLD src/test/test-child
CCLD src/test/test-switch-id
x86_64-apple-darwin10-ranlib: file: src/or/libtor-testing.a(src_or_libtor_testing_a-protover.o) has no symbols
CCLD src/test/test-timers
CCLD src/test/test-ntor-cl
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/test-hs-ntor-cl
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/test-bt-cl
CCLD src/test/fuzz/fuzz-consensus
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/fuzz/fuzz-descriptor
CCLD src/test/fuzz/fuzz-diff
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/fuzz/fuzz-diff-apply
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/fuzz/fuzz-extrainfo
CCLD src/test/fuzz/fuzz-hsdescv2
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/fuzz/fuzz-hsdescv3
CCLD src/test/fuzz/fuzz-http
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
CCLD src/test/fuzz/fuzz-http-connect
CCLD src/test/fuzz/fuzz-iptsv2
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
ld: warning: ignoring file ./src/rust/target/release/libtor_rust.a, file was built for archive which is not the architecture being linked (x86_64)
Undefined symbols for architecture x86_64:
"_protocol_list_supports_protocol_or_later", referenced from:
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
"_protocol_list_supports_protocol", referenced from:
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
ld: symbol(s) not found for architecture x86_64
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:4715: recipe for target 'src/test/fuzz/fuzz-descriptor' failed
make[1]: *** [src/test/fuzz/fuzz-descriptor] Error 1
make[1]: *** Waiting for unfinished jobs....
Undefined symbols for architecture x86_64:
"_protocol_list_supports_protocol_or_later", referenced from:
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
"_protocol_list_supports_protocol", referenced from:
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
ld: symbol(s) not found for architecture x86_64
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:4705: recipe for target 'src/test/fuzz/fuzz-consensus' failed
make[1]: *** [src/test/fuzz/fuzz-consensus] Error 1
Undefined symbols for architecture x86_64:
"_protover_get_supported_protocols", referenced from:
_router_build_fresh_descriptor in libtor-testing.a(src_or_libtor_testing_a-router.o)
"_protocol_list_supports_protocol_or_later", referenced from:
Undefined symbols for architecture x86_64:
"_protover_get_supported_protocols", referenced from:
_router_build_fresh_descriptor in libtor-testing.a(src_or_libtor_testing_a-router.o)
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
"_protover_all_supported", referenced from:
_handle_missing_protocol_warning_impl in libtor-testing.a(src_or_libtor_testing_a-networkstatus.o)
"_protocol_list_supports_protocol_or_later", referenced from:
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
"_protocol_list_supports_protocol", referenced from:
"_protover_all_supported", referenced from:
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
_handle_missing_protocol_warning_impl in libtor-testing.a(src_or_libtor_testing_a-networkstatus.o)
"_protocol_list_supports_protocol", referenced from:
ld: symbol(s) not found for architecture x86_64
_summarize_protover_flags in libtor-testing.a(src_or_libtor_testing_a-routerparse.o)
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:4785: recipe for target 'src/test/fuzz/fuzz-http-connect' failed
make[1]: *** [src/test/fuzz/fuzz-http-connect] Error 1
ld: symbol(s) not found for architecture x86_64
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [src/test/fuzz/fuzz-http] Error 1
Makefile:4775: recipe for target 'src/test/fuzz/fuzz-http' failed
make[1]: Leaving directory '/var/tmp/build/tor-master'
make: *** [all] Error 2
```Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25976connection_dir_finished_flushing(): Bug: called in unexpected state 32022-06-17T13:25:55ZDavid Gouletdgoulet@torproject.orgconnection_dir_finished_flushing(): Bug: called in unexpected state 3This from tor version git-302908657f492f06 on one of my test relay. It was immediately followed by another BUG() below. Note that relay is still running and seems well.
Torrc has nothing special except:
```
BandwidthRate 400 KBytes
```...This from tor version git-302908657f492f06 on one of my test relay. It was immediately followed by another BUG() below. Note that relay is still running and seems well.
Torrc has nothing special except:
```
BandwidthRate 400 KBytes
```
Stacktrace:
```
Apr 29 13:30:59.691 [warn] connection_dir_finished_flushing(): Bug: called in unexpected state 3. (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.691 [warn] tor_bug_occurred_(): Bug: src/or/directory.c:5248: connection_dir_finished_flushing: This line should not have been reached. (Future instances of this warning will be silenced.) (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: Line unexpectedly reached at connection_dir_finished_flushing at src/or/directory.c:5248. Stack trace: (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(log_backtrace+0x42) [0x55811a451722] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(tor_bug_occurred_+0xb9) [0x55811a46c559] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(connection_dir_finished_flushing+0x12e) [0x55811a3fc6ee] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(+0x108fcd) [0x55811a3d5fcd] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(connection_handle_write+0x2e) [0x55811a3d67ae] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(+0x534be) [0x55811a3204be] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x819) [0x7f0f91d364c9] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(do_main_loop+0x1a5) [0x55811a3217d5] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(tor_run_main+0x275) [0x55811a322ed5] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(tor_main+0x3a) [0x55811a31c40a] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(main+0x19) [0x55811a31c179] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f0f90a48830] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(_start+0x29) [0x55811a31c1c9] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] conn_write_callback(): Bug: unhandled error on write for Directory connection (fd 1588); removing (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] tor_bug_occurred_(): Bug: src/or/main.c:935: conn_write_callback: This line should not have been reached. (Future instances of this warning will be silenced.) (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: Line unexpectedly reached at conn_write_callback at src/or/main.c:935. Stack trace: (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(log_backtrace+0x42) [0x55811a451722] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(tor_bug_occurred_+0xb9) [0x55811a46c559] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(+0x53692) [0x55811a320692] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x819) [0x7f0f91d364c9] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(do_main_loop+0x1a5) [0x55811a3217d5] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(tor_run_main+0x275) [0x55811a322ed5] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(tor_main+0x3a) [0x55811a31c40a] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(main+0x19) [0x55811a31c179] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f0f90a48830] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
Apr 29 13:30:59.731 [warn] Bug: /home/relay/tor/src/or/tor(_start+0x29) [0x55811a31c1c9] (on Tor 0.3.4.0-alpha-dev 302908657f492f06)
```https://gitlab.torproject.org/tpo/core/tor/-/issues/25967v3 onion keep working without the HiddenServiceVersion 3 line2021-09-30T13:46:30Zcypherpunksv3 onion keep working without the HiddenServiceVersion 3 lineI started by defining a v3 hidden service in torrc and running tor, thus creating a v3 private key.
Then I commented out the HiddenServiceVersion 3 line and sent the tor process a sighup using kill -HUP processid.
The v2 private key a...I started by defining a v3 hidden service in torrc and running tor, thus creating a v3 private key.
Then I commented out the HiddenServiceVersion 3 line and sent the tor process a sighup using kill -HUP processid.
The v2 private key and hostname were generated, but the v3 address kept working the v2 address did not work.
I then sent sighup again, and this time both the v2 and v3 addresses worked.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25965Document default value of Nickname parameter [patch]2021-07-22T16:20:51ZTracDocument default value of Nickname parameter [patch]While responding to an inquiry on IRC regarding [[Plinth issue #1294: tor: let the user verify if the relay is connected](https://salsa.debian.org/freedombox-team/plinth/issues/1294|Freedombox)] I was wondering what happens if the `Nickn...While responding to an inquiry on IRC regarding [[Plinth issue #1294: tor: let the user verify if the relay is connected](https://salsa.debian.org/freedombox-team/plinth/issues/1294|Freedombox)] I was wondering what happens if the `Nickname` is not set.
I had to refer to the source code to find out.
I have published a change that fixes this:
http://repo.or.cz/tor/appveyor.git/shortlog/refs/heads/default_nickname
("default_nickname" branch on http://repo.or.cz/tor/appveyor.git)
**Trac**:
**Username**: saperTor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25964Remove hs_index_t fetch, and use one of the stores instead2021-09-16T14:30:52ZteorRemove hs_index_t fetch, and use one of the stores insteadSplit off from https://trac.torproject.org/projects/tor/ticket/23094#comment:9
Replying to [legacy/trac#23094:comment:3 asn]:
> After our legacy/trac#23387 refactoring of hsdir index logic Nick suggested that we don't need to keep all 3...Split off from https://trac.torproject.org/projects/tor/ticket/23094#comment:9
Replying to [legacy/trac#23094:comment:3 asn]:
> After our legacy/trac#23387 refactoring of hsdir index logic Nick suggested that we don't need to keep all 3 around in memory, since two of them are always identical:
> https://oniongit.eu/asn/tor/merge_requests/6#note_1201
We need to:
* analyse the state machine of fetch, store_first, and store_second to make sure that fetch is always equal to store_first or store_second
* work out the condition that we can use to select betweeen store_first or store_second when we want fetch
* write a function that produces fetch from a hsdir_index_t, and use it instead of fetchhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25963Clarify the bandwidth part of dir-spec2021-09-16T14:30:52ZteorClarify the bandwidth part of dir-specPeople keep asking about the precise meaning of relay bandwidths. We should make the spec clearer:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n424
In particular:
* there is a separate limit on inbound and outbound traf...People keep asking about the precise meaning of relay bandwidths. We should make the spec clearer:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n424
In particular:
* there is a separate limit on inbound and outbound traffic
* traffic includes origin circuits and BEGINDIR requests
* let's check if traffic includes DirPort, I think it would have to
There may also be more feedback in legacy/trac#25854.
I'm tagging this fast-fix, because I can fix it fast, and it will save me time when I next explain it.https://gitlab.torproject.org/tpo/core/tor/-/issues/25957Tor 0.3.3.5-rc died: Caught signal 112020-07-28T19:04:24ZTracTor 0.3.3.5-rc died: Caught signal 11from tor.log (tor server: devuan 8A00CE9638BDB4686B91F1F0B229DB3F8C9B8415):
.../...
Apr 28 00:58:53.000 [notice] Heartbeat: Tor's uptime is 23:59 hours, with 9698 circuits open. I've sent 556.38 GB and received 553.75 GB.
Apr 28 00:58:53...from tor.log (tor server: devuan 8A00CE9638BDB4686B91F1F0B229DB3F8C9B8415):
.../...
Apr 28 00:58:53.000 [notice] Heartbeat: Tor's uptime is 23:59 hours, with 9698 circuits open. I've sent 556.38 GB and received 553.75 GB.
Apr 28 00:58:53.000 [notice] Circuit handshake stats since last time: 21677/21677 TAP, 252349/252349 NTor.
Apr 28 00:58:53.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 1 v3 connections, and 16330 v4 connections; and received 36 v1 connections, 8546 v2 connections, 13955 v3 connections, and 12846 v4 connections.
Apr 28 00:58:53.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 294 single hop clients refused.
```
============================================================ T= 1524879769
Tor 0.3.3.5-rc died: Caught signal 11
tor(+0x189059)[0x558d01f7c059]
/lib/x86_64-linux-gnu/libc.so.6(+0x791d5)[0x7f201753e1d5]
/lib/x86_64-linux-gnu/libc.so.6(+0x791d5)[0x7f201753e1d5]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f201753ff64]
/usr/local/lib/libssl.so.1.1(+0x24f40)[0x7f2018ca4f40]
/usr/local/lib/libssl.so.1.1(+0x24b25)[0x7f2018ca4b25]
/usr/local/lib/libssl.so.1.1(+0x2baec)[0x7f2018cabaec]
/usr/local/lib/libssl.so.1.1(+0x374d0)[0x7f2018cb74d0]
/usr/local/lib/libssl.so.1.1(SSL_read+0x15)[0x7f2018cb76b5]
tor(tor_tls_read+0x52)[0x558d01fae7a2]
tor(buf_read_from_tls+0xac)[0x558d01fa01dc]
tor(+0x10b9e1)[0x558d01efe9e1]
tor(+0x5367e)[0x558d01e4667e]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0)[0x7f2018f1f5a0]
tor(do_main_loop+0x264)[0x558d01e47694]
tor(tor_run_main+0x275)[0x558d01e48c95]
tor(tor_main+0x3a)[0x558d01e422aa]
tor(main+0x19)[0x558d01e42019]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f20174e52e1]
tor(_start+0x2a)[0x558d01e4206a]
```
**Trac**:
**Username**: Pine64ARMv8Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25955onion v2 deprecation plan2021-09-30T13:46:30Zcypherpunksonion v2 deprecation plancome up with a plan and timeline to deprecate onion v2 services.
This should be the meta ticket for all ticket that need to be solved before we can deprecate onion v2 services.
* What are the required milestones?
* What tools depend on...come up with a plan and timeline to deprecate onion v2 services.
This should be the meta ticket for all ticket that need to be solved before we can deprecate onion v2 services.
* What are the required milestones?
* What tools depend on onion v2 services?
(random) tentative deprecation date : 2023-12-31
maybe announce it as a tentative date so people depending on onion v2 can speak up about there needs sooner rather than later.
George Kadianakis (asn) wrote:
(https://lists.torproject.org/pipermail/tor-dev/2018-April/013107.html )
The first actual step to v2 deprecation, is to make v3 the default
version. But to get there, we first need to solve various bugs and
issues with the current v3 system (legacy/trac#25552, legacy/trac#22893, legacy/trac#23662, legacy/trac#24977,
etc.). We also need to implement various needed features, like offline
keys (legacy/trac#18098), client-authorization (legacy/trac#20700 ; WIP https://github.com/torproject/tor/pull/36),
control port commands like HSFETCH (legacy/trac#25417) and revive onionbalance for
v3. We might also want to consider possible improvements to the UX of
long onion names (like legacy/trac#24310) (https://blog.torproject.org/cooking-onions-names-your-onions).
After we do most of the above, we can turn the switch to make v3 the
default, and then we need to wait some time for most of the users to
migrate from v2 to v3. After that we can initiate the countdown, and
eventually deprecate v2s for real.
It's hard to provide an actual timeline for the above right
now. However, we are currently applying for some onion-service-related
grants, and hopefully if we get them we will have the funding to
accelerate the development pace.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25953Module: Add Travis target for modularized directory authority subsystem2021-09-16T14:30:52ZAlexander Færøyahf@torproject.orgModule: Add Travis target for modularized directory authority subsystemWe should ensure that we run a build with tor + tests with Travis where all modules are disabled to catch issues early.We should ensure that we run a build with tor + tests with Travis where all modules are disabled to catch issues early.Tor: 0.3.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25952Move check_whether_*port_reachable() to a scheduled callback, not once-per-se...2020-06-27T13:53:34ZNick MathewsonMove check_whether_*port_reachable() to a scheduled callback, not once-per-secondTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25951Run flush_pending_log_callbacks() on an as-needed basis, not once-per-second2020-06-27T13:53:34ZNick MathewsonRun flush_pending_log_callbacks() on an as-needed basis, not once-per-secondThis is likely to be trickier than a bunch of the other removals from our once-per-second code, since the logic to activate this event can happen from non-main threads.This is likely to be trickier than a bunch of the other removals from our once-per-second code, since the logic to activate this event can happen from non-main threads.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25950Run "accounting_run_housekeeping" with a periodic event.2021-09-16T14:30:52ZNick MathewsonRun "accounting_run_housekeeping" with a periodic event.Here's an implementation sketch:
* Make accounting_add_bytes() check whether limits are exceeded. Refactor the code as needed to make this check fast.
* If a limit is exceeded, schedule consider_hibernation().
* Also schedule consi...Here's an implementation sketch:
* Make accounting_add_bytes() check whether limits are exceeded. Refactor the code as needed to make this check fast.
* If a limit is exceeded, schedule consider_hibernation().
* Also schedule consider_hibernation() again based on "shutdown_time", "hibernate_end_time", and "interval_wakeup_time".
* Pull "accounting_run_housekeeping" apart:
* Other logic to set interval_end_time if it isn't set but accounting is enabled.
* A periodic event, only scheduled when network is on and accounting is enabled, to record bandwidth usage. Tie this into the or_state_save event.https://gitlab.torproject.org/tpo/core/tor/-/issues/25949Handle deferred SIGNEWNYM requests with a mainloop event2020-06-27T13:53:35ZNick MathewsonHandle deferred SIGNEWNYM requests with a mainloop eventTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25948Run or_state_save as a mainloop event2020-06-27T13:53:35ZNick MathewsonRun or_state_save as a mainloop eventTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25947Create unit test for dirserv_read_measured_bandwidths2021-02-18T15:34:40ZjugaCreate unit test for dirserv_read_measured_bandwidthsSo that we ensure that tor will still continue to read V3BandwidthsFile documents when we add new headers to it in version 1.1.0, as proposed in legacy/trac#25869So that we ensure that tor will still continue to read V3BandwidthsFile documents when we add new headers to it in version 1.1.0, as proposed in legacy/trac#25869Tor: 0.3.4.x-finaljugajugahttps://gitlab.torproject.org/tpo/core/tor/-/issues/25944Investigate and fix tortls/context_new test failure on win32 CI builds2020-06-27T13:53:35ZIsis LovecruftInvestigate and fix tortls/context_new test failure on win32 CI buildsFrom legacy/trac#25549, the `tortls/context_new` is reliably [failing](https://ci.appveyor.com/project/isislovecruft/tor/build/1.0.60/job/a0coox4l2wemeo7w#L3451). We should investigate why and fix it.From legacy/trac#25549, the `tortls/context_new` is reliably [failing](https://ci.appveyor.com/project/isislovecruft/tor/build/1.0.60/job/a0coox4l2wemeo7w#L3451). We should investigate why and fix it.https://gitlab.torproject.org/tpo/core/tor/-/issues/25943Investigate and fix tortls/x509_cert_free test failure on win32 CI builds2020-06-27T13:53:35ZIsis LovecruftInvestigate and fix tortls/x509_cert_free test failure on win32 CI buildsFrom legacy/trac#25549, the `tortls/x509_cert_free` test is [failing](https://ci.appveyor.com/project/isislovecruft/tor/build/1.0.60/job/a0coox4l2wemeo7w#L3411) with:
```
tortls/x509_cert_free: [forking]
[x509_cert_free FAILED]
```From legacy/trac#25549, the `tortls/x509_cert_free` test is [failing](https://ci.appveyor.com/project/isislovecruft/tor/build/1.0.60/job/a0coox4l2wemeo7w#L3411) with:
```
tortls/x509_cert_free: [forking]
[x509_cert_free FAILED]
```https://gitlab.torproject.org/tpo/core/tor/-/issues/25942Fix win32 test failure for crypto/openssl_version2020-06-27T13:53:35ZIsis LovecruftFix win32 test failure for crypto/openssl_versionFrom legacy/trac#25549, the `crypto/openssl_version` test [fails](https://ci.appveyor.com/project/isislovecruft/tor/build/1.0.60/job/a0coox4l2wemeo7w#L2693) on win32 builds with:
```
crypto/openssl_version: [forking] openssl version = 1...From legacy/trac#25549, the `crypto/openssl_version` test [fails](https://ci.appveyor.com/project/isislovecruft/tor/build/1.0.60/job/a0coox4l2wemeo7w#L2693) on win32 builds with:
```
crypto/openssl_version: [forking] openssl version = 1.0.2l
openssl h_version = 1.0.2n
FAIL ../src/test/test_crypto.c:156: assert(!strcmpstart(version, h_version))
[openssl_version FAILED]
```
This could possibly be an artifact of how the CI environment is set up. If so, there should be a `CI_WINDOWS` environment variable set on the machine, so we can probably just ignore this test?Tor: 0.3.4.x-final