Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:11:46Zhttps://gitlab.torproject.org/legacy/trac/-/issues/22927zstd tests fail with libzstd 1.3.02020-06-13T15:11:46Zteorzstd tests fail with libzstd 1.3.0When I run the unit tests on tor master:
`
[notice] Tor 0.3.2.0-alpha-dev (git-9a1338d9df938fba) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2l, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd 1.3.0.
`
I see the following failures...When I run the unit tests on tor master:
`
[notice] Tor 0.3.2.0-alpha-dev (git-9a1338d9df938fba) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2l, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd 1.3.0.
`
I see the following failures:
```
buffer/compress/zstd: [forking]
FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf, compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf, compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf, compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
FAIL src/test/test_buffers.c:607: assert(write_to_buf_compress(buf, compress_state, "", 0, 1) OP_EQ 0): -1 vs 0
[compress/zstd FAILED]
...
util/compress_concat/zstd:
FAIL src/test/test_util.c:2414: assert(r OP_EQ 0): -1 vs 0
[compress_concat/zstd FAILED]
```Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22915clang 4.0 double promotion warnings in clamp_double_to_int64()2020-06-13T15:11:41ZNick Mathewsonclang 4.0 double promotion warnings in clamp_double_to_int64()Just upgraded to clang 4.0, and I'm seeing this:
```
CC src/common/util.o
src/common/util.c:5612:13: error: implicit conversion increases floating-point
precision: 'double' to 'long double' [-Werror,-Wdouble-promotion]
i...Just upgraded to clang 4.0, and I'm seeing this:
```
CC src/common/util.o
src/common/util.c:5612:13: error: implicit conversion increases floating-point
precision: 'double' to 'long double' [-Werror,-Wdouble-promotion]
if (isnan(number)) {
~~~~~~^~~~~~~
/usr/include/math.h:385:46: note: expanded from macro 'isnan'
# define isnan(x) __MATH_TG ((x), __isnan, (x))
~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
/usr/include/math.h:320:16: note: expanded from macro '__MATH_TG'
: FUNC ## l ARGS)
~~~~~~~~~ ^~~~
src/common/util.c:5630:16: error: implicit conversion increases floating-point
precision: 'double' to 'long double' [-Werror,-Wdouble-promotion]
if (isfinite(number) && exponent <= 63) {
~~~~~~~~~^~~~~~~
/usr/include/math.h:370:50: note: expanded from macro 'isfinite'
# define isfinite(x) __MATH_TG ((x), __finite, (x))
~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
/usr/include/math.h:320:16: note: expanded from macro '__MATH_TG'
: FUNC ## l ARGS)
~~~~~~~~~ ^~~~
src/common/util.c:5635:18: error: implicit conversion increases floating-point
precision: 'double' to 'long double' [-Werror,-Wdouble-promotion]
return signbit(number) ? INT64_MIN : INT64_MAX;
~~~~~~~~^~~~~~~
/usr/include/math.h:361:58: note: expanded from macro 'signbit'
# define signbit(x) __MATH_TG ((x), __builtin_signbit, (x))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
/usr/include/math.h:320:16: note: expanded from macro '__MATH_TG'
: FUNC ## l ARGS)
~~~~~~~~~ ^~~~
3 errors generated.
```Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22895Unused variables in donna's SSE2 header2020-06-13T15:11:35ZcypherpunksUnused variables in donna's SSE2 headerFWICT this only occurs on 32-bit x86 systems because of the [portability header](https://gitweb.torproject.org/tor.git/tree/src/ext/ed25519/donna/ed25519-donna-portable.h?id=3aba8490ba590899b6c23071ef0b4269d8c36d37#n147).FWICT this only occurs on 32-bit x86 systems because of the [portability header](https://gitweb.torproject.org/tor.git/tree/src/ext/ed25519/donna/ed25519-donna-portable.h?id=3aba8490ba590899b6c23071ef0b4269d8c36d37#n147).Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22885When uploading the first descriptor of a session, call it dirty because "Tor ...2020-06-13T15:11:31ZNick MathewsonWhen uploading the first descriptor of a session, call it dirty because "Tor just started"I have a pending patch for this sitting around that came out of a conversation with Roger.I have a pending patch for this sitting around that came out of a conversation with Roger.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22883Bridge unavailable during differential consensus update2020-06-13T15:11:30ZTracBridge unavailable during differential consensus updateAfter updating Tor from 0.3.0.9 to 0.3.1.4 (on a Raspberry Pi running Raspbian), I observed that my bridge became unable to answer new connection requests for extended periods, from 10 to 20 minutes or more, while tor process uses all av...After updating Tor from 0.3.0.9 to 0.3.1.4 (on a Raspberry Pi running Raspbian), I observed that my bridge became unable to answer new connection requests for extended periods, from 10 to 20 minutes or more, while tor process uses all available cpu (more than 90% on average - with no corresponding traffic for clients) and files are updated in /var/lib/tor/diff-cache directory.
(For example, if I launch a TorBrowser using this bridge during such an update, it remains blocked before opening the Welcome window, and the corresponding client tor process remains blocked after "Bootstrapped 90%: Establishing a Tor circuit", for 10 minutes or more).
So I had to downgrade to 0.3.0.9, so that my bridge doesn't become unavailable for a total of several hours per day.
May I suggest that an option make it possible to choose between the new differential update mode and the traditional one?
First, this would be necessary for some (like me) to keep following new Tor versions long term.
And even on more powerful platforms, and even if a better handling of priorities could make it possible for main Tor thread to remain available on Pi, Tor relay operators might want to make different choices between minimizing bandwidth for consensus transfer or minimizing cpu usage, and hence power consumption. (Please think of the Planet globally, and not only of the network ;) )
**Trac**:
**Username**: torvlnt33rTor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22862tor-spec doesn't say how clients authenticate authorities or fallback directo...2020-06-13T15:11:25Zteortor-spec doesn't say how clients authenticate authorities or fallback directories```
In all handshake variants, once all certificates are exchanged, all
parties receiving certificates must confirm that the identity key is as
expected. (When initiating a connection, the expected identity key is
- th...```
In all handshake variants, once all certificates are exchanged, all
parties receiving certificates must confirm that the identity key is as
expected. (When initiating a connection, the expected identity key is
- the one given in the directory; when creating a connection because of an
+ when no reasonably live consensus is available: the one given in the hard-coded authority or fallback list;
+ when there is a reasonably live consensus: the one in the directory; when creating a connection because of an
EXTEND cell, the expected identity key is the one given in the cell.) If
the key is not as expected, the party must close the connection.
```Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/22636Add Travis configs so GitHub forks get CI coverage2020-06-13T15:23:20ZTaylor YuAdd Travis configs so GitHub forks get CI coverageIt would be useful to have Travis configs for tor so GitHub users can have CI coverage for changes in their forks. This should probably run `make check` or whatever more strict level of tests we converge on later.It would be useful to have Travis configs for tor so GitHub users can have CI coverage for changes in their forks. This should probably run `make check` or whatever more strict level of tests we converge on later.Tor: 0.3.2.x-finalpatrickodpatrickodhttps://gitlab.torproject.org/legacy/trac/-/issues/20247seccomp2 crash after closing and opening ipv6 DirPort + OrPort2020-06-13T15:01:47Ztoralfseccomp2 crash after closing and opening ipv6 DirPort + OrPortrun this :
```
/etc/init.d/tor status 2>/dev/null
if [[ $? -eq 0 ]]; then
sed -i -e 's/^DirPort *\[/#DirPort [/' -e 's/^ORPort *\[/#ORPort [/' /etc/tor/torrc
/etc/init.d/tor reload
fi
# renew cert
#
/usr/bin/certbot renew --standalo...run this :
```
/etc/init.d/tor status 2>/dev/null
if [[ $? -eq 0 ]]; then
sed -i -e 's/^DirPort *\[/#DirPort [/' -e 's/^ORPort *\[/#ORPort [/' /etc/tor/torrc
/etc/init.d/tor reload
fi
# renew cert
#
/usr/bin/certbot renew --standalone --non-interactive --text --renew-hook RestartJabber --disable-hook-validation &>$log
# reopen Tor ports
#
sed -i -e 's/^#DirPort *\[/DirPort [/' -e 's/^#ORPort *\[/ORPort [/' /etc/tor/torrc
/etc/init.d/tor status 2>/dev/null
if [[ $? -eq 0 ]]; then
/etc/init.d/tor reload
fi
```
to get this:
```
============================================================ T= 1474911552
(Sandbox) Caught a bad syscall attempt (syscall setsockopt)
/usr/bin/tor(+0x15dbc8)[0x1ac72c9bc8]
/lib64/libc.so.6(setsockopt+0xa)[0x30a1fef1a2a]
/lib64/libc.so.6(setsockopt+0xa)[0x30a1fef1a2a]
/usr/bin/tor(+0xee289)[0x1ac725a289]
/usr/bin/tor(retry_all_listeners+0x322)[0x1ac725bb12]
/usr/bin/tor(set_options+0xa7d)[0x1ac724e58d]
/usr/bin/tor(options_init_from_string+0x32e)[0x1ac725020e]
/usr/bin/tor(options_init_from_torrc+0x1e2)[0x1ac7250562]
/usr/bin/tor(+0x425c9)[0x1ac71ae5c9]
/usr/lib64/libevent-2.1.so.5(+0x2443b)[0x30a20e8043b]
/usr/lib64/libevent-2.1.so.5(event_base_loop+0x56f)[0x30a20e812cf]
/usr/bin/tor(do_main_loop+0x235)[0x1ac71acdd5]
/usr/bin/tor(tor_main+0x1bad)[0x1ac71b04cd]
/usr/bin/tor(main+0x2b)[0x1ac71a83ab]
/lib64/libc.so.6(__libc_start_main+0x114)[0x30a1fe1b734]
/usr/bin/tor(_start+0x29)[0x1ac71a83f9]
```Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17639provide an option to display the expiry date of a given ed25519 signing key2020-06-13T14:51:13Zcypherpunksprovide an option to display the expiry date of a given ed25519 signing keyCurrently there is no way to see when the signing key is about to expire.
Adding such a feature would be great.Currently there is no way to see when the signing key is about to expire.
Adding such a feature would be great.Tor: 0.3.2.x-finalIsis LovecruftIsis Lovecruft