summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2011-04-27 13:33:38 -0400
committerNick Mathewson <nickm@torproject.org>2011-04-27 13:33:38 -0400
commitc49f660c1a9f196c8cbb4863bb377bdb6e642539 (patch)
tree8c72f6ab38ca44852c7a05940308a06af7d03ee1
parent748350ace11fa55758fb8bafe5e5556867dd9c23 (diff)
downloadtor-c49f660c1a9f196c8cbb4863bb377bdb6e642539.tar.gz
tor-c49f660c1a9f196c8cbb4863bb377bdb6e642539.zip
Add a big changelog entry for bug 1090 fixes
-rw-r--r--changes/bug1090-general73
1 files changed, 73 insertions, 0 deletions
diff --git a/changes/bug1090-general b/changes/bug1090-general
new file mode 100644
index 0000000000..465631592c
--- /dev/null
+++ b/changes/bug1090-general
@@ -0,0 +1,73 @@
+ o Major features and bugfixes (node selection)
+
+ - Revise and unify the meaning of the ExitNodes, EntryNodes,
+ ExcludeEntryNodes, ExcludeExitNodes, ExcludeNodes, and
+ StrictNodes options. Previously, we had been ambiguous in
+ describing what counted as an "exit" node, and what operations
+ exactly "StrictNodes 0" would permit. This created confusion
+ when people saw nodes built through unexpected circuits, and
+ made it hard to tell real bugs from surprises. We now stipulate
+ that the intended behavior is:
+
+ . "Exit", in the context of ExitNodes and ExcludeExitNodes,
+ means a node that delivers user traffic outside the Tor
+ network.
+ . "Entry", in the context of EntryNodes and ExcludeEntryNodes,
+ means a node used as the first hop of a multihop circuit:
+ it doesn't include direct connections to directory servers.
+ . "ExcludeNodes" applies to all nodes.
+ . "StrictNodes" changes the behavior of ExcludeNodes only.
+ When StrictNodes is set, Tor should avoid all nodes listed
+ in ExcludeNodes, even when it will make user requests
+ fail. When StrictNodes is *not* set, then Tor should
+ follow ExcludeNodes whenever it can, except when it must
+ use an excluded node to perform self-tests, connect to a
+ hidden service, provide a hidden service, fulfill a .exit
+ request, upload directory information, or fetch directory
+ information.
+
+ Collectively, the changes to implement the behavior are a fix for
+ bug 1090.
+
+ - ExcludeNodes now takes precedence over EntryNodes and ExitNodes:
+ if a node is listed in both, it's treated as excluded.
+
+ - ExcludeNodes now applies to directory nodes: as a preference if
+ StrictNodes is 0, or an absolute requirement if StrictNodes is 1.
+ (Don't exclude all the directory authorities and set StrictNodes
+ to 1 unless you really want your Tor to break.)
+
+ - ExcludeNodes and ExcludeExitNodes now override exit enclaving.
+
+ - ExcludeExitNodes now overrides .exit requests.
+
+ - We don't use bridges from ExcludeNodes.
+
+ - When StrictNodes is 1:
+ . We now apply ExcludeNodes to hidden service introduction points
+ and to rendezvous points selected by hidden service users.
+ This can make your hidden service less reliable: use it with
+ caution!
+ . If we have used ExcludeNodes on ourself, do not try self-tests.
+ . If we have excluded all the directory authorities, we will
+ not even try to upload our descriptor if we're a server.
+ . Do not honor .exit requests to an excluded node.
+
+ - Remove a misfeature that caused us to ignore the Fast/Stable flags
+ if ExitNodes was set. Bugfix on 0.2.2.7-alpha.
+
+ - When the set of permitted nodes changes, we now remove any
+ mappings introduced via TrackExitHosts to now-excluded nodes.
+ Bugfix on 0.1.0.1-rc.
+
+ - We never cannibalize a circuit that had excluded nodes on it,
+ even if StrictNodes is 0. Bugfix on 0.1.0.1-rc.
+
+ - Improve log messages related to excluded nodes.
+
+ - Revert a change where we would be laxer about attaching streams to
+ circuits than when building the circuits. This was meant to
+ prevent a set of bugs where streams were never attachable, but our
+ improved code here should make this unnecessary. Bugfix on
+ 0.2.2.7-alpha.
+