| Age | Commit message (Collapse) | Author |
|---|
|
On failure to upload, the HS_DESC event would report "UPLOAD_FAILED" as the
Action but it should have reported "FAILED" according to the spec.
Fixes #24230
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
This was accidentally reintroduced in 5a46074e55. It should be
harmless, though: the option is obsolete, so calling it deprecated
is redundant.
|
|
|
|
|
|
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>
|
|
|
|
When we have fewer than 15 descriptors to fetch, we will delay the
fetch for a little while. That's fine, if we can go ahead and build
circuits... but if not, it's a poor choice indeed.
Fixes bug 23985; bugfix on 0.1.1.11-alpha.
In 0.3.0.3-alpha, when we made primary guard descriptors necessary
for circuit building, this situation got worse.
|
|
|
|
|
|
|
|
Cleanup after 23318.
|
|
Cleanup after 23318.
|
|
Fixes bug 24170; bugfix on 0.2.4.3-alpha.
|
|
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.
Fixes bug 23318; bugfix on 0.2.4.10-alpha.
|
|
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
Fixes bug 23318; bugfix on 0.2.4.3-alpha.
|
|
Closes #24134
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
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>
|
|
|
|
This patch has implementations of the "decorrelated" and "full"
algorithms from https://www.awsarchitectureblog.com/2015/03/backoff.html
|
|
This reverts commit 01e984870a7e1db2722e85fe43af7bcb4755c2d4.
|
|
|
|
|
|
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>
|
|
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>
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Thanks to Dhalgren who analyzed this issue two years ago and found a
solution!
|
|
|
|
Once again allow the flag to be set, unless the default network is used.
Thanks to nickm for a suggestion for the workaround to a test failure.
|
|
|
|
This reverts commit 27fa4a98d23972213122fa99499efa4baebe49e3.
|
|
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>
|
|
|
|
Just in case we end up hitting a SCHED_BUG() multiple times, rate limit the
log warning.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
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>
|
|
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.
Requires chutney master 61c28b9 or later.
Closes ticket 24109.
|
|
|
|
|
|
|
|
Part of #23820.
|
|
They are not yet implemented: they will upload descriptors, but won't be
able to rendezvous, because IPv6 addresses in link specifiers are ignored.
Part of #23820.
|
|
Diagnostics for #23820.
|
