This applies only for relays. Previous commit adds two new consensus
parameters that dictate how libevent is configured with DNS resolution.
And so, with a new consensus, we now look at those values in case they
ever change.
Without this, Exit relay would have to HUP or restart to apply any new
Exit DNS consensus parameters.
Related to #40312
Signed-off-by: David Goulet <dgoulet@torproject.org>
Introduces two new consensus parameter:
exit_dns_timeout: Number of seconds before libevent should consider
the DNS request a timeout.
exit_dns_num_attempts: Number of attempts that libeven should retry a
previously failing query before calling it a timeout.
Closes#40312
Signed-off-by: David Goulet <dgoulet@torproject.org>
This code was heavily reused from the previous DNS timeout work done in
ticket #40491 that was removed afterall from our code.
Closes#40560
Signed-off-by: David Goulet <dgoulet@torproject.org>
Due to a possible Guard subsystem recursion, when the HS client gets
notified that the directory information has changed, it must run it in a
seperate mainloop event to avoid such issue.
See the ticket for more information on the recursion. This also fixes a
fatal assert.
Fixes#40579
Signed-off-by: David Goulet <dgoulet@torproject.org>
It is possible to not have the descriptor anymore by the time the
rendezvous circuit opens. Don't BUG() on that.
Instead, when sending the INTRODUCE1 cell, make sure the descriptor we
have (or have just fetched) matches what we setup in the rendezvous
circuit.
If not, the circuit is closed and another one is opened for a retry.
Fixes#40576
Signed-off-by: David Goulet <dgoulet@torproject.org>
Prometheus needs unique labels and so this bug was causing an onion
service with multiple ports to have multiple "port=" label for the
metrics requiring a port label.
Fixes#40581
Signed-off-by: David Goulet <dgoulet@torproject.org>
Prometheus needs unique labels and so this bug was causing an onion
service with multiple ports to have multiple "port=" label for the
metrics requiring a port label.
Fixes#40581
Signed-off-by: David Goulet <dgoulet@torproject.org>
(the idea is that ReleaseNotes is for learning what you get when you
move from one stable to another, whereas ChangeLog is for learning what
changed in each released version of tor.)
It looks like our code actually assumes (by dereferencing it in a
log call) that ed_id will _not_ be NULL, but rather will be a bunch
of zero bytes. Refactor the code accordingly, and stop using NULL
tests on ed_id.
We expect ed_id == NULL here to indicate "no ed id", but other parts
of Tor sometimes use an all-0 ed_id. Here we detect that input and
replace it with what's expected.
The previous code would notice if we were changing from one identity
to another, but not if we were changing from no identity to having
an identity. This problem caused a bug (spotted by cypherpunks in
ticket #40563) where if we created a channel for a circuit request
that doesn't include an Ed25519 identity, we won't be able to use
that channel later for requests that _do_ list Ed25519.
Fix for 40563; bugfix on 0.3.0.1-alpha.
Previously we were using tor_assert() to enforce the documented
invariant here; this commit changes it to use BUG() instead. It
will protect us from crashes if the next commit (on #40563) turns
out to expose a bug somewhere.
