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>
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.
It turns out that 9 years ago, we stopped appending data into stats file and
rather overwrite everytime we have new stats (see commit
a6a127c833)
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>
When making sure we have a Bridge line with a ClientTransportPlugin, we
now check in the managed proxy list and so we can catch any missing
ClientTransportPlugin for a Bridge line.
Fixes#40106
Signed-off-by: David Goulet <dgoulet@torproject.org>
Previously, our code would send back an error if the socks5 request
parser said anything but DONE. But there are other non-error cases,
like TRUNCATED: we shouldn't send back errors for them.
This patch lowers the responsibility for setting the error message
into the parsing code, since the actual type of the error message
will depend on what problem was encountered.
Fixes bug 40190; bugfix on 0.3.5.1-alpha.
Adds a more user-friendly error message when the configuration is
reloaded and a new %include is added that makes its unglobbing
access files/folders not allowed by the seccomp sandbox.
The "-static" compile flag was set globally which means that all autoconf test
were attempting to be built statically and lead to failures of detecting
OpenSSL libraries and others.
This commit adds this flag only to the "tor" binary build.
There is also a fix on where to find libevent.a since it is using libtool, it
is in .libs/.
At this commit, there are still warnings being emitted that informs the user
that the built binary must still be linked dynamically with glibc.
Fixes#40111
Signed-off-by: David Goulet <dgoulet@torproject.org>
When sending the stream level SENDME, it is possible the cirucit was marked
for close or any other failures that can occur. These events can occur
naturally.
Fixes#40142
Signed-off-by: David Goulet <dgoulet@torproject.org>
The function in charge of removing duplicate ORPorts from our configured ports
was skipping all non ORPorts port but only for the outer loop thus resulting
in comparing an ORPort with a non-ORPort which lead to problems.
For example, tor configured with the following would fail:
ORPort auto
DirPort auto
Both end up being the same configuration except that one is a OR listener and
one is a Dir listener. Thus because of the missing check in the inner loop,
they looked exactly the same and thus one is removed.
Fixes#40195
Signed-off-by: David Goulet <dgoulet@torproject.org>
First, this commit moves the launch_dummy_circuit_as_needed() function into
relay_find_addr.c and renames it to relay_addr_learn_from_dirauth(). This is
an attempt to centralize anything relate with address discovery in the right
module.
Second, when building a descriptor and we fail to discover our address,
immediately launch a dummy circuit to an authority in an attempt to learn our
descriptor.
It is still only done every 20 minutes even though the descriptor build is
done every minute. We ought to avoid load on the authority and if we can't
learn in the first place our address from them, chances are more things are
wrong.
Related to #40071
Signed-off-by: David Goulet <dgoulet@torproject.org>
Regularly, tor looks if its IP has changed. It does the entire auto discovery
process again. However, it is possible that it does not find anything.
Instead of thinking the IP changed to an unknown address, look at our cache
and see if that value has changed.
The reason for this is because if tor gets its address as a suggestion from a
directory authority, it is because the auto discovery failed and thus that
address should be consider for the IP change check.
Related to #40071
Signed-off-by: David Goulet <dgoulet@torproject.org>
Tor now can learn its address from a NETINFO cell coming from an authority.
Thus, instead from launching a dummy descriptor fetch to learn the address
from the directory response (unauthenticated), we simply now launch a one-hop
testing circuit.
Related to #40071
Signed-off-by: David Goulet <dgoulet@torproject.org>
Commit c3a0f75796 added this feature for ORPort
that we ignore any port that is not the family of our default address when
parsing the port. So if port_parse_config() was called with an IPv4 default
address, all IPv6 address would be ignored.
That makes sense for ORPort since we call twice port_parse_config() for
0.0.0.0 and [::] but for the rest of the ports, it is not good since a
perfectly valid configuration can be:
SocksPort 9050
SocksPort [::1]:9050
Any non-ORPort only binds by default to an IPv4 except the ORPort that binds
to both IPv4 and IPv6 by default.
The fix here is to always parse all ports within port_parse_config() and then,
specifically for ORPort, remove the duplicates or superseding ones. The
warning is only emitted when a port supersedes another.
A unit tests is added to make sure SocksPort of different family always exists
together.
Fixes#40183
Signed-off-by: David Goulet <dgoulet@torproject.org>
There were three separate places where we were hitting a sandbox Bug
warning before we actually exited.
Fixes#40094; bugfix on 0.3.1.1-alpha when %includes were introduced.
