Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-03-22T13:18:53Zhttps://gitlab.torproject.org/legacy/trac/-/issues/24378Prune the list of supported consensus methods2022-03-22T13:18:53ZteorPrune the list of supported consensus methodsWe currently have 13 supported consensus methods.
In 0.3.3, it is likely that prop282 will add 1 more, and prop283 will add 2 more.
Maybe we should prune this list eventually, because it will let us simplify our code, and make votes sm...We currently have 13 supported consensus methods.
In 0.3.3, it is likely that prop282 will add 1 more, and prop283 will add 2 more.
Maybe we should prune this list eventually, because it will let us simplify our code, and make votes smaller, less expensive to calculate, and reduce authority RAM requirements (due to fewer microdescs).
It has almost no impact on consensus size.
Here's how we could work out what to prune:
By mandatory feature:
We are currently locked into using consensus method 16 or later in the public network, because 0.2.9 and later require ntor keys, and 0.2.9 clients use microdescriptors by default.
We may add more mandatory features in 0.3.3 and 0.3.4.
By supported tor version:
On May 1, 2018, we will stop supporting 0.2.5, and only support 0.2.9 and later. This means that all supported non-alpha versions will support consensus methods 25 and later. (Or, if we count 0.2.9 alpha versions, it's 22 and later.)Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/25573Track half-closed stream IDs2022-03-22T13:18:09ZMike PerryTrack half-closed stream IDsIn order to eliminate a side channel attack described in https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf ("DropMark" attack) we need a way to determine if a stream id is invalid.
Many clients (particularly Firefox...In order to eliminate a side channel attack described in https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf ("DropMark" attack) we need a way to determine if a stream id is invalid.
Many clients (particularly Firefox) will hang up on streams that still have data in flight. In this case, Tor clients send RELAY_COMMAND_END when they are done with a stream, and immediately remove that stream ID from their valid stream mapping. The remaining application data continues to arrive, but is silently dropped by the Tor client. The result is that this ignored stream data currently can't be distinguished from injected dummy traffic with completely random stream IDs, and this fact can be used to mount side channel attacks.
A similar situation exists for spurious RELAY_ENDs.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28717Tor stuck in 25% Loading networkstatus consensus2021-03-27T04:55:11ZTracTor stuck in 25% Loading networkstatus consensusI installed the Tor Bridge. When launched, it gets stuck:
```
Dec 04 10:42:33.943 [notice] Tor 0.3.4.9 running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.8.2, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
Dec 04 10:42:33.944 [n...I installed the Tor Bridge. When launched, it gets stuck:
```
Dec 04 10:42:33.943 [notice] Tor 0.3.4.9 running on Linux with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.8.2, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
Dec 04 10:42:33.944 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 04 10:42:33.944 [notice] Read configuration file "/etc/tor/torrc".
Dec 04 10:42:33.947 [notice] Scheduler type KIST has been enabled.
Dec 04 10:42:33.947 [notice] Opening Socks listener on 127.0.0.1:9050
Dec 04 10:42:33.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
Dec 04 10:42:34.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
Dec 04 10:42:34.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.
Dec 04 10:42:34.000 [notice] Bootstrapped 0%: Starting
Dec 04 10:42:34.000 [notice] Starting with guard context "bridges"
Dec 04 10:42:34.000 [notice] new bridge descriptor 'huy' (cached): $3E0CFCEE7183970DCC70ABC2D10518BC288BF0DE~huy at 79.103.124.21
Dec 04 10:42:34.000 [notice] Delaying directory fetches: Pluggable transport proxies still configuring
Dec 04 10:42:35.000 [notice] Bootstrapped 5%: Connecting to directory server
Dec 04 10:42:35.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Dec 04 10:42:35.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection
Dec 04 10:42:35.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus
Dec 04 10:42:35.000 [notice] Bootstrapped 25%: Loading networkstatus consensus
Dec 04 10:47:39.000 [notice] Delaying directory fetches: No running bridges
```
My ISP does not block Tor. This problem does not depend on the country, because I tested the Tor client with my bridge in Russia, Germany and the Netherlands. The same problem occurs without using obfs4proxy. I think that in this case it has nothing to do with the time zone.
**Trac**:
**Username**: loskiqTor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25977Cross-compiling tor rust for macOS is broken2020-06-16T00:46:42ZGeorg 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/legacy/trac/-/issues/25895Cross-compiling tor rust for Windows is broken2020-06-16T00:46:29ZGeorg KoppenCross-compiling tor rust for Windows is brokenI managed to cross-compile at least a rust compiler for 64bit Windows but tor is not prepared for that:
```
x86_64-w64-mingw32-gcc -mwindows -fstack-protector-all -Wstack-protector --param ssp-buffer-size=4 -fno-strict-overflow -Wno-mis...I managed to cross-compile at least a rust compiler for 64bit Windows but tor is not prepared for that:
```
x86_64-w64-mingw32-gcc -mwindows -fstack-protector-all -Wstack-protector --param ssp-buffer-size=4 -fno-strict-overflow -Wno-missing-field-initializers -Wformat -Wformat-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all -Wstack-protector --param ssp-buffer-size=1 -fasynchronous-unwind-tables -Wall -fno-strict-aliasing -Waddress -Warray-bounds -Wdate-time -Wdouble-promotion -Wduplicated-cond -Wextra -Wfloat-conversion -Wignored-attributes -Winit-self -Wlogical-op -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wnormalized=nfkc -Wnull-dereference -Woverlength-strings -Woverride-init -Wshadow -Wshift-count-negative -Wshift-count-overflow -Wshift-negative-value -Wshift-overflow=2 -Wsizeof-array-argument -Wstrict-overflow=1 -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wswitch-bool -Wsync-nand -Wtrampolines -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-const-variable=2 -Wunused-local-typedefs -Wvariadic-macros -W -Wfloat-equal -Wundef -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wchar-subscripts -Wcomment -Wformat=2 -Wwrite-strings -Wnested-externs -Wbad-function-cast -Wswitch-enum -Waggregate-return -Wpacked -Wunused -Wunused-parameter -Wold-style-definition -Wmissing-declarations -mwindows -Wl,--dynamicbase -Wl,--nxcompat -Wl,--enable-reloc-section -lssp -L/var/tmp/dist/mingw-w64/gcclibs -Wl,--nxcompat -Wl,--dynamicbase -o src/tools/tor-resolve.exe src/tools/tor-resolve.o src/common/libor.a src/common/libor-ctime.a ./src/rust/target/release/tor_rust.lib -lws2_32 -luserenv
x86_64-w64-mingw32-gcc: error: ./src/rust/target/release/tor_rust.lib: No such file or directory
```
We don't want to have a *lib file I think. What we get instead when cross-compiling (libtor_rust.a) looks actually promising.Tor: 0.3.4.x-finalAlex XuAlex Xuhttps://gitlab.torproject.org/legacy/trac/-/issues/28912Stream hangs while downloading consensus via RELAY_BEGIN_DIR2020-06-13T18:29:22ZTracStream hangs while downloading consensus via RELAY_BEGIN_DIRAfter performing the following sequence of steps to download a consensus through a stream, Tor hangs after sending 58 (17 with deflate) cells:
1. Open an TLS connection to a local OR.
2. Negotiate a v5 link on the connection.
3. Create ...After performing the following sequence of steps to download a consensus through a stream, Tor hangs after sending 58 (17 with deflate) cells:
1. Open an TLS connection to a local OR.
2. Negotiate a v5 link on the connection.
3. Create a circuit via CREATE_FAST.
4. Create a stream via RELAY_BEGIN_DIR.
5. Send a request to download a consensus.
I managed to reproduce the issue with the code attached. Here are an excerpt of the file:
```
'''Using identity, we get 58 RELAY_DATA cells before hanging, 17 with deflate.
Affected:
Tor version 0.3.4.0-alpha-dev (git-3463b4e0652bacca).
Not affected:
Tor version 0.3.3.5-rc-dev (git-3ee4c9b1fae9d535).
'''
compression = b'identity' # or b'deflate'
'''Issue reproduced with the code below, originally bisected on [1].
From tag:tor-0.3.4.1-alpha Affected?
deb8970a29ef7427c3d42182d3bacc31ab602c03 yes
2d7b5c6fe5dc46b7e7cd040e6723e25d12015985 yes
3fa66f97996c179388fa91176b9a82fb9b5b31d8 no
306563ac68250872791350bda1ba7a7acff5eb63 no
3ee4c9b1fae9d53556b3e3be852f12e9abe51e14 no
c32108ee0fea851ced14f71d842390992f762393 yes
22845df2a7503ed73ed325c3a98916f289918caa no
c7d3de216c60c090fddb4926a739da038bb5d5fe yes
9ef4c05df8323850b5894782f435da15810d6189 no
5e0fbd7006993a4e402f2eee49f6f86074923197 no
c5899d5cf3a761f4049c1d6f05232731edcfeb57 no
3463b4e0652bacca51fecd2c256e3e9d61ce920e yes
[1] Unpublished (yet) python client, no link here, sorry :(
Usage:
virtualenv venv
source venv/bin/activate
pip install -r stem cryptography
tor PublishServerDescriptor 0 AssumeReachable 1 ExitRelay 0 ProtocolWarnings 1 SafeLogging 0 LogTimeGranularity 1 PidFile '$(mktemp)' SOCKSPort 0 ContactInfo none@example.com DataDirectory '$(mktemp -d)' ORPort 9050 DirPort 9051 Log 'err stderr' &
python reproduce.py
'''
```
I provided the redacted logs for two different versions, one affected and one not.
**Trac**:
**Username**: plcp`Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25284hidden-service-dir description in dir-spec should reference HSDir protovers2020-06-13T17:58:08Zteorhidden-service-dir description in dir-spec should reference HSDir protoversSince 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified...Since 0.3.0, tor supports HSDir versions 2 and 3 by default, and advertises no hidden-service-dir VersionNums.
But the spec says:
"If any VersionNum(s) are specified, this router supports those descriptor versions. If none are specified, it defaults to version 2 descriptors"Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/25756EARLY_CONSENSUS_NOTICE_SKEW of 60 is too strict for some drifting dirauth clocks2020-06-13T17:54:04ZTracEARLY_CONSENSUS_NOTICE_SKEW of 60 is too strict for some drifting dirauth clocksI keep getting this error on my relay, I set my timezone as Bucharest, Romania. The relay is running ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-119-generic x86_64) and using Tor 0.3.2.10
```
[WARN] Received ns flavor consensus with skewed tim...I keep getting this error on my relay, I set my timezone as Bucharest, Romania. The relay is running ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-119-generic x86_64) and using Tor 0.3.2.10
```
[WARN] Received ns flavor consensus with skewed time (CONSENSUS): It seems that our clock is behind by 1 minutes, 1 seconds, or that theirs is ahead. Tor requires an
accurate clock to work: please check your time, timezone, and date settings.
17:58:59 [WARN] Our clock is 1 minutes, 1 seconds behind the time published in the consensus network status document (2018-04-09 15:00:00 UTC). Tor needs an accurate clock to
work correctly. Please check your time and date settings!
```
**Trac**:
**Username**: DbryrtfbcbhgfTor: 0.3.4.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/25511Expose TZ info on control port for better debugging of time errors2020-06-13T17:44:06ZNick MathewsonExpose TZ info on control port for better debugging of time errorsWhen we tell people that their clocks are wrong, it's frequently because they've set up their systems with the wrong time zone. It would be helpful to tell torbrowser (or some other controller) about this information, so that it can giv...When we tell people that their clocks are wrong, it's frequently because they've set up their systems with the wrong time zone. It would be helpful to tell torbrowser (or some other controller) about this information, so that it can give more useful error messages on time-related bootstrapping failures.
~~One complication here is (IIUC) TB runs, and runs tor, with its TZ set to UTC.~~
Further investigation suggests that TB might not set `TZ` for the first time it starts tor. Opened #25823 for the Tor Launcher behavior inconsistency.Tor: 0.3.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/20522Enable DISABLE_DISABLING_ED255192020-06-13T17:35:03ZteorEnable DISABLE_DISABLING_ED25519Split from #18319
At some point, we should require relays that once had an ed25519 key associated with their RSA key to always have that key, rather than allowing them to drop back to a version that didn't support ed25519.
(This means ...Split from #18319
At some point, we should require relays that once had an ed25519 key associated with their RSA key to always have that key, rather than allowing them to drop back to a version that didn't support ed25519.
(This means they need to use a new RSA key to downgrade to an older version of tor without ed25519, which is consistent with the pinning in #18319.)
This means either:
1a. waiting until 0.2.5 is no longer recommended, or
1b. look at historical metrics data to see how often relays run a recent version for a while, then drop back to an older one. If the answer is "almost never" then we can just turn it on now.
To implement this change, replace `#undef DISABLE_DISABLING_ED25519` with `#define DISABLE_DISABLING_ED25519`.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/24790When 0.2.5 is EOL, remove the fallback script comment that refers to 0.2.8 an...2020-06-13T16:06:22ZteorWhen 0.2.5 is EOL, remove the fallback script comment that refers to 0.2.8 and earlierWe don't accept unsupported Tor versions as fallbacks, so there's no reason to talk about other bugs in unsupported versions.We don't accept unsupported Tor versions as fallbacks, so there's no reason to talk about other bugs in unsupported versions.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/24789Consider changing the fallback process to opt-out2020-06-13T16:06:22ZteorConsider changing the fallback process to opt-outIf we did this, we could rebuild the list by running a script, and occasionally collect opt-outs and add them to the blacklist.
I don't think this would worry anyone too much.If we did this, we could rebuild the list by running a script, and occasionally collect opt-outs and add them to the blacklist.
I don't think this would worry anyone too much.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25942Fix win32 test failure for crypto/openssl_version2020-06-13T15:52:21ZIsis LovecruftFix win32 test failure for crypto/openssl_versionFrom #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
opens...From #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-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28574Appveyor: OpenSSL unit test fails with header and library version mismatch2020-06-13T15:52:21ZteorAppveyor: OpenSSL unit test fails with header and library version mismatchI'm guessing that 1.1.1a and 1.1.1 are compatible, though?
```
crypto/openssl_version: [forking]
FAIL ../src/test/test_crypto.c:238: OpenSSL library version 1.1.1 did not begin with header version 1.1.1a.
[openssl_version FAILED]
``...I'm guessing that 1.1.1a and 1.1.1 are compatible, though?
```
crypto/openssl_version: [forking]
FAIL ../src/test/test_crypto.c:238: OpenSSL library version 1.1.1 did not begin with header version 1.1.1a.
[openssl_version FAILED]
```
https://ci.appveyor.com/project/torproject/tor/build/1.0.1625/job/gibgc64fp4hxsf2h?fullLog=true#L3064Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27810hs_service/helper_functions test seems unreliable on slow systems2020-06-13T15:46:23ZNick Mathewsonhs_service/helper_functions test seems unreliable on slow systemsHi! I've seen this test failure a few times on Travis:
```
hs_service/helper_functions: [forking]
FAIL src/test/test_hs_service.c:837: assert(ip->time_to_expire OP_GE now + INTRO_POINT_LIFETIME_MIN_SECONDS): 1537602275 vs 1537602297...Hi! I've seen this test failure a few times on Travis:
```
hs_service/helper_functions: [forking]
FAIL src/test/test_hs_service.c:837: assert(ip->time_to_expire OP_GE now + INTRO_POINT_LIFETIME_MIN_SECONDS): 1537602275 vs 1537602297
[helper_functions FAILED]
```
It seems to happen intermittently, so I think it might be one of those things where a slow-running machine fails the test because of the unexpected passage of time.
Is it possible to mock time here?Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25766Refactor token buckets to meet current coding standards2020-06-13T15:44:28ZNick MathewsonRefactor token buckets to meet current coding standardsOur existing token bucket code is a mess. We should clean it up before we tackle #25373.Our existing token bucket code is a mess. We should clean it up before we tackle #25373.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/27465Windows: cast between incompatible function types in address.c2020-06-13T15:44:11ZteorWindows: cast between incompatible function types in address.c```
bash.exe : ../src/common/address.c: In function 'get_interface_addresses_win32':
At line:2 char:5
+ & $commandPath $args 2>&1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (../src/common/a...dresses_...```
bash.exe : ../src/common/address.c: In function 'get_interface_addresses_win32':
At line:2 char:5
+ & $commandPath $args 2>&1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (../src/common/a...dresses_win32'::String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
../src/common/address.c:1499:14: error: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'ULONG (*)(ULONG, ULONG, void *, IP_ADAPTER_ADDRESSES_XP *, ULONG *)' {aka 'long unsigned int
(*)(long unsigned int, long unsigned int, void *, struct _IP_ADAPTER_ADDRESSES_XP *, long unsigned int *)'} [-Werror=cast-function-type]
if (!(fn = (GetAdaptersAddresses_fn_t)
^
```
https://ci.appveyor.com/project/teor2345/tor/build/1.0.152/job/g7dxnnck0r3p66n9#L1093Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29962Turn off Travis Rust caching, and see if it speeds up the builds2020-06-13T15:40:02ZteorTurn off Travis Rust caching, and see if it speeds up the buildsOur Rust builds seem to be really slow.
Maybe we should turn off caching, clear the caches, and see if that helps.Our Rust builds seem to be really slow.
Maybe we should turn off caching, clear the caches, and see if that helps.Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29806Ignore bandwidth file lines with "vote=0"2020-06-13T15:39:30ZjugaIgnore bandwidth file lines with "vote=0"As commented in https://trac.torproject.org/projects/tor/ticket/28563#comment:14As commented in https://trac.torproject.org/projects/tor/ticket/28563#comment:14Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29665hs: circuit_expire_old_circuits_serverside() should check for RP circuits2020-06-13T15:38:59ZDavid Gouletdgoulet@torproject.orghs: circuit_expire_old_circuits_serverside() should check for RP circuitsThanks to a single onion service operator on IRC in the #tor channel (`slingamn`), armadev and I were able to identify this issue.
Any clients connecting to a single onion service and then being idle for 60 seconds would get disconnecte...Thanks to a single onion service operator on IRC in the #tor channel (`slingamn`), armadev and I were able to identify this issue.
Any clients connecting to a single onion service and then being idle for 60 seconds would get disconnected as in the rendezvous circuit closed.
It turns out that the rendezvous point closes the service circuit through this function `circuit_expire_old_circuits_serversid()` if is idle for more than 60 seconds (only for single onion service). The faulty condition is:
```
if (or_circ->p_chan && channel_is_client(or_circ->p_chan) &&
!circ->n_chan &&
!or_circ->n_streams && !or_circ->resolving_streams &&
channel_when_last_xmit(or_circ->p_chan) <= cutoff) {
```
The RP is the end of the service circuit (`or_circ`), all data is spliced to the client circuit which makes it that `n_streams` and `n_chan` are NULL and thus validating the condition.
Also possible to hit this if `channel_is_client()` is a false positive for the exit point.
The fix here is to check if the circuit being looked at is a rendezvous point and ignore it if so. The `or_circ->rend_splice` should be non-NULL if so.
This needs to be backported and affects v2 and v3 hidden service.Tor: 0.3.4.x-final