backport r16698: don't use a new entry guard that's also your exit

svn:r16729

ChangeLog

@@ -7,6 +7,10 @@ Changes in version 0.2.0.31 - 2008-09-??
       a digest of all zeroes, or asks to extend back to the relay that
       sent the extend cell, tear down the circuit. Ideas suggested
       by rovv.
+    - If not enough of our entry guards are available so we add a new
+      one, we might use the new one even if it overlapped with the
+      current circuit's exit relay (or its family). Anonymity bugfix
+      pointed out by rovv.
 
  o Minor bugfixes:
     - Fix a small alignment and memory-wasting bug on buffer chunks.  Spotted

doc/TODO.020

@@ -13,5 +13,5 @@ Backport for 0.2.0 once better tested:
   - r16143: generate stream close events from connection_edge_destroy().
   o r16450: open /dev/pf before dropping privileges.
   o r16605: relays reject risky extend cells.
-  - r16698: don't use a new entry guard that's also your exit.
+  o r16698: don't use a new entry guard that's also your exit.
 

src/or/circuitbuild.c

@@ -2503,8 +2503,13 @@ choose_random_entry(cpath_build_state_t *state)
        * be a long time til we get it. -RD */
       r = add_an_entry_guard(NULL, 0);
       if (r) {
-        smartlist_add(live_entry_guards, r);
         entry_guards_changed();
+        /* XXX we start over here in case the new node we added shares
+         * a family with our exit node. There's a chance that we'll just
+         * load up on entry guards here, if the network we're using is
+         * one big family. Perhaps we should teach add_an_entry_guard()
+         * to understand nodes-to-avoid-if-possible? -RD */
+        goto retry;
       }
     }
     if (!r && need_uptime) {