Make origin-side messages about padding negotiation failure into
LOG_PROTOCOL_WARN.
I'm not sure I like this either.. But the negotiation refusal case might
happen naturally due to consensus drift, and is functionally no different than
a corrupted cell.
There is other code that uses this value, and some of it is
apparently reachable from inside router_dir_info_changed(), which
routerlist_free() apparently calls. (ouch!) This is a minimal fix
to try to resolve the issue without causing other problems.
Fixes bug 31003. I'm calling this a bugfix on 0.1.2.2-alpha, where
the call to router_dir_info_changed() was added to routerlist_free().
Overflowing a signed integer in C is an undefined behaviour.
It is possible to trigger this undefined behaviour in tor_asprintf on
Windows or systems lacking vasprintf.
On these systems, eiter _vscprintf or vsnprintf is called to retrieve
the required amount of bytes to hold the string. These functions can
return INT_MAX. The easiest way to recreate this is the use of a
specially crafted configuration file, e.g. containing the line:
FirewallPorts AAAAA<in total 2147483610 As>
This line triggers the needed tor_asprintf call which eventually
leads to an INT_MAX return value from _vscprintf or vsnprintf.
The needed byte for \0 is added to the result, triggering the
overflow and therefore the undefined behaviour.
Casting the value to size_t before addition fixes the behaviour.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Replace the 157 fallbacks originally introduced in Tor 0.3.5.6-rc
in December 2018 (of which ~122 were still functional), with a
list of 148 fallbacks (70 new, 78 existing, 79 removed) generated
in June 2019.
Closes ticket 28795.
Note that we created extra lists from DE and US, but they didn't add
any more fallbacks when we tried to merge them.
Update the fallback directory mirrors by merging the current list with:
fallback_dirs_2019-06-28-08-58-39_AU_f0437a39ddbc8459.inc
Part of 28795, see that ticket for logs.
Update the fallback directory mirrors by replacing the old list with:
fallback_dirs_2019-06-25-11-49-10_AU_a37adb956fbb5cd2.inc
Part of 28795, see that ticket for logs.
When we consider all circuits in "waiting for guard" state to be promoted to
an "open" state, we were considering all circuits, even the one marked for
close.
This ultiamtely triggers a "circuit_has_opened()" called on the circuit that
is marked for close which then leads to possible undesirable behaviors within
a subsystem.
For instance, the HS subsystem would be unable to find the authentication key
of the introduction point circuit leading to a BUG() warning and a duplicate
mark for close on the circuit.
This commit also adds a unit test to make sure we never select marked for
close circuits when upgrading its guard state from waiting for guard to open.
Fixes#30871
Signed-off-by: David Goulet <dgoulet@torproject.org>
Previously we had "make check" launched whenever DISTCHECK was
false. Now we'd like to turn it off in a few other circumstances,
like running chutney. Maybe stem too?
Skip test_rebind when the TOR_SKIP_TEST_REBIND environmental variable
is set.
Skip test_rebind on macOS in Travis builds, because it is unreliable
on macOS on Travis.
Fixes bug 30713; bugfix on 0.3.5.1-alpha.
Leave the other rend and hs_ident data around until circuit free, since code
may still try to inspect it after marking the circuit for close. The
circuitmap is the important thing to clean up, since repurposed
intropoints must be removed from this map to ensure validity.
