This patch makes Tor announce the relay specific bridge status page URL
when Tor is starting up before bootstrap occours.

See: tor#30477

This patch unbreaks the current build after tor!369 landed.

See: https://bugs.torproject.org/tpo/core/tor/40371

Now that we don't have version 2, it gives us:

  [warn] HiddenServiceVersion must be between 3 and 3, not 2.

This commit changes it to:

  [warn] HiddenServiceVersion must be 3, not 2.

Part of #40476

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

Closes #40476

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

Part of #40476

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

Some tests were removed because they were testing something not usable
anymore.

Some tests remains to make sure that things are indeed disabled.

Part of #40476

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

Part of #40476

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

Relay do not accept both stores and lookups of version 2 descriptor.
This effectively disable version 2 HSDir supports for relays.

Part of #40476

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

Upon receiving a v2 introduction request, the relay will close the
circuit and send back a tor protocol error.

Part of #40476

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

The minimum service version is raised from 2 to 3 which effectively
disable loading or creating an onion service v2.

As for ADD_ONION, for version 2, a 551 error is returned:

  "551 Failed to add Onion Service"

Part of #40476

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

This effectively turns off the ability of tor to use HSv2 as a client by
invalidating the v2 onion hostname passed through a SOCKS request.

Part of #40476

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

We currently assume that the only way for Tor to listen on ports in the
privileged port range (1 to 1023), on Linux, is if we are granted the
NET_BIND_SERVICE capability. Today on Linux, it's possible to specify
the beginning of the unprivileged port range using a sysctl
configuration option. Docker (and thus the CI service Tor uses) recently
changed this sysctl value to 0, which causes our tests to fail as they
assume that we should NOT be able to bind to a privileged port *without*
the NET_BIND_SERVICE capability.

In this patch, we read the value of the sysctl value via the /proc/sys/
filesystem iff it's present, otherwise we assume the default
unprivileged port range begins at port 1024.

See: tor#40275

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

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

George Kadianakis authored 3 years ago and Alexander Hansen Færøy committed 3 years ago

Fixes bug 40078.

As reported by hdevalence our batch verification logic can cause an assert
crash.

The assert happens because when the batch verification of ed25519-donna fails,
the code in `ed25519_checksig_batch()` falls back to doing a single
verification for each signature.

The crash occurs because batch verification failed, but then all signatures
individually verified just fine.

That's because batch verification and single verification use a different
equation which means that there are sigs that can pass single verification
but fail batch verification.

Fixing this would require modding ed25519-donna which is not in scope for
this ticket, and will be soon deprecated in favor of arti and
ed25519-dalek, so my branch instead removes batch verification.

New list for all stable releases.

Closes #40447

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

David Goulet authored 4 years ago and Alexander Hansen Færøy committed 3 years ago

Fixes #40301

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

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

This issue was reported by Jann Horn part of Google's Project Zero.

Jann's one-sentence summary: entry/middle relays can spoof RELAY_END cells on
half-closed streams, which can lead to stream confusion between OP and
exit.

Fixes #40389

Previously, we would detect errors from a missing RNG
implementation, but not failures from the RNG code itself.

Fortunately, it appears those failures do not happen in practice
when Tor is using OpenSSL's default RNG implementation.  Fixes bug
40390; bugfix on 0.2.8.1-alpha. This issue is also tracked as
TROVE-2021-004. Reported by Jann Horn at Google's Project Zero.

It was used nowhere outside its own unit tests, and it was causing
compilation issues with recent OpenSSL 3.0.0 alphas.

Closes ticket 40399.

Fixes bug 40931; bugfix on 0.2.4.4-alpha. Also tracked as
TROVE-2021-005.

This issue was reported by Jann Horn from Google's Project Zero.

As of GCC 11.1.1, the compiler warns us about code like this:

     if (a)
         b;
         c;

and that's a good thing: we wouldn't want to "goto fail".  But we
had an instance if this in circuituse.c, which was making our
compilation sad.

Fixes bug 40380; bugfix on 0.3.0.1-alpha.

This function has been a no-op since Libevent 2.0.4-alpha, when
libevent got an arc4random() implementation.  Libevent has finally
removed it, which will break our compilation unless we stop calling
it.  (This is currently breaking compilation in OSS-fuzz.)

Closes #40371.

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

This is a bugfix against my fix for #40133, which has not yet
appeared in 0.3.5.