The point of this function is to make sure that the ed25519-based
implementation of curve25519_basepoint() actually works when we
start tor, and use the regular fallback implementation if it
doesn't. But it accounts for 9% of our startup time in the case
when we have directory information, and I think it's safe to make
the test shorter. After all, it has yet to find any actual bugs in
curved25519_scalarmult_basepoint_donna() on any platforms.
Closes ticket 28838.
Add the bootstrap tag name to the log messages, so people
troubleshooting connection problems can look up a symbol instead of a
number. Closes ticket 28731.
Merge Phoul's two lists into teor's list.
Replace the 150 fallbacks originally introduced in Tor 0.3.3.1-alpha in
January 2018 (of which ~115 were still functional), with a list of
157 fallbacks (92 new, 65 existing, 85 removed) generated in
December 2018.
Closes ticket 24803.
Replace the 150 fallbacks originally introduced in Tor 0.3.3.1-alpha in
January 2018 (of which ~115 were still functional), with a list of
148 fallbacks (89 new, 59 existing, 91 removed) generated in
December 2018.
Closes ticket 24803.
If a relay matches at least one fingerprint, IPv4 address, or IPv6
address in the fallback whitelist, it can become a fallback. This
reduces the work required to keep the list up to date.
Closes ticket 28768.
Tor clients on 0.3.5.6-rc? and later will use a consensus that will become
valid up to 24 hours in the future.
Clients on 0.3.5.5-alpha? and earlier won't accept future consensuses.
Update the fallback expiry tolerance to match tor's checks.
Part of 28768, follow-up on 28591.
Tor clients will use a consensus that expired up to 24 hours ago.
Clients on 0.3.5.5-alpha? and earlier won't select guards from an expired
consensus, but they can still bootstrap if they have existing guards.
Update the fallback expiry tolerance to match tor's checks.
Part of 28768, follow-up on 24661.
When retrying all SOCKS connection because new directory information just
arrived, do not BUG() if a connection in state AP_CONN_STATE_RENDDESC_WAIT is
found to have a usable descriptor.
There is a rare case when this can happen as detailed in #28669 so the right
thing to do is put that connection back in circuit wait state so the
descriptor can be retried.
Fixes#28669
Signed-off-by: David Goulet <dgoulet@torproject.org>
Removing a ".auth" file revokes a client access to the service but the
rendezvous circuit is not closed service side because the service simply
doesn't know which circuit is for which client.
This commit notes in the man page that to fully revoke a client access to the
service, the tor process should be restarted.
Closes#28275
Signed-off-by: David Goulet <dgoulet@torproject.org>