Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:48:37Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32792Copy chutney CI diagnostics to Tor's chutney job2020-06-27T13:48:37ZteorCopy chutney CI diagnostics to Tor's chutney jobIn legacy/trac#32630, we improved chutney's CI diagnostics on failure. We should also run those diagnostics in tor's chutney CI job.In legacy/trac#32630, we improved chutney's CI diagnostics on failure. We should also run those diagnostics in tor's chutney CI job.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33131Bug: buf->datalen >= 0x7fffffff2021-01-28T18:01:38ZcypherpunksBug: buf->datalen >= 0x7fffffffWith
```
BandwidthRate
```
set greater than 2147483646 bytes, for example Config line:
```
BandwidthRate 2147483647
#same as
BandwidthRate 2 GBytes
```
no streams complete in my relay and this Bug message appears:
```
Feb 02 06:...With
```
BandwidthRate
```
set greater than 2147483646 bytes, for example Config line:
```
BandwidthRate 2147483647
#same as
BandwidthRate 2 GBytes
```
no streams complete in my relay and this Bug message appears:
```
Feb 02 06:32:37.000 [warn] {BUG} tor_bug_occurred_(): Bug: buffers_tls.c:73: buf_read_from_tls: Non-fatal assertion !(ASSERT_PREDICT
_UNLIKELY_(buf->datalen >= 0x7fffffff - at_most)) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.5 )
Feb 02 06:32:37.000 [warn] {BUG} Bug: Tor 0.4.2.5: Non-fatal assertion !(ASSERT_PREDICT_UNLIKELY_(buf->datalen >= 0x7fffffff - at_mo
st)) failed in buf_read_from_tls at buffers_tls.c:73. (Stack trace not available) (on Tor 0.4.2.5 )
```
Looks like some INT_MAX buffer count trouble to me at least.
```
# BandwidthRate BandwidthRate __N__ bytes|KBytes|MBytes|GBytes|TBytes|KBits|MBits|GBits|TBits
# A token bucket limits the average incoming bandwidth usage on this node
# to the specified number of bytes per second, and the average outgoing
# bandwidth usage to that same value. If you want to run a relay in the
# public network, this needs to be _at the very least_ 75 KBytes for a
# relay (that is, 600 kbits) or 50 KBytes for a bridge (400 kbits) -- but of
# course, more is better; we recommend at least 250 KBytes (2 mbits) if
# possible. (Default: 1 GByte) +
# +
# Note that this option, and other bandwidth-limiting options, apply to TCP
# data only: They do not count TCP headers or DNS traffic. +
# +
# With this option, and in other options that take arguments in bytes,
# KBytes, and so on, other formats are also supported. Notably, "KBytes" can
# also be written as "kilobytes" or "kb"; "MBytes" can be written as
# "megabytes" or "MB"; "kbits" can be written as "kilobits"; and so forth.
# Tor also accepts "byte" and "bit" in the singular.
# The prefixes "tera" and "T" are also recognized.
# If no units are given, we default to bytes.
# To avoid confusion, we recommend writing "bytes" or "bits" explicitly,
# since it's easy to forget that "B" means bytes, not bits.
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33195Require IPv6 tests in Travis CI2020-06-27T13:48:21ZteorRequire IPv6 tests in Travis CIWhile we're actively changing our IPv6 code, we should make sure that the macOS chutney IPv6 tests pass in Travis CI.
While I'm doing this change, I will see if there are:
* some redundant jobs I can delete, or
* some inactive areas th...While we're actively changing our IPv6 code, we should make sure that the macOS chutney IPv6 tests pass in Travis CI.
While I'm doing this change, I will see if there are:
* some redundant jobs I can delete, or
* some inactive areas that I can make fast_finish.
I think our Rust build might be a good candidate for fast_finish, we haven't changed that code much in about a year. But I should check with the team before making this change.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33212Warning in protover.rs making CI fail.2020-06-27T13:48:20ZNick MathewsonWarning in protover.rs making CI fail.It looks like a new version of Rust is warning about extraneous parentheses, causing our CI to fail in some cases. Let's fix that.
(This is possibly a duplicate, but I can't find the original.)It looks like a new version of Rust is warning about extraneous parentheses, causing our CI to fail in some cases. Let's fix that.
(This is possibly a duplicate, but I can't find the original.)Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33346Seccomp soft fail (no write) in 0.4.2.62021-01-28T17:58:13ZTracSeccomp soft fail (no write) in 0.4.2.6I've upgraded to 0.4.2.6 (as a good software user, but also because I noticed the seccomp changes).
Tor successfully starts with seccomp, but 'soft fails' because it can't write to its data directory (here: /var/lib/tor/data). Tor has p...I've upgraded to 0.4.2.6 (as a good software user, but also because I noticed the seccomp changes).
Tor successfully starts with seccomp, but 'soft fails' because it can't write to its data directory (here: /var/lib/tor/data). Tor has permissions to write to this directory - fine with Sandbox 0.
Log:
```
# cat /var/log/tor/log
Feb 16 00:46:56.000 [notice] Tor 0.4.2.6 opening new log file.
Feb 16 00:46:56.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Feb 16 00:46:57.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Feb 16 00:46:57.000 [notice] Bootstrapped 0% (starting): Starting
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-certs": Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-consensus" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/unverified-consensus" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-microdesc-consensus" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/unverified-microdesc-consensus" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-microdescs" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-microdescs.new": Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-descriptors" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [warn] Could not open "/var/lib/tor/data/cached-extrainfo" for mmap(): Operation not permitted
Feb 16 00:46:57.000 [notice] Starting with guard context "default"
Feb 16 00:46:58.000 [warn] Couldn't open "/var/lib/tor/data/state.tmp" (/var/lib/tor/data/state) for writing: Operation not permitted
Feb 16 00:46:58.000 [warn] Unable to write state to file "/var/lib/tor/data/state"; will try again later
Feb 16 00:46:58.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Feb 16 00:46:58.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Feb 16 00:46:58.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Feb 16 00:46:58.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Feb 16 00:46:58.000 [notice] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
Feb 16 00:46:58.000 [notice] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
Feb 16 00:46:58.000 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
Feb 16 00:46:59.000 [warn] Couldn't open "/var/lib/tor/data/unverified-microdesc-consensus.tmp" (/var/lib/tor/data/unverified-microdesc-consensus) for writing: Operation not permitted
Feb 16 00:46:59.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Feb 16 00:46:59.000 [notice] Bootstrapped 40% (loading_keys): Loading authority key certs
Feb 16 00:46:59.000 [warn] Couldn't open "/var/lib/tor/data/cached-certs.tmp" (/var/lib/tor/data/cached-certs) for writing: Operation not permitted
Feb 16 00:46:59.000 [warn] Error writing certificates to disk.
Feb 16 00:46:59.000 [warn] Could not open "/var/lib/tor/data/unverified-microdesc-consensus" for mmap(): Operation not permitted
Feb 16 00:46:59.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
```
#### Appendix
##### Environment
```
Tor: 0.4.2.6
OS: Gentoo arm64
Hardware: Raspberry Pi 4
Kernel: 4.19.102-v8+ (RPi base)
```
##### Other info
When running 0.4.2.5, I experienced a crash with seccomp (possibly related to legacy/trac#27315)?
```
# tor
Feb 16 00:37:42.963 [notice] Tor 0.4.2.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Feb 16 00:37:42.963 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 16 00:37:42.963 [notice] Read configuration file "/etc/tor/torrc".
Feb 16 00:37:42.966 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 16 00:37:42.966 [notice] Opened Socks listener on 127.0.0.1:9050
============================================================ T= 1581813463
(Sandbox) Caught a bad syscall attempt (syscall unlinkat)
tor(+0x1cd714)[0x5571820714]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x7f8bde0658]
/lib64/libc.so.6(unlink+0x30)[0x7f8b8058d8]
tor(run_tor_main_loop+0x74)[0x55716ae874]
tor(tor_run_main+0x11c)[0x55716aead4]
tor(tor_main+0x50)[0x55716ad458]
tor(main+0x24)[0x55716acf74]
/lib64/libc.so.6(__libc_start_main+0xe4)[0x7f8b758cac]
tor(+0x59fd0)[0x55716acfd0]
```
**Trac**:
**Username**: subjectfrostingTor: 0.3.5.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/33491tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal...2022-10-11T23:39:34ZTractor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )Hi there,
Receiving the below report, searched for 'src/core/or/dos.c:697' no hits, so opening ticket, please let me know if further info is needed to troubleshoot.
FreeBSD <<hostname>> 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC ...Hi there,
Receiving the below report, searched for 'src/core/or/dos.c:697' no hits, so opening ticket, please let me know if further info is needed to troubleshoot.
FreeBSD <<hostname>> 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64
```
Mar 1 13:53:33 <<hostname>> Tor[86742]: tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: Tor 0.4.2.6: Non-fatal assertion !(entry == NULL) failed in dos_new_client_conn at src/core/or/dos.c:697. Stack trace: (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x12f4acc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x12f0b76 <tor_bug_occurred_+0x1d6> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x118d9a5 <channel_do_open_actions+0xf5> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x118d88e <channel_change_state_open+0x2e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1191a57 <channel_tls_handle_state_change_on_orconn+0x67> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1144946 <connection_or_set_state_open+0x26> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x11923ee <channel_tls_handle_cell+0x88e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1140d52 <connection_or_process_inbuf+0x152> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x114ddad <connection_handle_read+0x8fd> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x119e3ee <connection_add_impl+0x23e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x8013d72b3 <event_base_assert_ok_nolock_+0xc23> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x8013d318f <event_base_loop+0x53f> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x11a0881 <do_main_loop+0xf1> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113de68 <tor_run_main+0x128> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113c656 <tor_main+0x66> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113c309 <main+0x19> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: Tor 0.4.2.6: Non-fatal assertion !(entry == NULL) failed in dos_new_client_conn at src/core/or/dos.c:697. Stack trace: (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x12f4acc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x12f0b76 <tor_bug_occurred_+0x1d6> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x118d9a5 <channel_do_open_actions+0xf5> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x118d88e <channel_change_state_open+0x2e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1191a57 <channel_tls_handle_state_change_on_orconn+0x67> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1144946 <connection_or_set_state_open+0x26> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x11923ee <channel_tls_handle_cell+0x88e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1140d52 <connection_or_process_inbuf+0x152> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x114ddad <connection_handle_read+0x8fd> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x119e3ee <connection_add_impl+0x23e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x8013d72b3 <event_base_assert_ok_nolock_+0xc23> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x8013d318f <event_base_loop+0x53f> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x11a0881 <do_main_loop+0xf1> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113de68 <tor_run_main+0x128> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113c656 <tor_main+0x66> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113c309 <main+0x19> at /usr/local/bin/tor (on Tor 0.4.2.6 )
```
**Trac**:
**Username**: sjcjonkerTor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33643Appveyor: OpenSSL version mismatch in unit tests, 2020 edition2020-06-27T13:48:02ZteorAppveyor: OpenSSL version mismatch in unit tests, 2020 editionIt's happened again:
```
OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
```
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380
Just like legacy/trac#32449, legacy/trac#285...It's happened again:
```
OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
```
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380
Just like legacy/trac#32449, legacy/trac#28574, legacy/trac#28399 and legacy/trac#25942.
We think our tests are fragile, because they are not copying the necessary libraries into `${env:build}/src/test` from `C:/mingw32/lib`:
```
ssl
crypto
lzma
event
zstd
```
We already copy zlib and ssp at https://github.com/ahf/tor/blob/master/.appveyor.yml#L98-L99 .
These libraries might have different dll prefixes or suffixes, for example, OpenSSL is:
```
/mingw32/bin/libcrypto-1_1.dll
/mingw32/bin/libssl-1_1.dll
```
https://packages.msys2.org/package/mingw-w64-i686-openssl
We might also want to copy these libraries into the same directory as the tor executable `${env:build}/src/app`, before we run the tests that launch tor.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33673Use the right DLLs and pkg-config path on Appveyor2020-06-27T13:48:00ZteorUse the right DLLs and pkg-config path on AppveyorWe want to future-proof our Appveyor CI against dll and pkg-config issues.
Split off from legacy/trac#33643, which is the urgent CI fix.We want to future-proof our Appveyor CI against dll and pkg-config issues.
Split off from legacy/trac#33643, which is the urgent CI fix.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34303Find out why onion service measurements have gotten slower2022-07-07T00:49:01ZKarsten LoesingFind out why onion service measurements have gotten slowerToday I changed the ["Time to download files over Tor" graph](https://metrics.torproject.org/torperf.html) to include version 3 onion service measurements.
By chance, I also looked at the [onion server measurements](https://metrics.torp...Today I changed the ["Time to download files over Tor" graph](https://metrics.torproject.org/torperf.html) to include version 3 onion service measurements.
By chance, I also looked at the [onion server measurements](https://metrics.torproject.org/torperf.html?start=2020-02-25&end=2020-05-25&server=onion&filesize=50kb) and found that the onion service measurements made by op-nl2, op-us2, and op-hk2 have gotten much slower as compared to their op-nl, op-us, and op-hk predecessors.
I'm 95% certain that this is not a bug in the graphs.
My current best guess is that something in `tor` has changed. I'd like to set up a small number of experimental OnionPerf instances all in the same place but with different `tor` versions. Any suggestions on locations (Amsterdam, Florida, Hong Kong) or `tor` versions?
This is also relevant to Sponsor 59 in order to make sure that our current measurements are going to be a baseline for future experiments. Classifying as potential defect.Tor: 0.3.5.x-finalKarsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40509relay: Stop advertising HSv2 protocol version2022-02-05T21:30:38ZDavid Gouletdgoulet@torproject.orgrelay: Stop advertising HSv2 protocol versionWe just disabled v2 in 035+ and so we should make the relays stop advertising the protocol version.
Tor clients don't use protocol versions to learn if a relay can be used for onion service v2 so this shouldn't change much. But it could...We just disabled v2 in 035+ and so we should make the relays stop advertising the protocol version.
Tor clients don't use protocol versions to learn if a relay can be used for onion service v2 so this shouldn't change much. But it could for any alt-implementation out there that uses those for v2.
Essentially, relay protocol version should be set to:
- `HSIntro=4-5` -> removing `3` which is v2 specific.
- `HSDir=2` -> removing `1` which is v2 specific.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40476hs-v2: Remove support for HSv2 on stable versions2021-10-19T15:03:12ZDavid Gouletdgoulet@torproject.orghs-v2: Remove support for HSv2 on stable versionsNow that the HSv2 has been removed from the code base in 0.4.6.x series, we now need to proceed onto the next phase which is to eliminate it from the network.
We'll do this by removing the entry points into the HSv2 code relay side so:
...Now that the HSv2 has been removed from the code base in 0.4.6.x series, we now need to proceed onto the next phase which is to eliminate it from the network.
We'll do this by removing the entry points into the HSv2 code relay side so:
- HSDir will stop accepting or serving v2 descriptors
- Introduction points wills top allowing introductions for v2.
- For Rendezvous points, we'll stop allowing it by refusing the TAP connection from the service side.
For client side:
- Disallow v2 service creation and client connections.
With these guards, we should be good with the removal of v2 in the network. We need this patch in 035 and 045 (the last two stable release we maintain with v2 support).Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40493fallbackdirs: Update list for October 2021 releases2021-11-14T12:41:19ZDavid Gouletdgoulet@torproject.orgfallbackdirs: Update list for October 2021 releasesWe are about to roll out an 0.3.5.x, 0.4.5.x, 0.4.6.x and 0.4.7.x release. This ticket is to update the lists on all maintained versions.We are about to roll out an 0.3.5.x, 0.4.5.x, 0.4.6.x and 0.4.7.x release. This ticket is to update the lists on all maintained versions.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org