Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Conflicts:
	doc/Makefile.am
	doc/spec/Makefile.am
	doc/spec/address-spec.txt
	doc/spec/bridges-spec.txt
	doc/spec/control-spec-v0.txt
	doc/spec/control-spec.txt
	doc/spec/dir-spec-v1.txt
	doc/spec/dir-spec-v2.txt
	doc/spec/dir-spec.txt
	doc/spec/path-spec.txt
	doc/spec/proposals/000-index.txt
	doc/spec/proposals/001-process.txt
	doc/spec/proposals/098-todo.txt
	doc/spec/proposals/099-misc.txt
	doc/spec/proposals/100-tor-spec-udp.txt
	doc/spec/proposals/101-dir-voting.txt
	doc/spec/proposals/102-drop-opt.txt
	doc/spec/proposals/103-multilevel-keys.txt
	doc/spec/proposals/104-short-descriptors.txt
	doc/spec/proposals/105-handshake-revision.txt
	doc/spec/proposals/106-less-tls-constraint.txt
	doc/spec/proposals/107-uptime-sanity-checking.txt
	doc/spec/proposals/108-mtbf-based-stability.txt
	doc/spec/proposals/109-no-sharing-ips.txt
	doc/spec/proposals/110-avoid-infinite-circuits.txt
	doc/spec/proposals/111-local-traffic-priority.txt
	doc/spec/proposals/112-bring-back-pathlencoinweight.txt
	doc/spec/proposals/113-fast-authority-interface.txt
	doc/spec/proposals/114-distributed-storage.txt
	doc/spec/proposals/115-two-hop-paths.txt
	doc/spec/proposals/116-two-hop-paths-from-guard.txt
	doc/spec/proposals/117-ipv6-exits.txt
	doc/spec/proposals/118-multiple-orports.txt
	doc/spec/proposals/119-controlport-auth.txt
	doc/spec/proposals/120-shutdown-descriptors.txt
	doc/spec/proposals/121-hidden-service-authentication.txt
	doc/spec/proposals/122-unnamed-flag.txt
	doc/spec/proposals/123-autonaming.txt
	doc/spec/proposals/124-tls-certificates.txt
	doc/spec/proposals/125-bridges.txt
	doc/spec/proposals/126-geoip-reporting.txt
	doc/spec/proposals/127-dirport-mirrors-downloads.txt
	doc/spec/proposals/128-bridge-families.txt
	doc/spec/proposals/129-reject-plaintext-ports.txt
	doc/spec/proposals/130-v2-conn-protocol.txt
	doc/spec/proposals/131-verify-tor-usage.txt
	doc/spec/proposals/132-browser-check-tor-service.txt
	doc/spec/proposals/134-robust-voting.txt
	doc/spec/proposals/135-private-tor-networks.txt
	doc/spec/proposals/137-bootstrap-phases.txt
	doc/spec/proposals/138-remove-down-routers-from-consensus.txt
	doc/spec/proposals/140-consensus-diffs.txt
	doc/spec/proposals/141-jit-sd-downloads.txt
	doc/spec/proposals/142-combine-intro-and-rend-points.txt
	doc/spec/proposals/143-distributed-storage-improvements.txt
	doc/spec/proposals/145-newguard-flag.txt
	doc/spec/proposals/146-long-term-stability.txt
	doc/spec/proposals/147-prevoting-opinions.txt
	doc/spec/proposals/148-uniform-client-end-reason.txt
	doc/spec/proposals/149-using-netinfo-data.txt
	doc/spec/proposals/150-exclude-exit-nodes.txt
	doc/spec/proposals/151-path-selection-improvements.txt
	doc/spec/proposals/152-single-hop-circuits.txt
	doc/spec/proposals/153-automatic-software-update-protocol.txt
	doc/spec/proposals/154-automatic-updates.txt
	doc/spec/proposals/155-four-hidden-service-improvements.txt
	doc/spec/proposals/156-tracking-blocked-ports.txt
	doc/spec/proposals/157-specific-cert-download.txt
	doc/spec/proposals/158-microdescriptors.txt
	doc/spec/proposals/159-exit-scanning.txt
	doc/spec/proposals/ideas/xxx-hide-platform.txt
	doc/spec/proposals/ideas/xxx-port-knocking.txt
	doc/spec/proposals/ideas/xxx-separate-streams-by-port.txt
	doc/spec/proposals/ideas/xxx-what-uses-sha1.txt
	doc/spec/proposals/reindex.py
	doc/spec/rend-spec.txt
	doc/spec/socks-extensions.txt
	doc/spec/tor-spec.txt
	doc/spec/version-spec.txt

1 files changed, 0 insertions, 283 deletions

