Hrmm, actually, it appears you mark all guards as made_contact=1 when
you parse the state file in entry_guards_parse_state(), so you can
still add guards and write them out to disk eventually, no?
In actual fact, I still don't fully understand how the list is
actually growing beyond options->NumEntryGuards. I *think* it may have
something to do with the difference between live_entry_guards and
entry_guards, and adding more guards to entry_guards if
live_entry_guards is too small.
Another possibility may be that this UnreachableSince or UnlistedSince
(bad_since).. It seems like it should be possible for a guard to be
marked as unlisted but then be discovered to be listed again, creating
a larger pool of guards than desired.
It seems to me that this whole guard implementation is a little too
complicated for its own good. Really all we want to keep is 2-3 reliable
guard nodes known to be reachable for as long as possible.
So how about this idea instead: Based on the assumption that we want
multiple guards so that circuit failure attacks aren't as deadly, lets
only keep a list of known, live guards, and hard-cap this at 3 nodes
(or NumEntryGuards nodes). If a circuit fails, choose a different
guard from this list for the next circuit (to frustrate circuit
failure attacks). However, if an or_conn to a guard fails (or it
disappears from the directory), mark it as down, but do not remove it
until a connectable replacement is found. Create a tentative_guard
global pointer or something to hold a randomly chosen guard for
replacement. Once the connection is made to this guard, then replace
the downed live_entry_guard entry with this pointer.
This should simplify things quite a good deal, has easy to analyze
properties, and should not have unexpected results.
Thus spake arma@xxxxxxxx (arma@xxxxxxxx):
> Author: arma
> Date: 2007-07-02 18:15:26 -0400 (Mon, 02 Jul 2007)
> New Revision: 10730
>
> Modified:
> tor/trunk/ChangeLog
> tor/trunk/src/or/circuitbuild.c
> Log:
> If there's a never-before-connected-to guard node in our list,
> never choose any guards past it. This way we don't expand our
> guard list unless we need to. [Bugfix in 0.1.2.x]
>
> I'm not sure if this will solve all our problems, but it is at least
> something.
>
>
>
> Modified: tor/trunk/ChangeLog
> ===================================================================
> --- tor/trunk/ChangeLog 2007-07-02 22:07:53 UTC (rev 10729)
> +++ tor/trunk/ChangeLog 2007-07-02 22:15:26 UTC (rev 10730)
> @@ -50,7 +50,12 @@
> - Stop under-counting the number of authorities that recommend each
> version. [Bugfix on 0.1.2.x]
>
> + o Minor bugfixes (guard nodes):
> + - If there's a never-before-connected-to guard node in our list,
> + never choose any guards past it. This way we don't expand our
> + guard list unless we need to. [Bugfix in 0.1.2.x]
>
> +
> Changes in version 0.2.0.2-alpha - 2007-06-02
> o Major bugfixes on 0.2.0.1-alpha:
> - Fix an assertion failure related to servers without extra-info digests.
>
> Modified: tor/trunk/src/or/circuitbuild.c
> ===================================================================
> --- tor/trunk/src/or/circuitbuild.c 2007-07-02 22:07:53 UTC (rev 10729)
> +++ tor/trunk/src/or/circuitbuild.c 2007-07-02 22:15:26 UTC (rev 10730)
> @@ -2418,6 +2418,13 @@
> r = entry_is_live(entry, need_uptime, need_capacity, 0);
> if (r && !smartlist_isin(exit_family, r)) {
> smartlist_add(live_entry_guards, r);
> + if (!entry->made_contact) {
> + /* Always start with the first not-yet-contacted entry
> + * guard. Otherwise we might add several new ones, pick
> + * the second new one, and now we've expanded our entry
> + * guard list without needing to. */
> + goto choose_and_finish;
> + }
> if (smartlist_len(live_entry_guards) >= options->NumEntryGuards)
> break; /* we have enough */
> }
> @@ -2451,6 +2458,7 @@
> /* live_entry_guards may be empty below. Oh well, we tried. */
> }
>
> + choose_and_finish:
> r = smartlist_choose(live_entry_guards);
> smartlist_free(live_entry_guards);
> smartlist_free(exit_family);
--
Mike Perry
Mad Computer Scientist
fscked.org evil labs
Attachment:
pgp3fDrtkh4yK.pgp
Description: PGP signature