Given that ed25519 public key validity checks are usually not needed
and (so far) they are only necessary for onion addesses in the Tor
protocol, we decided to fix this specific bug instance without
modifying the rest of the codebase (see below for other fix
approaches).
In our minimal fix we check that the pubkey in
hs_service_add_ephemeral() is valid and error out otherwise.
This function does a nonfatal assertion to make sure that a machine
is not registered twice, but Tobias Pulls found a case where it
happens. Instead, make the function exit early so that it doesn't
cause a remotely triggered memory leak.
Fixes bug 33619; bugfix on 0.4.0.1-alpha. This is also tracked as
TROVE-2020-004.
Stop forcing all non-SOCKSPorts to prefer IPv6 exit connections.
Instead, prefer IPv6 connections by default, but allow users to change
their configs using the "NoPreferIPv6" port flag.
Fixes bug 33608; bugfix on 0.4.3.1-alpha.
For a bridge configured with a pluggable transport, the transport name is
used, with the IP address, for the GeoIP client cache entry.
However, the DoS subsystem was not aware of it and always passing NULL when
doing a lookup into the GeoIP cache.
This resulted in bridges with a PT are never able to apply DoS defenses for
newly created connections.
Fixes#33491
Signed-off-by: David Goulet <dgoulet@torproject.org>
Allow the "practracker" coding best practices checking script to read
unicode files, when using Python 2.
We made the script use unicode literals in 0.4.3.1-alpha, but didn't
change the codec for opening files.
Fixes bug 33374; bugfix on 0.4.3.1-alpha.
Closing these file descriptors can hide sanitiser logs.
Instead, flush the logs before tor exits, using fsync().
Some Windows environments don't have fsync(), so we check
for it at compile time.
Fixes bug 33087; bugfix on 0.4.1.6.
This patch ensures that we always lowercase the BridgeDistribution from
torrc in descriptors before submitting it.
See: https://bugs.torproject.org/32753
Conflicts:
doc/tor.1.txt
src/app/config/config.c
src/app/config/or_options_st.h
src/core/mainloop/connection.h
Between 042 and 043, the dirauth options were modularized so this merge commit
address this by moving the AuthDirRejectUncompressedRequests to the module
along with a series of accessors.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Authorities were never sending back 503 error code because by design they
should be able to always answer directory requests regardless of bandwidth
capacity.
However, that recently backfired because of a large number of requests from
unknown source using the DirPort that are _not_ getting their 503 code which
overloaded the DirPort leading to the authority to be unable to answer to its
fellow authorities.
This is not a complete solution to the problem but it will help ease off the
load on the authority side by sending back 503 codes *unless* the connection
is from a known relay or an authority.
Fixes#33029
Signed-off-by: David Goulet <dgoulet@torproject.org>
When the ONION_CLIENT_AUTH_REMOVE command is given to tor, now also remove the
descriptor associated with the client authorization credentials.
Fixes#33148
Signed-off-by: David Goulet <dgoulet@torproject.org>
The "once" flag makes tor_bug_occurred_() say that future instances
of the warning will be suppressed -- but that's not something that
BUG() does. Fixes bug 33095; bugfix on 0.4.1.1-alpha.
When we added the ACTIVE and DORMANT virtual signals, we taught the
signal command to handle them, but we didn't teach SIGNAL event to
report them.
To solve this problem and prevent it from recurring, this patch
revises the implementation of control_event_signal() to use the same
signal_table that handle_control_signal() uses. This way, the two
controller commands can't become out of sync.
Fixes bug 33104; bugfix on 0.4.0.1-alpha.
Fixes bug 32673; bugfix on 0.3.0.4-alpha. We introduced these
checks in ee5471f9aa to help diagnose 21369, but we used "-1"
when "TOR_TLS_ERROR_MISC" would have been correct. Found by opara.
I don't think that this is actually getting triggered in the wild,
but if it were, it could cause nasty behavior: spurious
WANTREAD/WANTWRITE returns have a way of turning into CPU-eating
busy-loops.
We introduced these BUG() checks in b0ddaac074 to prevent a
recurrence of bug 23690. But there's a report of the BUG() message
getting triggered and filling up the disk. Let's change it to
IF_BUG_ONCE().
Fixes bug 33093; bugfix on 0.3.2.2-alpha.
Stop allowing failures on the Travis CI stem tests job. It looks like
all the stem hangs we were seeing are now fixed, but let's make sure we
see them if they happen again.
Closes ticket 33075.
