When selecting the first advertised port, we always prefer the one with an
explicit address.

Closes #40246

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

We used to actually discard ORPorts that were the same port and same family
but they could have different address.

Instead, we need to keep all different ORPorts so we can bind a listener on
each of them. We will publish only one of these in our descriptor though.

Related to #40246

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

We can end up trying to find our address from an authority while we don't have
yet its descriptor.

In this case, don't BUG() and just come back later.

Closes #40231

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

In case building the descriptor would fail, we could still flag that we did in
fact publish the descriptors leading to no more attempt at publishing it which
in turn makes the relay silent for some hours and not try to rebuild the
descriptor later.

This has been spotted with #40231 because the operator used a localhost
address for the ORPort and "AssumeReachable 1" leading to this code path where
the descriptor failed to build but all conditions to "can I publish" were met.

Related to #40231

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

This is currently for the dircache module that can not be disabled by itself,
it is only disabled from the relay module.

Thus, we should not print in the configure summary the disable option.

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 gcc versions do explode if the order of the linker flags are not correct.
One issue was statically building OpenSSL which would require that "-lssl
-lcrypto" be put _before_ the "-lpthread -ldl" flags.

I have not such problem with GCC 10 but does with GCC 9.

Closes #33624

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

Fixes bug #40234; bugfix on 0.3.2.5-alpha.

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>

We're getting "fallback annotation annotation in unreachable code"
warnings when we build with ALL_BUGS_ARE_FATAL. This patch fixes
that.

Fixes bug 40241.  Bugfix on 0.3.5.4-alpha.

If we get an address suggestion from a directory authority and we have no
address configured or discovered, log it at notice level so the operator can
learn what address will be used by Tor.

Fixes #40201

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

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

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

Karsten Loesing authored 4 years ago and Nick Mathewson committed 4 years ago

The previous parser only considered stats files _starting_ with the
timestamp tag, not stats files having the timestamp tag in a later
position. While this applies to all current stats files, a future
stats file might look differently. Better to fix the function now than
be surprised in another 9 years from now.

This commit also adds a test case for such future stats, and it fixes
stats file paths in newly added unit tests.