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

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

Fixes bug #40234; bugfix on 0.3.2.5-alpha.

Our original code for parsing these parameters out of our list of
parameters pre-dated us having the
dirvote_get_intermediate_param_value() function... and it was buggy.
Specifically, it would reject any " ... K=V ..." value
where there were additional unconverted characters after the V, and
use the default value instead,

We haven't run into this yet because we've never voted for
bwweightscale to be anything besides the default 10000, or
maxunmeasuredbw to be anything besides the default 20.

This requires a new consensus method because it is a change in how
consensuses are computed.

Fixes bug 19011; bugfix on 0.2.2.10-alpha.

"ours" to avoid version bump.

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.

"ours" to avoid version bump.

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.

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

It turns out that 9 years ago, we stopped appending data into stats file and
rather overwrite everytime we have new stats (see commit
a6a127c8)

The load_stats_file() function was still thinking that we could have the same
line many times in the file which turns out to be false since 9 years ago.
However, that did not cause problem until IPv6 connection stats came along
which introduced a new line in conn-stats: "ipv6-conn-bi-direct ...".

Before, that file contained a single line starting with the tag
"conn-bi-direct".  That very tag appears also in the IPv6 tag (see above) so
the load_stats_file() function would consider that the IPv6 line as the last
tag to be appeneded to the file and fail to report the line above (for IPv4).
It would actually truncate the IPv6 line and report it (removing the "ipv6-"
part).

In other words, "conn-bi-direct" was not reported and instead
"ipv6-conn-bi-direct" was used without the "ipv6-" part.

This commit refactors the entire function so that now it looks for a
"timestamp tag" to validate and then if everything is fine, returns the entire
content of the file. The refactor simplifies the function, adds logging in
case of failures and modernize it in terms of coding standard.

Unit tests are also added that makes sure the loaded content matches the
entire file if timestamp validation passes.

Fixes #40226

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