George Kadianakis authored Mar 30, 2020 and Nick Mathewson committed Apr 13, 2020

And also disallow all-zeroes keys from the filesystem; add a test for it too.

George Kadianakis authored Mar 30, 2020 and Nick Mathewson committed Apr 13, 2020

The client auth protocol allows attacker-controlled x25519 private keys being
passed around, which allows an attacker to potentially trigger the all-zeroes
assert for client_auth_sk in hs_descriptor.c:decrypt_descriptor_cookie().

We fixed that by making sure that an all-zeroes client auth key will not be
used.

There are no guidelines for validating x25519 private keys, and the assert was
there as a sanity check for code flow issues (we don't want to enter that
function with an unitialized key if client auth is being used). To avoid such
crashes in the future, we also changed the assert to a BUG-and-err.

"ours" to avoid version bump

(Our fix for 33087 requires this, I believe.)

Fixes a couple of Coverity warnings about possible memory leaks.
Bug not in any released Tor.

asn: Accidentally left this commit out when merging #32542, so cherry-picking
it now.

Signed-off-by: David Goulet <dgoulet@torproject.org>

"ours" merge, because we only want to remove check-best-practices
from check-local in 0.4.2 and 0.4.3.

Remove check-best-practices from check-local in maint-0.4.3.
(The check-local jobs are all on separate lines in 0.4.3.)

Nick Mathewson authored Jun 19, 2019 and teor committed Apr 09, 2020

practracker shouldn't be running in release or maint branches.

"ours" merge, to avoid taking PR 1854, which reverts
"Prefer IPv6 by default"  for 0.4.3 only.

Squashed PR 1854, and fixed a minor typo (IPv4 -> IPv6).

David Goulet authored Apr 07, 2020 and teor committed Apr 09, 2020

This change broke torsocks that by default is expecting an IPv4 for hostname
resolution because it can't ask tor for a specific IP version with the SOCKS5
extension.

PreferIPv6 made it that sometimes the IPv6 could be returned to torsocks that
was expecting an IPv4.

Torsocks is probably a very unique case because the runtime flow is that it
hijacks DNS resolution (ex: getaddrinfo()), gets an IP and then sends it back
for the connect() to happen.

The libc has DNS resolution functions that allows the caller to request a
specific INET family but torsocks can't tell tor to resolve the hostname only
to an IPv4 or IPv6 and thus by default fallsback to IPv4.

Reverting this change into 0.4.3.x series but we'll keep it in the 0.4.4.x
series in the hope that we add this SOCKS5 extension to tor for DNS resolution
and then change torsocks to use that.

Fixes #33804

Signed-off-by: David Goulet <dgoulet@torproject.org>

Lock in some file and function size improvements.

Accept some small file size and dependency increases.

Part of 33633.

But only take the changes from the relay module.

Part of 33633.

Part of 33633.

Make the "else" case explicit at the end of the function.

Part of 33633.

Part of 33633.

Preparation for testing circuit_extend().

Part of 33633.

Explain what the function does now.
Fix some typos.

Part of 33633.

Part of 33633.

Part of 33633.

Part of 33633.

Since we're testing IF_BUG_ONCE(), we need to fork.

Part of 33633.

Add tests for circuit_extend_add_ed25519_helper().

Part of 33633.

Part of 33633.

Part of 33633.

Make test_new_route_len_unhandled_exit more robust, by always tearing
down logs. (Rather than just tearing them down on success.)