changes/bug1090-general

   1   o Major features and bugfixes (node selection)
   2
   3     - Revise and unify the meaning of the ExitNodes, EntryNodes,
   4       ExcludeEntryNodes, ExcludeExitNodes, ExcludeNodes, and
   5       StrictNodes options.  Previously, we had been ambiguous in
   6       describing what counted as an "exit" node, and what operations
   7       exactly "StrictNodes 0" would permit.  This created confusion
   8       when people saw nodes built through unexpected circuits, and
   9       made it hard to tell real bugs from surprises.  We now stipulate
  10       that the intended behavior is:
  11
  12         . "Exit", in the context of ExitNodes and ExcludeExitNodes,
  13            means a node that delivers user traffic outside the Tor
  14            network.
  15         . "Entry", in the context of EntryNodes and ExcludeEntryNodes,
  16           means a node used as the first hop of a multihop circuit:
  17           it doesn't include direct connections to directory servers.
  18         . "ExcludeNodes" applies to all nodes.
  19         . "StrictNodes" changes the behavior of ExcludeNodes only.
  20           When StrictNodes is set, Tor should avoid all nodes listed
  21           in ExcludeNodes, even when it will make user requests
  22           fail.  When StrictNodes is *not* set, then Tor should
  23           follow ExcludeNodes whenever it can, except when it must
  24           use an excluded node to perform self-tests, connect to a
  25           hidden service, provide a hidden service, fulfill a .exit
  26           request, upload directory information, or fetch directory
  27           information.
  28
  29       Collectively, the changes to implement the behavior are a fix for
  30       bug 1090.
  31
  32     - ExcludeNodes now takes precedence over EntryNodes and ExitNodes:
  33       if a node is listed in both, it's treated as excluded.
  34
  35     - ExcludeNodes now applies to directory nodes: as a preference if
  36       StrictNodes is 0, or an absolute requirement if StrictNodes is 1.
  37       (Don't exclude all the directory authorities and set StrictNodes
  38       to 1 unless you really want your Tor to break.)
  39
  40     - ExcludeNodes and ExcludeExitNodes now override exit enclaving.
  41
  42     - ExcludeExitNodes now overrides .exit requests.
  43
  44     - We don't use bridges from ExcludeNodes.
  45
  46     - When StrictNodes is 1:
  47        . We now apply ExcludeNodes to hidden service introduction points
  48          and to rendezvous points selected by hidden service users.
  49          This can make your hidden service less reliable: use it with
  50          caution!
  51        . If we have used ExcludeNodes on ourself, do not try self-tests.
  52        . If we have excluded all the directory authorities, we will
  53          not even try to upload our descriptor if we're a server.
  54        . Do not honor .exit requests to an excluded node.
  55
  56     - Remove a misfeature that caused us to ignore the Fast/Stable flags
  57       if ExitNodes was set.  Bugfix on 0.2.2.7-alpha.
  58
  59     - When the set of permitted nodes changes, we now remove any
  60       mappings introduced via TrackExitHosts to now-excluded nodes.
  61       Bugfix on 0.1.0.1-rc.
  62
  63     - We never cannibalize a circuit that had excluded nodes on it,
  64       even if StrictNodes is 0.  Bugfix on 0.1.0.1-rc.
  65
  66     - Improve log messages related to excluded nodes.
  67
  68     - Revert a change where we would be laxer about attaching streams to
  69       circuits than when building the circuits.  This was meant to
  70       prevent a set of bugs where streams were never attachable, but our
  71       improved code here should make this unnecessary.  Bugfix on
  72       0.2.2.7-alpha.
  73