r8973@Kushana: nickm | 2006-09-28 16:53:19 -0400

 Refactor entry guard status logic a lot; allow more factors [like not
 having a Guard flag or being listed in ExcludeNodes] to render a guard
 "unlisted" (now called "unusable"); track guard down status (now
 called "unreachable") separately from is_running.


svn:r8519

1 files changed, 8 insertions, 1 deletions

diff --git a/ChangeLog b/ChangeLog
index 8e1d7d1a30..91d99252b6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -23,6 +23,10 @@ Changes in version 0.1.2.2-alpha - 2006-??-??
       servers on the same /16" behavior.  It's still on by default; this
       is mostly for people who want to operate private test networks with
       all the machines on the same subnet.
+    - If one of our entry guards is on the ExcludeNodes list, or the
+      directory authorities don't think it's a good guard, treat it as if it
+      were unlisted: stop using it as a guard, and throw it off the guards
+      list if it stays that way for a long time.
 
   o Security Fixes, minor:
     - If a client asked for a server by name, and we didn't have a
@@ -59,13 +63,16 @@ Changes in version 0.1.2.2-alpha - 2006-??-??
       we don't recognize.
     - Avoid a memory corruption bug when creating a hash table for the first
       time.
+    - Track unreachable entry guards correctly: don't conflate 'unreachable
+      by us right now' with 'listed as down by the directory authorities'.
+      With the old code, if a guard was unreachable by us but listed as
+      running, it would clog our guard list forever.
 
   o Documentation
     - Documented (and renamed) ServerDNSSearchDomains and
       ServerDNSResolvConfFile options.
 
 
-
   o Packaging:
     - Patches so Tor builds with MinGW on Windows.
     - The Debian package now uses --verify-config when (re)starting,