mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2025-02-24 22:58:50 +01:00
2797fd8f68
Previously, we'd just take all the nodes in EntryNodes, see which
ones were already in the guard list, and add the ones that weren't.
There were some problems there, though:
* We'd add _every_ entry in EntryNodes, and add them in the order
they appeared in the routerlist. This wasn't a problem
until we added the ability to give country-code or IP-range
entries in the EntryNodes set, but now that we did, it is.
(Fix: We now shuffle the entry nodes before adding them; only
add up to 10*NumEntryGuards)
* We didn't screen EntryNodes for the Guard flag. That's okay
if the user has specified two or three entry nodes manually,
but if they have listed a whole subcontinent, we should
restrict ourselves to the entries that are currently guards.
(Fix: separate out the new guard from the new non-guard nodes,
and add the Guards first.)
* We'd prepend new EntryNodes _before_ the already configured
EntryNodes. This could lead to churn.
(Fix: don't prepend these.)
This patch also pre-screens EntryNodes entries for
reachableaddresses/excludenodes, even though we check for that
later. This is important now, since we cap the number of entries
we'll add.
10 lines
506 B
Text
10 lines
506 B
Text
o Minor bugfixes:
|
|
- When configuring a large set of nodes in EntryNodes (as with
|
|
'EntryNodes {cc}' or 'EntryNodes 1.1.1.1/16'), choose only a
|
|
random subset to be guards, and choose them in random
|
|
order. Bugfix on 0.2.3.1-alpha; fixes bug 2798.
|
|
|
|
o Minor features:
|
|
- When configuring a large set of nodes in EntryNodes, and there are
|
|
enough of them listed as Guard so that we don't need to consider
|
|
the non-guard entries, prefer the ones listed with the Guard flag.
|