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

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

We were looking for the first instance of "directory-signature "
when instead the correct behavior is to look for the first instance
of "directory-signature " at the start of a line.

Unfortunately, this can be exploited as to crash authorities while
they're voting.

Fixes #40316; bugfix on 0.2.2.4-alpha.  This is TROVE-2021-002,
also tracked as CVE-2021-28090.

We're going to disable this feature in all versions for now.

Now deprecated in libc >= 2.33

Closes #40309

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

It can be called with strings that should have been
length-delimited, but which in fact are not.  This can cause a
CPU-DoS bug or, in a worse case, a crash.

Since this function isn't essential, the best solution for older
Tors is to just turn it off.

Fixes bug 40286; bugfix on 0.2.2.1-alpha when dump_desc() was
introduced.

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

Any lookup now will be certain and not probabilistic as the bloomfilter.

Closes #40269

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

The TORPROTOCOL reason causes the client to close the circuit which is not
what we want because other valid streams might be on it.

Instead, CONNECTION_REFUSED will leave it open but will not allow more streams
to be attached to it. The client then open a new circuit to the destination.

Closes #40270

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

This is to minimize false positive and thus deny reentry to Exit connections
that were in reality not re-entering. Helps with overall UX.

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

Obey the "allow-network-reentry" consensus parameters in order to decide to
allow it or not at the Exit.

Closes #40268

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

George Kadianakis authored 4 years ago and David Goulet committed 4 years ago

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

Roger Dingledine authored 4 years ago and David Goulet committed 4 years ago

Exit relays now reject exit attempts to known relay addresses + ORPort and
also to authorities on the ORPort and DirPort.

Closes #2667

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

In order to deny re-entry in the network, we now keep a bloomfilter of relay
ORPort + address and authorities ORPort + address and DirPort + address
combinations.

So when an Exit stream is handled, we deny anything connecting back into the
network on the ORPorts for relays and on the ORPort+DirPort for the
authorities.

Related to #2667

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

Alex Xu authored 4 years ago and David Goulet committed 4 years ago

otherwise src/core is ignored.

Generates the compile_commands.json file using the "bear" application so the
ccls server can be more efficient with our code base.

Closes #40227

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

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

This one should work on GCC _and_ on Clang.  The previous version
made Clang happier by not having unreachable "fallthrough"
statements, but made GCC sad because GCC didn't think that the
unconditional failures were really unconditional, and therefore
_wanted_ a FALLTHROUGH.

This patch adds a FALLTHROUGH_UNLESS_ALL_BUGS_ARE_FATAL macro that
seems to please both GCC and Clang in this case: ordinarily it is a
FALLTHROUGH, but when ALL_BUGS_ARE_FATAL is defined, it's an
abort().

Fixes bug 40241 again.  Bugfix on earlier fix for 40241, which was
merged into maint-0.3.5 and forward, and released in 0.4.5.3-rc.

Some days before this commit, the network experienced a DDoS on the directory
authorities that prevented them to generate a consensus for more than 5 hours
straight.

That in turn entirely disabled onion service v3, client and service side, due
to the subsystem requiring a live consensus to function properly.

We know require a reasonably live consensus which means that the HSv3
subsystem will to its job for using the best consensus tor can find. If the
entire network is using an old consensus, than this should be alright.

If the service happens to use a live consensus while a client is not, it
should still work because the client will use the current SRV it sees which
might be the previous SRV for the service for which it still publish
descriptors for.

If the service is using an old one and somehow can't get a new one while
clients are on a new one, then reachability issues might arise. However, this
is a situation we already have at the moment since the service will simply not
work if it doesn't have a live consensus while a client has one.

Fixes #40237

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