| Age | Commit message (Collapse) | Author |
|---|
|
Commit 488e2b00bf881b97bcc8e4bbe304845ff1d79a03 introduced an issue, most
likely introduced by a bad copy paste, that made us stop reading on the
connection if our write bandwidth limit was reached.
The problem is that because "read_blocked_on_bw" was never set, the connection
was never reenabled for reading.
This is most likely the cause of #27813 where bytes were accumulating in the
kernel TCP bufers because tor was not doing reads. Only relays with
RelayBandwidthRate would suffer from this but affecting all relays connecting
to them. And using that tor option is recommended and best practice so many
many relays have it enabled.
Fixes #28089.
|
|
It turns out that if _only_ the ControlPort is set and nothing else, tor would
simply not bootstrap and thus not start properly. Commit 67a41b63063370c2
removed that requirement for tor to be considered a "client".
Unfortunately, this made the mainloop enable basically nothing if only the
ControlPort is set in the torrc.
This commit now makes it that we also consider the ControlPort when deciding
if we are a Client or not. It does not revert 67a41b63063370c2 meaning
options_any_client_port_set() stays the same, not looking at the control port.
Fixes #27849.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
This version of the macro makes it obvious to the compiler that
"tor_assert_unreached()" will always abort().
|
|
|
|
|
|
|
|
|
|
|
|
In hs_config.c, we do validate the permission of the hidden service directory
but we do not try to create it. So, in the event that the directory doesn't
exists, we end up in the loading key code path which checks for the
permission and possibly creates the directory. On failure, don't BUG() since
there is a perfectly valid use case for that function to fail.
Fixes #27335
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Before 0.3.3.1-alpha, we would exit() in this case immediately. But
now that we leave tor_main() more conventionally, we need to make
sure we restore things so as not to cause a double free.
Fixes bug 27708; bugfix on 0.3.3.1-alpha.
|
|
The spec only allows the characters [A-Za-z0-9-].
Fix on b2b2e1c7f24d9b65059e3d089768d6c49ba4f58f.
Fixes #27316; bugfix on 0.2.9.4-alpha.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix a minor merge conflict due to an #endif comment.
|
|
It is not supported, and always fails. Some compilers warn about the
function pointer cast on 64-bit Windows.
Fixes bug 27461; bugfix on 0.2.2.23-alpha.
|
|
gcc 8 warns that extend_info_t.nickname might be truncated by strncpy().
But it doesn't know that nickname can either contain a hex id, or a
nicknames. hex ids are only used for general and HSDir circuits.
Fixes bug 27463; bugfix on 0.1.1.2-alpha.
|
|
|
|
|
|
LinkAuth method 1 is the one where we pull the TLS master secrets
out of the OpenSSL data structures and authenticate them with
RSA. Right now we list method 1 as required for clients and relays.
That's a problem, since we can't reasonably support it with NSS. So
let's remove it as a requirement and a recommendation.
As for method 3: I'd like to recommend it it, but that would make
0.2.9 start warning. Let's not do that till at least some time
after 0.3.5 (the next LTS) is stable.
Closes ticket 27286
|
|
Diagnostics for 27236.
|
|
This fix requires chutney's 27230 fix to bridge client bootstrap.
Part of 27236.
|
|
Instead, count exits as usable if they have the exit flag, and
present if they also have a non-reject exit policy.
Requiring a threshold of usable descriptors avoids directories trickling
exit descriptors to clients to discover their ExitNodes settings.
Part of 27236.
|
|
Previously, Tor would only check the exit flag. In small networks, Tor
could bootstrap once it received a consensus with exits, without fetching
the new descriptors for those exits.
After bootstrap, Tor delays descriptor fetches, leading to failures in
fast networks like chutney.
Fixes 27236; bugfix on 0.2.6.3-alpha.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When we fixed 25939 in f7633c1fcaefe72bf97c001bab9062132c919996, we
introduced a call to rescan_periodic_events() from inside the onion
service logic. But this meant that we could rescan the event list --
thereby running event callbacks! -- from inside the hidden service code.
This could cause us to run some of our event callbacks from an
inconsistent state, if we were in the middle of changing options.
A related bug (#25761) prevented us from rescanning our periodic
events as appropriate, but when we fixed THAT one, this bug reared
its ugly head.
The fix here is that "enabling" an event should cause us to run it
from the event loop, but not immediately from the point where we
enable it.
Fixes bug 27003; bugfix on 0.3.4.1-alpha.
|
|
We would usually call it through tor_cleanup(), but in some code
paths, we wouldn't. These paths would break restart-in-process,
since leaving fields uncleared would cause assertion failures on
restart.
Fixes bug 26948; bugfix on 0.3.3.1-alpha
|
|
|
|
|
|
|
|
|
|
Improve the log message when connection initiators fail to authenticate
direct connections to relays.
Fixes bug 26927; bugfix on 0.3.0.1-alpha.
|
|
|
