Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:58:59Zhttps://gitlab.torproject.org/legacy/trac/-/issues/19499Compile time warnings with OpenSSL 1.1.0-pre6-dev (aka master).2020-06-13T14:58:59ZYawning AngelCompile time warnings with OpenSSL 1.1.0-pre6-dev (aka master).They changed a bunch of function prototypes since I wrote the code for #19406 to constify arguments passed to their RSA/DH accessors of doom.
This is trivial to fix, and should probably be done for the 0.2.8.x stable release assuming we...They changed a bunch of function prototypes since I wrote the code for #19406 to constify arguments passed to their RSA/DH accessors of doom.
This is trivial to fix, and should probably be done for the 0.2.8.x stable release assuming we intend to support OpenSSL 1.1.0 if it is declared stable prior to the 0.2.9.x getting out the door.Tor: 0.2.8.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/18943sha3 testsuite fails on big endian hosts2020-06-13T14:56:59Zweasel (Peter Palfrader)sha3 testsuite fails on big endian hostsHi,
looking at the current https://buildd.debian.org/status/package.php?p=tor&suite=experimental, in particular at
https://buildd.debian.org/status/fetch.php?pkg=tor&arch=mips&ver=0.2.8.2-alpha-1&stamp=1461496211
https://buildd.debian....Hi,
looking at the current https://buildd.debian.org/status/package.php?p=tor&suite=experimental, in particular at
https://buildd.debian.org/status/fetch.php?pkg=tor&arch=mips&ver=0.2.8.2-alpha-1&stamp=1461496211
https://buildd.debian.org/status/fetch.php?pkg=tor&arch=powerpc&ver=0.2.8.2-alpha-1&stamp=1461451662
https://buildd.debian.org/status/fetch.php?pkg=tor&arch=s390x&ver=0.2.8.2-alpha-1&stamp=1461436567
suggests that the sha3 test suite fails on big-endian hosts.
```
crypto/sha3: [forking]
FAIL ../src/test/test_crypto.c:506: assert(data == mem_op_hex_tmp): E241F247AF432EEDB73B6377C955F93F42B162AD7A2047E468381A59451EB178 vs 677035391CD3701293D385F037BA32796252BB7CE180B00B582DD9B20AAAD7F0
[sha3 FAILED]
crypto/sha3_xof: [forking]
FAIL ../src/test/test_crypto.c:854: assert(out == mem_op_hex_tmp): 62FBE70B8BA99C650A17E57A921F558D0D24DF1C960463DE4DEAB998B4287550F3B909E83FA6B202873F3DAF9AE3A816014814386C8534CAF25E828F80AB0B8E233D669CCC0C0A94213896DB9018714D096C82AF8B52D68906B28F636CDE99EC5C78C31D992A66E4D957C41AFBD27A776AD3F486728BE7B4AE5DBA090AA6B3D0B858E7730CF59727E505F757E8441BAD63639FABFB40AE3F647DECDB7AF60BC6B4A93C2F3300A97698BC84B0AAEDD8FC278CC1AF9C33B09712443CD5F1D4713582EA1E40C0F3C4F2D3D854747803EC55EAD1ED512E964053A193137EB9BC4DD97D619F679401AF7B152D264793E7F886C0FECA5F5D4C9F2AB01C66558256BC2FE8E322F3B8D159960E53B63D7EF207588B402018F0C1AA8CEEDDB44BA32071F5D3EBB426CFEC939462BCE590BE7CD968534552103A38C428B36F8E832F05C7BDFEC0935C2893C0D875C0A43089A484CF4F60E2A80434BBB90068870ACADCE6B59521B19ECECDD14B237D0E149FE40ABC2188DA16C0527A19FE9584BF925199CAB95B9504561E24D648F64A088C58A336D78111852C4F8782882D9F7D9AF7B82960D682D83DD5FD681DF07BD47B116393DFEDEBDCA3DB464B68CA9DBF6AD3756FCFAE3BBD7E4B4737D8556081C855414A722EDEB7FF4B31AF4F3FF5F65368A9CE2F7BAA3507CFAFBF455F164143BC6F5CE4554F695EFAD65513116C26BA915750 vs 8A5199B4A7E133E264A86202720655894D48CFF344A928CF8347F48379CEF347DFC5BCFFAB99B27B1F89AA2735E23D30088FFA03B9EDB02B9635470AB9F1038985D55F9CA774572DD006470EA65145469609F9FA0831BF1FFD842DC24ACADE27BD9816E3B5BF2876CB112232A0EB4475F1DFF9F5C713D9FFD4CCB89AE5607FE35731DF06317949EEF646E9591CF3BE53ADD6B7DD2B6096E2B3FB06E662EC8B2D77422DAAD9463CD155204ACDBD38E319613F39F99B6DFB35CA9365160066DB19835888C2241FF9A731A4ACBB5663727AAC34A401247FBAA7499E7D5EE5B69D31025E63D04C35C798BCA1262D5673A9CF0930B5AD89BD485599DC184528DA4790F088EBD170B635D9581632D2FF90DB79665CED430089AF13C9F21F6D443A818064F17AEC9E9C5457001FA8DC6AFBADBE3138F388D89D0E6F22F66671255B210754ED63D81DCE75CE8F189B534E6D6B3539AA51E837C42DF9DF59C71E6171CD4902FE1BDC73FB1775B5C754A1ED4EA7F3105FC543EE0418DAD256F3F6118EA77114A16C15355B42877A1DB2A7DF0E155AE1D8670ABCEC3450F4E2EEC9838F895423EF63D261138BAAF5D9F104CB5A957AEA06C0B9B8C78B0D441796DC0350DDEABB78A33B6F1F9E68EDE3D1805C7B7E2CFD54E0FAD62F0D8CA67A775DC4546AF9096F2EDB221DB42843D65327861282DC946A0BA01A11863AB2D1DFD16E3973D4
[sha3_xof FAILED]
```Tor: 0.2.8.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/18728Build is broken with --enable-gcc-warnings on NetBSD.2020-06-13T14:56:02ZYawning AngelBuild is broken with --enable-gcc-warnings on NetBSD.Part of trying to track down #18286, neither tor nor the unit tests build with `--enable-gcc-warnings` set on NetBSD 7.0 (gcc 4.8.4) due to char subscript warnings.
This gets tor to build:
```
diff --git a/src/ext/readpassphrase.c b/src...Part of trying to track down #18286, neither tor nor the unit tests build with `--enable-gcc-warnings` set on NetBSD 7.0 (gcc 4.8.4) due to char subscript warnings.
This gets tor to build:
```
diff --git a/src/ext/readpassphrase.c b/src/ext/readpassphrase.c
index ab71935..dee474f 100644
--- a/src/ext/readpassphrase.c
+++ b/src/ext/readpassphrase.c
@@ -144,11 +144,11 @@ restart:
if (p < end) {
if ((flags & RPP_SEVENBIT))
ch &= 0x7f;
- if (isalpha(ch)) {
+ if (isalpha((int)ch)) {
if ((flags & RPP_FORCELOWER))
- ch = (char)tolower(ch);
+ ch = (char)tolower((int)ch);
if ((flags & RPP_FORCEUPPER))
- ch = (char)toupper(ch);
+ ch = (char)toupper((int)ch);
}
*p++ = ch;
}
```
The test suite fails with:
```
CC src/test/src_test_test-test_util.o
../src/test/test_util.c: In function 'test_util_format_time_interval':
../src/test/test_util.c:2347:3: error: array subscript has type 'char' [-Werror=char-subscripts]
tt_ci_char_op(label_s[0],OP_EQ, 's');
^
../src/test/test_util.c:2354:3: error: array subscript has type 'char' [-Werror=char-subscripts]
tt_ci_char_op(label_s[0],OP_EQ, 's');
[lots more use of the macro snipped]
```
I'm filing this against 0.2.8, since it's a build failure, change it if you disagree.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18685Fire a`STATUS_SERVER` event when the hibernation state changes.2020-06-13T14:55:53ZYawning AngelFire a`STATUS_SERVER` event when the hibernation state changes.Most of the hibernation related information is already exposed in a useful manner via `GETINFO`. As far as I can tell the only really other useful thing to do here is to fire an event whenever we enter/exit hibernation so that controlle...Most of the hibernation related information is already exposed in a useful manner via `GETINFO`. As far as I can tell the only really other useful thing to do here is to fire an event whenever we enter/exit hibernation so that controllers don't have to poll continuously via `GETINFO`.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18221Validate our DH parameters to prevent socat-type fails.2020-06-13T14:53:58ZYawning AngelValidate our DH parameters to prevent socat-type fails.http://www.openwall.com/lists/oss-security/2016/02/01/4
Was stupid and is easily avoided. While we use hard coded known good primes taken from sensible locations, the code should validate the parameters used as a defense in depth measure.http://www.openwall.com/lists/oss-security/2016/02/01/4
Was stupid and is easily avoided. While we use hard coded known good primes taken from sensible locations, the code should validate the parameters used as a defense in depth measure.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18029ADD_ONION doesn't validate its target2020-06-13T14:53:21ZDamian JohnsonADD_ONION doesn't validate its targetThe target ADD_ONION accepts is documented as matching [HiddenServicePort](https://www.torproject.org/docs/tor-manual.html.en#HiddenServicePort) but evidently doesn't validate that it's given a valid address...
```
>>> GETINFO version
2...The target ADD_ONION accepts is documented as matching [HiddenServicePort](https://www.torproject.org/docs/tor-manual.html.en#HiddenServicePort) but evidently doesn't validate that it's given a valid address...
```
>>> GETINFO version
250-version=0.2.7.6-dev (git-b34c5c6b8ac0d13d)
250 OK
>>> ADD_ONION NEW:BEST Port=4567,not_an_address:4567
250-ServiceID=4e5bpsy6e46onv3k
250-PrivateKey=RSA1024:[crypto blob]
250 OK
```
Honestly I'm a tad mystified since this is breaking Stem's integ tests, but only started manifesting after I reformatted my system yesterday. I'd expect our Jenkins tests to be failing so this might be something local, but if so I'm stumped.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17783Pull in a SHA-3 implementation.2020-06-13T14:52:03ZYawning AngelPull in a SHA-3 implementation.We'll need it sooner or later, particularly because SHAKE128/SHAKE256 are incredibly handy for what they do, and having a cryptographic hash that's immune to length extension attacks simplifies some of our constructs.
I have a modified ...We'll need it sooner or later, particularly because SHAKE128/SHAKE256 are incredibly handy for what they do, and having a cryptographic hash that's immune to length extension attacks simplifies some of our constructs.
I have a modified version of keccak-tiny (https://github.com/coruus/keccak-tiny) that provides more familiar semantics that I can clean up for inclusion.Tor: 0.2.8.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/17687crypto_strongest_rand() failures should be fatal(?)2020-06-13T14:51:29ZYawning Angelcrypto_strongest_rand() failures should be fatal(?)Follow up from #17686.
We either trust OpenSSL's `RAND_bytes()`, or we don't. The existence/use of the call hints at the latter, so failing `crypto_strongest_rand()` should be fatal especially when doing Ed25519/Curve25519 key generation.Follow up from #17686.
We either trust OpenSSL's `RAND_bytes()`, or we don't. The existence/use of the call hints at the latter, so failing `crypto_strongest_rand()` should be fatal especially when doing Ed25519/Curve25519 key generation.Tor: 0.2.8.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/17635Assertion due to periodic event initialization being too late.2020-06-13T14:51:10ZYawning AngelAssertion due to periodic event initialization being too late.Reported by Lunar in #tor-dev:
```
Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(log_backtrace+0x41) [0x5644546256b1] (on Tor 0.2.8.0-alpha-dev )
Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x8d) [0x5644546338bd] (on ...Reported by Lunar in #tor-dev:
```
Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(log_backtrace+0x41) [0x5644546256b1] (on Tor 0.2.8.0-alpha-dev )
Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x8d) [0x5644546338bd] (on Tor 0.2.8.0-alpha-dev )
Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(reschedule_directory_downloads+0x6f) [0x5644545344df] (on Tor 0.2.8.0-alpha-dev )
Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(learned_bridge_descriptor+0x394) [0x56445461b704] (on Tor 0.2.8.0-alpha-dev )
Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(routerlist_descriptors_added+0xc3) [0x56445457a4a3] (on Tor 0.2.8.0-alpha-dev )
Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(router_load_routers_from_string+0x429) [0x56445457db19] (on Tor 0.2.8.0-alpha-dev )
Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(+0x88089) [0x56445457e089] (on Tor 0.2.8.0-alpha-dev )
Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(router_reload_router_list+0x26) [0x56445457e0e6] (on Tor 0.2.8.0-alpha-dev )
Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(do_main_loop+0x118) [0x564454534968] (on Tor 0.2.8.0-alpha-dev )
Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(tor_main+0x19ad) [0x56445453812d] (on Tor 0.2.8.0-alpha-dev ) Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(main+0x19) [0x564454530889] (on Tor 0.2.8.0-alpha-dev )
Nov 18 12:03:38.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f9289bd9b45] (on Tor 0.2.8.0-alpha-dev )
Nov 18 12:03:38.000 [err] Bug: /usr/bin/tor(+0x3a8d9) [0x5644545308d9] (on Tor 0.2.8.0-alpha-dev )
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17562DataDirectory permissions are too restrictive when using CapabilityBoundingSe...2020-06-13T15:00:24ZTracDataDirectory permissions are too restrictive when using CapabilityBoundingSet or SELinuxDirectories created by Tor have 0700 and TorUser:TorUser permissions. Tor also checks the permissions again at runtime, reducing the permissions if they aren't 0700 and refusing to run if the directory UID and GID aren't both TorUser.
T...Directories created by Tor have 0700 and TorUser:TorUser permissions. Tor also checks the permissions again at runtime, reducing the permissions if they aren't 0700 and refusing to run if the directory UID and GID aren't both TorUser.
These precautions protect the security of the Tor files. However, the DataDirectory (ie, `/var/lib/tor`) is unreadable by the root user. When Tor is started as root, it accesses the DataDirectory before dropping root permissions. Normally this wouldn't cause any problems, but there are two situations in which Tor is prevented from running:
1. If the systemd `CapabilityBoundingSet` option is set but `CAP_READ_SEARCH` isn't listed, root is denied access to the DataDirectory.
2. If SELinux is enabled but `tor_t` domain isn't allowed `dac_read_search` permissions, root is denied access to the DataDirectory.
`CAP_READ_SEARCH` and dac_read_search should be avoided; a process with these permissions can read arbitrary files regardless of DAC permissions. The solution proposed in this patch is to default to creating the DataDirectory with 0750 permissions, while also allowing the group to be either TorUser or root (but nobody else).
Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1279222
I notice that Debian fixed this issue on Stretch/Sid by giving Tor `CAP_DAC_OVERRIDE`, `CAP_CHOWN` and `CAP_FOWNER`. These dangerous capabilities are effectively equal to root, and kind of defeats the point of using `CapabilityBoundingSet` in the first place. I've chosen different solution.
**Trac**:
**Username**: jamielinuxTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17549tortls.c compile error w/Tor v0.2.8.0-alpha-dev and OpenSSL 1.1.0-dev (git-19...2020-06-13T14:50:47ZTractortls.c compile error w/Tor v0.2.8.0-alpha-dev and OpenSSL 1.1.0-dev (git-19e10f95c105a698) against SSL_DevHi again...
with Tor v0.2.8.0-alpha-dev (builds after git-19e10f95c105a698) running on NetBSD (6/i386) with Libevent 2.1.5-beta, OpenSSL 1.1.0-dev and Zlib 1.2.3
For 5 or 6 days I receive the following compile errors:
gmake[1]: Entering...Hi again...
with Tor v0.2.8.0-alpha-dev (builds after git-19e10f95c105a698) running on NetBSD (6/i386) with Libevent 2.1.5-beta, OpenSSL 1.1.0-dev and Zlib 1.2.3
For 5 or 6 days I receive the following compile errors:
gmake[1]: Entering directory '/usr/local/src/tor'
CC src/common/tortls.o
src/common/tortls.c: In function 'tor_tls_server_info_callback':
src/common/tortls.c:1536:3: warning: implicit declaration of function 'SSL_state'
src/common/tortls.c:1537:21: error: 'SSL3_ST_SW_SRVR_HELLO_A' undeclared (first use in this function)
src/common/tortls.c:1537:21: note: each undeclared identifier is reported only once for each function it appears in
src/common/tortls.c:1538:21: error: 'SSL3_ST_SW_SRVR_HELLO_B' undeclared (first use in this function)
Makefile:3240: recipe for target 'src/common/tortls.o' failed
gmake[1]: *** [src/common/tortls.o] Error 1
gmake[1]: Leaving directory '/usr/local/src/tor'
Makefile:1864: recipe for target 'all' failed
gmake: *** [all] Error 2
regards,
gene
**Trac**:
**Username**: yancmTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17544Our SipHash-2-4 performance is sometimes odd.2020-06-13T14:50:47ZYawning AngelOur SipHash-2-4 performance is sometimes odd.Something is screwed up (probably in the code gen), such that hashing buffers that aren't a multiple of 8 has performance issues.
```
siphash24g(7): 30.42 ns per call
siphash24g(8): 22.67 ns per call
siphash24g(15): 34.08 ns per call
si...Something is screwed up (probably in the code gen), such that hashing buffers that aren't a multiple of 8 has performance issues.
```
siphash24g(7): 30.42 ns per call
siphash24g(8): 22.67 ns per call
siphash24g(15): 34.08 ns per call
siphash24g(16): 27.14 ns per call
siphash24g(20): 36.35 ns per call
siphash24g(32): 37.66 ns per call
siphash24g(111): 93.87 ns per call
siphash24g(128): 100.21 ns per call
```
I'm not sure if deviating from the upstream further to fix this is the right thing to do, but we probably call this code a decent amount.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17223tortls.c compile errors on git master/current2020-06-13T14:49:48ZTractortls.c compile errors on git master/currentHi,
On NetBSD 6_Stable (i386) compiling against openssl git master/current,
I have been receiving the following errors for a couple of days:
CC src/common/tortls.o
In file included from src/common/tortls.c:75:0:
src/common/tor...Hi,
On NetBSD 6_Stable (i386) compiling against openssl git master/current,
I have been receiving the following errors for a couple of days:
CC src/common/tortls.o
In file included from src/common/tortls.c:75:0:
src/common/tortls.h:139:15: error: conflicting types for 'SSL_SESSION_get_master_key'
/usr/local/ssl/include/openssl/ssl.h:1658:15: note: previous declaration of 'SSL_SESSION_get_master_key' was here
src/common/tortls.c: In function 'log_cert_lifetime':
src/common/tortls.c:2139:3: warning: passing argument 1 of 'X509_get_notBefore' discards qualifiers from pointer target type
/usr/local/ssl/include/openssl/x509.h:694:13: note: expected 'struct X509 *' but argument is of type 'const struct X509 *'
src/common/tortls.c:2147:3: warning: passing argument 1 of 'X509_get_notAfter' discards qualifiers from pointer target type
/usr/local/ssl/include/openssl/x509.h:696:12: note: expected 'struct X509 *' but argument is of type 'const struct X509 *'
src/common/tortls.c: In function 'check_cert_lifetime_internal':
src/common/tortls.c:2309:3: warning: passing argument 1 of 'X509_get_notBefore' discards qualifiers from pointer target type
/usr/local/ssl/include/openssl/x509.h:694:13: note: expected 'struct X509 *' but argument is of type 'const struct X509 *'
src/common/tortls.c:2314:3: warning: passing argument 1 of 'X509_get_notAfter' discards qualifiers from pointer target type
/usr/local/ssl/include/openssl/x509.h:696:12: note: expected 'struct X509 *' but argument is of type 'const struct X509 *'
src/common/tortls.c: At top level:
src/common/tortls.h:139:15: warning: 'SSL_SESSION_get_master_key' used but never defined
Makefile:3222: recipe for target 'src/common/tortls.o' failed
gmake[1]: *** [src/common/tortls.o] Error 1
gmake[1]: Leaving directory '/usr/local/src/tor'
Makefile:1855: recipe for target 'all' failed
gmake: *** [all] Error 2
I understand maintaining sync (tor/openssl - master branches) is not the
primary concern of the effort, but thought I would bring this to your attention.
--gene
**Trac**:
**Username**: yancmTor: 0.2.8.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/17109autoconf should check that the SSL implementation has ECC support and at leas...2020-06-13T14:49:16ZYawning Angelautoconf should check that the SSL implementation has ECC support and at least one usable curve.Gentoo apparently has special snowflake OpenSSL > 1.0 that is missing ECC support unless explicitly enabled. Since we only check the OpenSSL version and not if ECC support is present, the build fails at `make` time rather than `configur...Gentoo apparently has special snowflake OpenSSL > 1.0 that is missing ECC support unless explicitly enabled. Since we only check the OpenSSL version and not if ECC support is present, the build fails at `make` time rather than `configure` time.
We should fix this so it fails earlier rather than later.
https://bugs.gentoo.org/560780Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16846Include sizeof(void *) in your extrainfo.2020-06-13T14:48:21ZYawning AngelInclude sizeof(void *) in your extrainfo.From #16535, it appears that it would be useful to get an idea of how much x86 vs x86_64 we have as part of the tor network. If we don't also include CPU architecture information, it would be good to have that as well if we can do it saf...From #16535, it appears that it would be useful to get an idea of how much x86 vs x86_64 we have as part of the tor network. If we don't also include CPU architecture information, it would be good to have that as well if we can do it safely.https://gitlab.torproject.org/legacy/trac/-/issues/16674Allow FQDNs ending with a single '.' in our SOCKS host name checks.2020-06-13T14:47:39ZYawning AngelAllow FQDNs ending with a single '.' in our SOCKS host name checks.Brought up as part of #16430. A single `.` is allowed by RFC 3986 ("URI Generic Syntax") in URIs to specify that a domain name is absolute rather than relative. In practice not many sites use this, but right now since we unilaterally r...Brought up as part of #16430. A single `.` is allowed by RFC 3986 ("URI Generic Syntax") in URIs to specify that a domain name is absolute rather than relative. In practice not many sites use this, but right now since we unilaterally reject the syntax, it breaks things.
Relevant portion of RFC 3986:
```
Such a name consists of a sequence of domain labels separated by ".",
each domain label starting and ending with an alphanumeric character
and possibly also containing "-" characters. The rightmost domain
label of a fully qualified domain name in DNS may be followed by a
single "." and should be if it is necessary to distinguish between
the complete domain name and some local domain.
```
RFC 1928 specifies that all `DOMAINNAME` type addresses are `fully-qualified domain name`(s), so I personally think that the `.` is redundant, but accepting it will increase compatibility, and being somewhat tolerant here is a good thing.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16666ed25519-donna doesn't build on arm without warnings with the stack protector2020-06-13T14:47:38ZYawning Angeled25519-donna doesn't build on arm without warnings with the stack protectorFrom Jenkins (https://jenkins.torproject.org/job/tor-ci-linux-master-extra-arm/147/ARCHITECTURE=armhf,SUITE=jessie/consoleFull):
```
13:54:27 ../tor/src/ext/ed25519/donna/ed25519_tor.c: In function 'curved25519_scalarmult_basepoint_donna...From Jenkins (https://jenkins.torproject.org/job/tor-ci-linux-master-extra-arm/147/ARCHITECTURE=armhf,SUITE=jessie/consoleFull):
```
13:54:27 ../tor/src/ext/ed25519/donna/ed25519_tor.c: In function 'curved25519_scalarmult_basepoint_donna':
13:54:27 ../tor/src/ext/ed25519/donna/ed25519_tor.c:107:12: error: stack protector not protecting local variables: variable length buffer [-Werror=stack-protector]
13:54:27 ED25519_FN(curved25519_scalarmult_basepoint) (curved25519_key pk, const curved25519_key e) {
13:54:27 ^
13:54:27 ../tor/src/ext/ed25519/donna/ed25519_tor.c:33:32: note: in definition of macro 'ED25519_FN3'
13:54:27 #define ED25519_FN3(fn,suffix) fn##suffix
```
Commit d8352646900c6316af8e2967742ce6a438b04221 should have fixed this, but apparently it's not enough. I'm just going to change the donna code to not align to 16 byte boundaries on ARM since that's only there for the SSE2 code in the first place.
On the off chance that the code does gain NEON support the penalty for unaligned access isn't that severe (there are load/store forms that require alignment, in which case the code will crash), but when that happens we can revisit this issue.Tor: 0.2.7.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/15652Base64 code cleanups.2020-06-13T14:45:17ZYawning AngelBase64 code cleanups.The base64 encoder/decoder can use some love of the following sort:
* The code gated by `USE_OPENSSL_BASE64` should probably be removed, since we haven't used OpenSSL's base64 decoder since 2007, and enabling it will do weird and broke...The base64 encoder/decoder can use some love of the following sort:
* The code gated by `USE_OPENSSL_BASE64` should probably be removed, since we haven't used OpenSSL's base64 decoder since 2007, and enabling it will do weird and broken things (Eg: Inputs that aren't broken up into into lines that are < 80 characters will fail to decode correctly).
* It would be really nice to have a Base64 encode that doesn't automatically add `\n` characters.
* Having a routine to get the encoded output size makes for cleaner code.Tor: 0.2.7.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/15482Don't surprise users with new circuits in the middle of browsing2020-06-15T23:29:43ZMike PerryDon't surprise users with new circuits in the middle of browsingThe way Tor handles circuit dirtiness for websites is pretty crappy. See #13766.
However, simply raising the circuit dirtiness timeout has a whole bunch of problems. See https://lists.torproject.org/pipermail/tor-dev/2015-March/008548.h...The way Tor handles circuit dirtiness for websites is pretty crappy. See #13766.
However, simply raising the circuit dirtiness timeout has a whole bunch of problems. See https://lists.torproject.org/pipermail/tor-dev/2015-March/008548.html.
So instead of raising the timeout, let's make normal circuits behave more like hidden service circuits: keep resetting their timestamp_dirty every time a new stream is attached. This has the effect that a user will never suddenly get a new circuit in the middle of actively using a website, which will be a huge usability improvement. Still not ideal, but good enough to leave the actual circuit dirtiness timeout alone.
I am going to do this with a TBB-specific Tor patch for now so we can test this in TBB 4.5a5. We can then decide if we want to make this a torrc option after that.Tor: 0.2.7.x-finalYawning AngelYawning Angel