diff --git a/doc/spec/proposals/101-dir-voting.txt b/doc/spec/proposals/101-dir-voting.txt
deleted file mode 100644
index 634d3f194..000000000
--- a/doc/spec/proposals/101-dir-voting.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-Filename: 101-dir-voting.txt
-Title: Voting on the Tor Directory System
-Author: Nick Mathewson
-Created: Nov 2006
-Status: Closed
-Implemented-In: 0.2.0.x
-
-Overview
-
-  This document describes a consensus voting scheme for Tor directories;
-  instead of publishing different network statuses, directories would vote on
-  and publish a single "consensus" network status document.
-
-  This is an open proposal.
-
-Proposal:
-
-0. Scope and preliminaries
-
-  This document describes a consensus voting scheme for Tor directories.
-  Once it's accepted, it should be merged with dir-spec.txt.  Some
-  preliminaries for authority and caching support should be done during
-  the 0.1.2.x series; the main deployment should come during the 0.2.0.x
-  series.
-
-0.1. Goals and motivation: voting.
-
-  The current directory system relies on clients downloading separate
-  network status statements from the caches signed by each directory.
-  Clients download a new statement every 30 minutes or so, choosing to
-  replace the oldest statement they currently have.
-
-  This creates a partitioning problem: different clients have different
-  "most recent" networkstatus sources, and different versions of each
-  (since authorities change their statements often).
-
-  It also creates a scaling problem: most of the downloaded networkstatus
-  are probably quite similar, and the redundancy grows as we add more
-  authorities.
-
-  So if we have clients only download a single multiply signed consensus
-  network status statement, we can:
-       - Save bandwidth.
-       - Reduce client partitioning
-       - Reduce client-side and cache-side storage
-       - Simplify client-side voting code (by moving voting away from the
-         client)
-
-  We should try to do this without:
-       - Assuming that client-side or cache-side clocks are more correct
-         than we assume now.
-       - Assuming that authority clocks are perfectly correct.
-       - Degrading badly if a few authorities die or are offline for a bit.
-
-  We do not have to perform well if:
-      - No clique of more than half the authorities can agree about who
-        the authorities are.
-
-1. The idea.
-
-  Instead of publishing a network status whenever something changes,
-  each authority instead publishes a fresh network status only once per
-  "period" (say, 60 minutes).  Authorities either upload this network
-  status (or "vote") to every other authority, or download every other
-  authority's "vote" (see 3.1 below for discussion on push vs pull).
-
-  After an authority has (or has become convinced that it won't be able to
-  get) every other authority's vote, it deterministically computes a
-  consensus networkstatus, and signs it.  Authorities download (or are
-  uploaded; see 3.1) one another's signatures, and form a multiply signed
-  consensus.  This multiply-signed consensus is what caches cache and what
-  clients download.
-
-  If an authority is down, authorities vote based on what they *can*
-  download/get uploaded.
-
-  If an authority is "a little" down and only some authorities can reach
-  it, authorities try to get its info from other authorities.
-
-  If an authority computes the vote wrong, its signature isn't included on
-  the consensus.
-
-  Clients use a consensus if it is "trusted": signed by more than half the
-  authorities they recognize. If clients can't find any such consensus,
-  they use the most recent trusted consensus they have. If they don't
-  have any trusted consensus, they warn the user and refuse to operate
-  (and if DirServers is not the default, beg the user to adapt the list
-  of authorities).
-
-2. Details.
-
-2.0. Versioning
-
-  All documents generated here have version "3" given in their
-  network-status-version entries.
-
-2.1. Vote specifications
-
-  Votes in v3 are similar to v2 network status documents.  We add these
-  fields to the preamble:
-
-     "vote-status" -- the word "vote".
-
-     "valid-until" -- the time when this authority expects to publish its
-        next vote.
-
-     "known-flags" -- a space-separated list of flags that will sometimes
-        be included on "s" lines later in the vote.
-
-     "dir-source" -- as before, except the "hostname" part MUST be the
-        authority's nickname, which MUST be unique among authorities, and
-        MUST match the nickname in the "directory-signature" entry.
-
-  Authorities SHOULD cache their most recently generated votes so they
-  can persist them across restarts.  Authorities SHOULD NOT generate
-  another document until valid-until has passed.
-
-  Router entries in the vote MUST be sorted in ascending order by router
-  identity digest.  The flags in "s" lines MUST appear in alphabetical
-  order.
-
-  Votes SHOULD be synchronized to half-hour publication intervals (one
-  hour? XXX say more; be more precise.)
-
-  XXXX some way to request older networkstatus docs?
-
-2.2. Consensus directory specifications
-
-  Consensuses are like v3 votes, except for the following fields:
-
-     "vote-status" -- the word "consensus".
-
-     "published" is the latest of all the published times on the votes.
-
-     "valid-until" is the earliest of all the valid-until times on the
-       votes.
-
-     "dir-source" and "fingerprint" and "dir-signing-key" and "contact"
-       are included for each authority that contributed to the vote.
-
-     "vote-digest" for each authority that contributed to the vote,
-       calculated as for the digest in the signature on the vote. [XXX
-       re-English this sentence]
-
-     "client-versions" and "server-versions" are sorted in ascending
-       order based on version-spec.txt.
-
-     "dir-options" and "known-flags" are not included.
-[XXX really? why not list the ones that are used in the consensus?
-For example, right now BadExit is in use, but no servers would be
-labelled BadExit, and it's still worth knowing that it was considered
-by the authorities. -RD]
-
-  The fields MUST occur in the following order:
-     "network-status-version"
-     "vote-status"
-     "published"
-     "valid-until"
-     For each authority, sorted in ascending order of nickname, case-
-     insensitively:
-         "dir-source", "fingerprint", "contact", "dir-signing-key",
-         "vote-digest".
-     "client-versions"
-     "server-versions"
-
-  The signatures at the end of the document appear as multiple instances
-  of directory-signature, sorted in ascending order by nickname,
-  case-insensitively.
-
-  A router entry should be included in the result if it is included by more
-  than half of the authorities (total authorities, not just those whose votes
-  we have).  A router entry has a flag set if it is included by more than
-  half of the authorities who care about that flag.  [XXXX this creates an
-  incentive for attackers to DOS authorities whose votes they don't like.
-  Can we remember what flags people set the last time we saw them? -NM]
-  [Which 'we' are we talking here? The end-users never learn which
-  authority sets which flags. So you're thinking the authorities
-  should record the last vote they saw from each authority and if it's
-  within a week or so, count all the flags that it advertised as 'no'
-  votes? Plausible. -RD]
-
-  The signature hash covers from the "network-status-version" line through
-  the characters "directory-signature" in the first "directory-signature"
-  line.
-
-  Consensus directories SHOULD be rejected if they are not signed by more
-  than half of the known authorities.
-
-2.2.1. Detached signatures
-
-  Assuming full connectivity, every authority should compute and sign the
-  same consensus directory in each period.  Therefore, it isn't necessary to
-  download the consensus computed by each authority; instead, the authorities
-  only push/fetch each others' signatures.  A "detached signature" document
-  contains a single "consensus-digest" entry and one or more
-  directory-signature entries. [XXXX specify more.]
-
-2.3. URLs and timelines
-
-2.3.1. URLs and timeline used for agreement
-
-  An authority SHOULD publish its vote immediately at the start of each voting
-  period.  It does this by making it available at
-     http://<hostname>/tor/status-vote/current/authority.z
-  and sending it in an HTTP POST request to each other authority at the URL
-     http://<hostname>/tor/post/vote
-
-  If, N minutes after the voting period has begun, an authority does not have
-  a current statement from another authority, the first authority retrieves
-  the other's statement.
-
-  Once an authority has a vote from another authority, it makes it available
-  at
-      http://<hostname>/tor/status-vote/current/<fp>.z
-  where <fp> is the fingerprint of the other authority's identity key.
-
-  The consensus network status, along with as many signatures as the server
-  currently knows, should be available at
-      http://<hostname>/tor/status-vote/current/consensus.z
-  All of the detached signatures it knows for consensus status should be
-  available at:
-      http://<hostname>/tor/status-vote/current/consensus-signatures.z
-
-  Once an authority has computed and signed a consensus network status, it
-  should send its detached signature to each other authority in an HTTP POST
-  request to the URL:
-      http://<hostname>/tor/post/consensus-signature
-
-
-  [XXXX Store votes to disk.]
-
-2.3.2. Serving a consensus directory
-
-  Once the authority is done getting signatures on the consensus directory,
-  it should serve it from:
-      http://<hostname>/tor/status/consensus.z
-
-  Caches SHOULD download consensus directories from an authority and serve
-  them from the same URL.
-
-2.3.3. Timeline and synchronization
-
-  [XXXX]
-
-2.4. Distributing routerdescs between authorities
-
-  Consensus will be more meaningful if authorities take steps to make sure
-  that they all have the same set of descriptors _before_ the voting
-  starts.  This is safe, since all descriptors are self-certified and
-  timestamped: it's always okay to replace a signed descriptor with a more
-  recent one signed by the same identity.
-
-  In the long run, we might want some kind of sophisticated process here.
-  For now, since authorities already download one another's networkstatus
-  documents and use them to determine what descriptors to download from one
-  another, we can rely on this existing mechanism to keep authorities up to
-  date.
-
-  [We should do a thorough read-through of dir-spec again to make sure
-  that the authorities converge on which descriptor to "prefer" for
-  each router. Right now the decision happens at the client, which is
-  no longer the right place for it. -RD]
-
-3. Questions and concerns
-
-3.1. Push or pull?
-
-  The URLs above define a push mechanism for publishing votes and consensus
-  signatures via HTTP POST requests, and a pull mechanism for downloading
-  these documents via HTTP GET requests.  As specified, every authority will
-  post to every other.  The "download if no copy has been received" mechanism
-  exists only as a fallback.
-
-4. Migration
-
-     * It would be cool if caches could get ready to download consensus
-       status docs, verify enough signatures, and serve them now.  That way
-       once stuff works all we need to do is upgrade the authorities.  Caches
-       don't need to verify the correctness of the format so long as it's
-       signed (or maybe multisigned?).  We need to make sure that caches back
-       off very quickly from downloading consensus docs until they're
-       actually implemented.
-