teor authored 7 years ago and Nick Mathewson committed 7 years ago

When running "make test-network-all", test that IPv6-only clients can use
microdescriptors. IPv6-only microdescriptor client support was fixed in
tor 0.3.0.1-alpha.

Requires chutney master 61c28b9 or later.

Closes ticket 24109.

teor authored 7 years ago and Nick Mathewson committed 7 years ago

Part of #23820.

teor authored 7 years ago and Nick Mathewson committed 7 years ago

They are not yet implemented: they will upload descriptors, but won't be
able to rendezvous, because IPv6 addresses in link specifiers are ignored.

Part of #23820.

teor authored 7 years ago and Nick Mathewson committed 7 years ago

Diagnostics for #23820.

teor authored 7 years ago and Nick Mathewson committed 7 years ago

The previous version of this function had the following issues:
* it didn't check if the extend_info contained an IPv6 address,
* it didn't check if the ed25519 identity key was valid.
But we can't add IPv6 support in a bugfix release.

Instead, BUG() if the address is an IPv6 address, so we always put IPv4
addresses in link specifiers. And ignore missing ed25519 identifiers,
rather than generating an all-zero link specifier.

This supports v3 hidden services on IPv4, dual-stack, and IPv6, and
v3 single onion services on IPv4 only.

Part of 23820, bugfix on 0.3.2.1-alpha.

David Goulet authored 7 years ago and Nick Mathewson committed 7 years ago

A v3 service can have between 0 and 20 intro points where v2 has 0 to 10.

Fixes #24115

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

David Goulet authored 7 years ago and Nick Mathewson committed 7 years ago

When the directory information changes, callback to the HS client subsystem so
it can check if any pending SOCKS connections are waiting for a descriptor. If
yes, attempt a refetch for those.

Fixes #23762

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

Fixes bug 24082; bugfix on 0.3.0.3-alpha.  Found by Brian Carpenter.

The new decryption function performs no decryption, skips the salt,
and doesn't check the mac.  This allows us to fuzz the
hs_descriptor.c code using unencrypted descriptor test, and exercise
more of the code.

Related to 21509.

If the intro point supports ed25519 link authentication, make sure we don't
have a zeroed key which would lead to a failure to extend to it.

We already check for an empty key if the intro point does not support it so
this makes the check on the key more consistent and symmetric.

Fixes #24002

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

Fixes #21509

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

This reverts commit 5ef656e7.

This call happens before we update our entry guards, so it needs to be
removed for the fix to #23862 to work.

Update guard state even if we don't have enough dirinfo since that
actually affects the future download of dirinfos.

Fixes #23862 on 0.3.0.1-alpha

The previous version of these functions had the following issues:
* they can't supply both the IPv4 and IPv6 addresses in link specifiers,
* they try to fall back to a 3-hop path when the address for a direct
  connection is unreachable, but this isn't supported by
  launch_rendezvous_point_circuit(), so it fails.
But we can't fix these things in a bugfix release.

Instead, always put IPv4 addresses in link specifiers.
And if a v3 single onion service can't reach any intro points, fail.

This supports v3 hidden services on IPv4, dual-stack, and IPv6, and
v3 single onion services on IPv4 only.

Part of 23820, bugfix on 0.3.2.1-alpha.

The previous version of this function has the following issues:
* it doesn't choose between IPv4 and IPv6 addresses correctly, and
* it doesn't fall back to a 3-hop path when the address for a direct
  connection is unreachable.
But we can't fix these things in a bugfix release.

Instead, treat IPv6 addresses like any other unrecognised link specifier
and ignore them. If there is no IPv4 address, return NULL.

This supports v3 hidden services on IPv4, dual-stack, and IPv6, and
v3 single onion services on IPv4 only.

Part of 23820, bugfix on 0.3.2.1-alpha.

Turns out that when reloading a tor configured with hidden service(s), we
weren't copying all the needed information between the old service object to
the new one.

For instance, the desc_is_dirty timestamp wasn't which could lead to the
service uploading its desriptor much later than it would need to.

The replaycache wasn't also moved over and some intro point information as
well.

Fixes #23790

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

"ours" merge to avoid version bump

"ours" merge to avoid version bump

"ours" merge to avoid version bump

"ours" merge to avoid version bump

"ours" merge to avoid version bump