- Apr 15, 2021
-
-
Nick Mathewson authored
-
Nick Mathewson authored
"ours" to avoid version bump.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
- Apr 14, 2021
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
The --include-asn option includes AS numbers in the geoip mapping. The --output-asn option makes the program generate a number-to-name mapping file. Additionally, the script now outputs ?? CC entries for networks that are listed but which have no country known.
-
David Goulet authored
-
David Goulet authored
-
David Goulet authored
-
David Goulet authored
Signed-off-by: David Goulet <dgoulet@torproject.org>
-
- Apr 13, 2021
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
David Goulet authored
Signed-off-by: David Goulet <dgoulet@torproject.org>
-
Fixes #40364 Signed-off-by: David Goulet <dgoulet@torproject.org>
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
- Apr 12, 2021
-
-
David Goulet authored
Signed-off-by: David Goulet <dgoulet@torproject.org>
-
- Apr 08, 2021
-
-
David Goulet authored
This is related to ticket #40360 which found this problem when a Bridge entry with a transport name (let say obfs4) is set without a fingerprint: Bridge obfs4 <IP>:<PORT> cert=<...> iat-mode=0 (Notice, no fingerprint between PORT and "cert=") Problem: commit 09c6d032 added a check in get_sampled_guard_for_bridge() that would return NULL if the selected bridge did not have a valid transport name (that is the Bridge transport name that corresponds to a ClientTransportPlugin). Unfortuantely, this function is also used when selecting our eligible guards which is done *before* the transport list is populated and so the added check for the bridge<->transport name is querying an empty list of transports resulting in always returning NULL. For completion, the logic is: Pick eligible guards (use bridge(s) if need be) then for those, initiate a connection to the pluggable transport proxy and then populate the transport list once we've connected. Back to get_sampled_guard_for_bridge(). As said earlier, it is used when selecting our eligible guards in a way that prevents us from selecting duplicates. In other words, if that function returns non-NULL, the selection continues considering the bridge was sampled before. But if it returns NULL, the relay is added to the eligible list. This bug made it that our eligible guard list was populated with the *same* bridge 3 times like so (remember no fingerprint): [info] entry_guards_update_primary(): Primary entry guards have changed. New primary guard list is: [info] entry_guards_update_primary(): 1/3: [bridge] ($0000000000000000000000000000000000000000) [info] entry_guards_update_primary(): 2/3: [bridge] ($0000000000000000000000000000000000000000) [info] entry_guards_update_primary(): 3/3: [bridge] ($0000000000000000000000000000000000000000) When tor starts, it will find the bridge fingerprint by connecting to it and will then update the primary guard list by calling entry_guard_learned_bridge_identity() which then goes and update only 1 single entry resulting in this list: [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($<FINGERPRINT>) is still listed. [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed. [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed. And here lies the problem, now tor is stuck attempting to wait for a valid descriptor for at least 2 guards where the second one is a bunch of zeroes and thus tor will never fully bootstraps: [info] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6671/6703). That's ok. We will try to fetch missing descriptors soon. Now, why passing the fingerprint then works? This is because the list of guards contains 3 times the same bridge but they all have a fingerprint and so the descriptor can be found and tor can bootstraps. The solution here is to entirely remove the transport name check in get_sampled_guard_for_bridge() since the transport_list is empty at that point. That way, the eligible guard list only gets 1 entry, the bridge, and can then go on to bootstrap properly. It is OK to do so since when launching a bridge descriptor fetch, we validate that the bridge transport name is OK and thus avoid connecting to a bridge without a ClientTransportPlugin. If we wanted to keep the check in place, we would need to populate the transport_list much earlier and this would require a much bigger refactoring. Fixes #40360 Signed-off-by: David Goulet <dgoulet@torproject.org>
-
George Kadianakis authored
-
George Kadianakis authored
-
George Kadianakis authored
-
- Apr 05, 2021
-
-
George Kadianakis authored
-
- Apr 02, 2021
-
-
Nick Mathewson authored
-
- Mar 29, 2021
-
-
George Kadianakis authored
- Also fix the vector producing script to work with python3.
-
- Mar 28, 2021
-
-
Jigsaw52 authored
-
- Mar 26, 2021
-
-
Jigsaw52 authored
On Linux systems, glob automatically ignores the errors ENOENT and ENOTDIR because they are expected during glob expansion. But BSD systems do not ignore these, resulting in glob failing when globs expand to invalid paths. This is fixed by adding a custom error handler that ignores only these two errors and removing the GLOB_ERR flag as it makes glob fail even if the error handler ignores the error and is unnecessary as the error handler will make glob fail on all other errors anyway.
-
- Mar 24, 2021
-
-
Jigsaw52 authored
-
Roger Dingledine authored
-
Roger Dingledine authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-