David Goulet [Wed, 8 Nov 2017 19:36:04 +0000 (14:36 -0500)]
dirauth: Recalculate voting schedule at first vote
Commit e67f4441eb2646368e3e7cb1bcee403667b786f0 introduced a safeguard against
using an uninitialized voting schedule object. However, the dirvote_act() code
was looking roughly at the same thing to know if it had to compute the timings
before voting with this condition:
if (!voting_schedule.voting_starts) {
...
dirvote_recalculate_timing(options, now);
}
The sr_init() function is called very early and goes through the safeguard
thus the voting schedule is always initilized before the first vote.
That first vote is a crucial one because we need to have our voting schedule
aligned to the "now" time we are about to use for voting. Then, the schedule
is updated when we publish our consensus or/and when we set a new consensus.
From that point on, we only want to update the voting schedule through that
code flow.
This "created_on_demand" is indicating that the timings have been recalculated
on demand by another subsystem so if it is flagged, we know that we need to
ignore its values before voting.
Fixes #24186
Signed-off-by: David Goulet <dgoulet@torproject.org>
teor [Wed, 8 Nov 2017 03:09:50 +0000 (14:09 +1100)]
Use node counts in networks with all zero-bandwidths
When calculating the fraction of nodes that have descriptors, and all
all nodes in the network have zero bandwidths, count the number of nodes
instead.
Nick Mathewson [Fri, 22 Sep 2017 19:29:15 +0000 (15:29 -0400)]
Remove an erroneous 0.5 in compute_weighted_bandwidths()
Back in 0.2.4.3-alpha (e106812a778f537), when we switched from using
double to using uint64 for selecting by bandwidth, I got the math
wrong: I should have used llround(x), or (uint64_t)(x+0.5), but
instead I wrote llround(x+0.5). That means we would always round
up, rather than rounding to the closest integer
David Goulet [Wed, 8 Nov 2017 14:44:39 +0000 (09:44 -0500)]
sched: Ignore closed channel after flushing cells
The flush cells process can close a channel if the connection write fails but
still return that it flushed at least one cell. This is due because the error
is not propagated up the call stack so there is no way of knowing if the flush
actually was successful or not.
Because this would require an important refactoring touching multiple
subsystems, this patch is a bandaid to avoid the KIST scheduler to handle
closed channel in its loop.
Bandaid on #23751.
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Tue, 7 Nov 2017 16:14:45 +0000 (11:14 -0500)]
Add a safe guard to avoid using a zeroed voting schedule
dirvote_get_next_valid_after_time() is the only public function that uses the
voting schedule outside of the dirvote subsystem so if it is zeroed,
recalculate its timing if we can that is if a consensus exists.
Part of #24161
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Tue, 7 Nov 2017 16:08:12 +0000 (11:08 -0500)]
Recalculate voting schedule first when getting a new consensus
Because the HS and SR subsystems can use the voting schedule early (with the
changes in #23623 making the SR subsystem using the static voting schedule
object), we need to recalculate the schedule very early when setting the new
consensus.
Fixes #24161
Signed-off-by: David Goulet <dgoulet@torproject.org>
Nick Mathewson [Sun, 5 Nov 2017 17:21:16 +0000 (12:21 -0500)]
Fix a memory leak on decryption non-failure of v3 hsdesc
If it decrypts something that turns out to start with a NUL byte,
then decrypt_desc_layer() will return 0 to indicate the length of
its result. But 0 also indicates an error, which causes the result
not to be freed by decrypt_desc_layer()'s callers.
Since we're trying to stabilize 0.3.2.x, I've opted for the simpler
possible fix here and made it so that an empty decrypted string will
also count as an error.
Fixes bug 24150 and OSS-Fuzz issue 3994.
The original bug was present but unreachable in 0.3.1.1-alpha. I'm
calling this a bugfix on 0.3.2.1-alpha since that's the first version
where you could actually try to decrypt these descriptors.
David Goulet [Wed, 1 Nov 2017 16:15:15 +0000 (12:15 -0400)]
nodelist: Downgrade warning to protocol warning
The node_get_ed25519_id() warning can actually be triggered by a relay flagged
with NoEdConsensus so instead of triggering a warning on all relays of the
network, downgrade it to protocol warning.
Fixes #24025
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Tue, 3 Oct 2017 18:38:30 +0000 (14:38 -0400)]
sched: Use SCHED_BUG() macro in scheduler
When a BUG() occurs, this macro will print extra information about the state
of the scheduler and the given channel if any. This will help us greatly to
fix future bugs in the scheduler especially when they occur rarely.
Fixes #23753
Signed-off-by: David Goulet <dgoulet@torproject.org>
teor [Wed, 1 Nov 2017 06:13:07 +0000 (17:13 +1100)]
Test that IPv6-only clients can use microdescriptors
When running "make test-network-all", test that IPv6-only clients can use
microdescriptors. IPv6-only microdescriptor client support was fixed in
tor 0.3.0.1-alpha.
teor [Thu, 26 Oct 2017 05:30:24 +0000 (16:30 +1100)]
Remove buggy IPv6 and ed25519 handling from get_lspecs_from_extend_info()
The previous version of this function had the following issues:
* it didn't check if the extend_info contained an IPv6 address,
* it didn't check if the ed25519 identity key was valid.
But we can't add IPv6 support in a bugfix release.
Instead, BUG() if the address is an IPv6 address, so we always put IPv4
addresses in link specifiers. And ignore missing ed25519 identifiers,
rather than generating an all-zero link specifier.
This supports v3 hidden services on IPv4, dual-stack, and IPv6, and
v3 single onion services on IPv4 only.
David Goulet [Wed, 4 Oct 2017 20:22:49 +0000 (16:22 -0400)]
hs-v3: Attempt descriptor refetch when dirinfo changes
When the directory information changes, callback to the HS client subsystem so
it can check if any pending SOCKS connections are waiting for a descriptor. If
yes, attempt a refetch for those.
Fixes #23762
Signed-off-by: David Goulet <dgoulet@torproject.org>
Nick Mathewson [Fri, 27 Oct 2017 18:28:02 +0000 (14:28 -0400)]
In the hsdescv3 fuzzer, replace the decryption function.
The new decryption function performs no decryption, skips the salt,
and doesn't check the mac. This allows us to fuzz the
hs_descriptor.c code using unencrypted descriptor test, and exercise
more of the code.
David Goulet [Fri, 27 Oct 2017 13:16:29 +0000 (09:16 -0400)]
sr: Don't use a dynamic voting schedule
The exposed get_voting_schedule() allocates and return a new object everytime
it is called leading to an awful lot of memory allocation when getting the
start time of the current round which is done for each node in the consensus.
Closes #23623
Signed-off-by: David Goulet <dgoulet@torproject.org>
teor [Thu, 26 Oct 2017 03:47:54 +0000 (14:47 +1100)]
Remove buggy IPv6 support from pick_intro_point() and service_intro_point_new()
The previous version of these functions had the following issues:
* they can't supply both the IPv4 and IPv6 addresses in link specifiers,
* they try to fall back to a 3-hop path when the address for a direct
connection is unreachable, but this isn't supported by
launch_rendezvous_point_circuit(), so it fails.
But we can't fix these things in a bugfix release.
Instead, always put IPv4 addresses in link specifiers.
And if a v3 single onion service can't reach any intro points, fail.
This supports v3 hidden services on IPv4, dual-stack, and IPv6, and
v3 single onion services on IPv4 only.
teor [Thu, 26 Oct 2017 03:38:06 +0000 (14:38 +1100)]
Remove buggy IPv6 support from hs_get_extend_info_from_lspecs()
The previous version of this function has the following issues:
* it doesn't choose between IPv4 and IPv6 addresses correctly, and
* it doesn't fall back to a 3-hop path when the address for a direct
connection is unreachable.
But we can't fix these things in a bugfix release.
Instead, treat IPv6 addresses like any other unrecognised link specifier
and ignore them. If there is no IPv4 address, return NULL.
This supports v3 hidden services on IPv4, dual-stack, and IPv6, and
v3 single onion services on IPv4 only.
David Goulet [Wed, 25 Oct 2017 15:21:28 +0000 (11:21 -0400)]
hs-v2: Copy needed information between service on prunning
Turns out that when reloading a tor configured with hidden service(s), we
weren't copying all the needed information between the old service object to
the new one.
For instance, the desc_is_dirty timestamp wasn't which could lead to the
service uploading its desriptor much later than it would need to.
The replaycache wasn't also moved over and some intro point information as
well.
Fixes #23790
Signed-off-by: David Goulet <dgoulet@torproject.org>
projects / thirdparty / tor.git / log
