Remove various outdated documents.

doc/TODO and doc/spec/README were placeholders to tell people where to
look for the real TODO and README stuff -- we replaced them years ago,
though.

authority-policy, v3-authority-howto, and torel-design.txt belong in
torspec.  I'm putting them in attic there since I think they may be in
large part obsolete, but someone can rescue them if they're not.

translations.txt is outdated, and refers to lots of programs other
than Tor.  We have much better translation resources on the website
now.

tor-win32-mingw-creation.txt is pending review of a revised version
for 0.2.5 (see ticket #4520), but there's no reason to ship this one
while we're waiting for an accurate version.

the tor-rpm-creation.txt isn't obsolete AFAIK, but it belongs in
doc/contrib if anywhere.

Resolves bug #8965.

3 files changed, 56 insertions, 270 deletions

diff --git a/doc/contrib/authority-policy.txt b/doc/contrib/authority-policy.txt
deleted file mode 100644
index 7072082d1..000000000
--- a/doc/contrib/authority-policy.txt
+++ /dev/null
@@ -1,89 +0,0 @@
-
-0. Overview.
-
-   This document contains various informal policies for how to operate
-   a directory authority, how to choose new ones, etc.
-
-1. How to pick a new directory authority.
-
-   Here's our current guidelines for how to pick new directory
-   authorities.
-
-   (These won't ever be formal criteria -- we need to keep this flexible
-   so we can adapt to new situations.)
-
-   o Stability:
-     - Must be a low-downtime Tor server (computer as well as network).
-     - Must have a static IP.
-     - The operator must have been running a stable Tor server for at least
-       3 months.
-     - Must intend for this server to stick around for the next 12 months
-       or more.
-     - Must not hibernate.
-     - Should not be an exit node (as this increases the risk both of
-       downtime and of key compromise).
-
-   o Performance:
-     - Must have sufficient bandwidth: at least 10mbit/s symmetric,
-       though in practice the inbound traffic can be considerably less.
-
-   o Availability:
-     - Must be available to upgrade within a few days in most cases.
-       (While we're still developing Tor, we periodically find bugs that
-       impact the whole network and require authority upgrades.)
-     - Should have a well-known way to contact the administrator
-       via PGP-encrypted message.
-
-   o Integrity:
-     - Must promise not to censor or attack the network and users.
-     - Should be run by somebody that Tor (i.e. Roger) knows.
-     - Should be widely regarded as fair/trustworthy, or at least
-       known, by many people.
-     - If somebody asks you to backdoor or change your server, legally or
-       otherwise, you will fight it to the extent of your abilities. If
-       you fail to fight it, you must shut down the Tor server and notify
-       us that you have.
-
-   o Diversity
-     - We should avoid situations that make it likelier for multiple
-       authority failures to happen at the same time.  Therefore...
-       - It's good when authorities are not all in the same country.
-       - It's good when authorities are not all in the same jurisdictions.
-       - It's good when authorities are not all running the same OS.
-       - It's good when authorities are not all using the same ISP.
-       - It's good when authorities are not all running the same
-         version of Tor.
-       - No two authorities should have the same operator.
-     - Maximal diversity, however, is not always practical.  Sometimes,
-       for example, there is only one version of Tor that provides a
-       given consensus generation algorithm.
-     - A small group of authorities with the same country/jurisdiction/OS is
-       not a problem, until that group's size approaches quorum (half the
-       authorities).
-
-2. How to choose the recommended versions
-
-  The policy, in a nutshell, is to not remove versions without a good
-  reason. So this means we should recommend all versions except:
-
-  - Versions that no longer conform to the spec. That is, if they wouldn't
-    actually interact correctly with the current Tor network.
-  - Versions that have known security problems.
-  - Versions that have frequent crash or assert problems.
-  - Versions that harm the performance or stability of the current Tor
-    network or the anonymity of other users. For example, a version
-    that load balances wrong, or a version that hammers the authorities
-    too much.
-
-
-> some use the slight variant of requiring a *good* reason.
-> excellent reasons include "there's a security flaw"
-> good reasons include "that crashes every time you start it. you would think
-+tor is dumb if you tried to use that version and think of it as tor."
-> good reasons include "those old clients do their load balancing wrong, and
-+they're screwing up the whole network"
-> reasons include "the old one is really slow, clients should prefer the new
-+one"
-> i try to draw the line at 'good reasons and above'
-
-
diff --git a/doc/contrib/tor-rpm-creation.txt b/doc/contrib/tor-rpm-creation.txt
new file mode 100644
index 000000000..a03891e2b
--- /dev/null
+++ b/doc/contrib/tor-rpm-creation.txt
@@ -0,0 +1,56 @@
+## Instructions for building the official rpms.
+##
+The process used to create the official rpms is as follows:
+
+You'll need to install libevent headers, usually located in package named
+libevent-devel. Alternatively, you could download latest libevent from
+http://libevent.org/ but that shouldn't be necessary.
+
+Download and Extract the latest tor source code from
+https://www.torproject.org/download
+
+In the resulting directory:
+LIBS=-lrt ./configure
+make dist-rpm
+
+You should have at least two, maybe three, rpms.  There should be the binary
+(i686|x86_64).rpm, a src.rpm, and on redhat/centos machines, a debuginfo.rpm.
+The debuginfo rpms are created if package redhat-rpm-config is installed (case
+of redhat distros).
+
+This step suffices unless you want to create RPMs for distros other than the
+one you used for building.
+
+
+## Instructions for building RPMs for multiple architectures or distributions
+## using 'mock' on Fedora or RHEL (and clones)
+
+Make sure you have mock installed and configured, see following HOWTOs for setup:
+https://fedoraproject.org/wiki/How_to_create_an_RPM_package
+https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds
+
+Take the source RPM generated by previous step, and execute mock for every
+target architecture (the names come from files in /etc/mock, strip the .cfg
+extension in the -r parameter):
+
+mock --rebuild -r fedora-17-x86_64 tor-X.Y.Z.src.rpm
+
+Building for EL5 from newer distro (e.g. EL6 or Fedora 17) will fail due to bug
+(https://bugzilla.redhat.com/show_bug.cgi?id=490613).
+Here's a workaround:
+
+Before even building the source RPM, install fedora-packager and instruct
+the build system to use rpmbuild-md5 like this:
+
+yum install fedora-packager
+export RPMBUILD=rpmbuild-md5
+
+Then proceed as usual to create the source RPM and binary RPMs:
+
+LIBS=-lrt ./configure
+make dist-rpm
+mock --rebuild -r epel-5-x86_64 tor-X.Y.Z.src.rpm
+
+
+(Note: don't build under OpenVZ - it breaks unshare() syscall, which in turn
+breaks mock. It could save you several hours.)
diff --git a/doc/contrib/torel-design.txt b/doc/contrib/torel-design.txt
deleted file mode 100644
index 610cbe21f..000000000
--- a/doc/contrib/torel-design.txt
+++ /dev/null
@@ -1,181 +0,0 @@
-Design For A Tor DNS-based Exit List
-
-Status:
-
-  This is a suggested design for a DNS Exit List (DNSEL) for Tor exit nodes.
-  See http://exitlist.torproject.org/ for an implementation.
-
-Why?
-
-  It's useful for third parties to be able to tell when a given connection
-  is coming from a Tor exit node.  Potential applications range from
-  "anonymous user" cloaks on IRC networks like oftc, to networks like
-  Freenode that apply special authentication rules to users from these
-  IPs, to systems like Wikipedia that may want to make a priority of
-  _unblocking_ shared IPs more liberally than non-shared IPs, since shared
-  IPs presumably have non-abusive users as well as abusive ones.
-
-  Since Tor provides exit policies, not every Tor server will connect to
-  every address:port combination on the Internet.  Unless you're trying to
-  penalize hosts for supporting anonymity, it makes more sense to answer
-  the fine-grained question "which Tor servers will connect to _me_?" than
-  the coarse-grained question "which Tor servers exist?"  The fine-grained
-  approach also helps Tor server ops who share an IP with their Tor
-  server: if they want to access a site that blocks Tor users, they
-  can exclude that site from their exit policy, and the site can learn
-  that they won't send it anonymous connections.
-
-  Tor already ships with a tool (the "contrib/exitlist" script) to
-  identify which Tor nodes might open anonymous connections to any given
-  exit address.  But this is a bit tricky to set up, so only sites like
-  Freenode and OFTC that are dedicated to privacy use it.
-  Conversely, providers of some DNSEL implementations are providing
-  coarse-grained lists of Tor hosts -- sometimes even listing servers that
-  permit no exit connections at all.  This is rather a problem, since
-  support for DNSEL is pretty ubiquitous.
-
-
-How?
-
-  Keep a running Tor instance, and parse the cached-routers and
-  cached-routers.new files as new routers arrive.  To tell whether a given
-  server allows connections to a certain address:port combo, look at the
-  definitions in dir-spec.txt or follow the logic of the current exitlist
-  script. If bug 405 is still open when you work on this
-  (https://bugs.torproject.org/flyspray/index.php?do=details&id=405), you'll
-  probably want to extend it to look at only the newest descriptor for
-  each server, so you don't use obsolete exit policy data.
-
-  FetchUselessDescriptors would probably be a good torrc option to enable.
-
-  If you're also running a directory cache, you get extra-fresh
-  information.
-
-
-The DNS interface
-
-  Standard DNSEL, if I understand right, looks like this: There's some
-  authoritative name server for foo.example.com.  You want to know if
-  1.2.3.4 is in the list, so you query for an A record for
-  4.3.2.1.foo.example.com.  If the record exists and has the value
-  127.0.0.2[DNSBL-EMAIL], 1.2.3.4 is in the list.  If you get an NXDOMAIN
-  error, 1.2.3.4 is not in the list.  If you ask for a domain name outside
-  of the foo.example.com zone, you get a Server Failure error[RFC 1035].
-
-  Assume that the DNSEL answers queries authoritatively for some zone,
-  torhosts.example.com.  Below are some queries that could be supported,
-  though some of them are possibly a bad idea.
-
-
-  Query type 1: "General IP:Port"
-
-    Format:
-        {IP1}.{port}.{IP2}.ip-port.torhosts.example.com
-
-    Rule:
-        Iff {IP1} is a Tor server that permits connections to {port} on
-        {IP2}, then there should be an A record with the value 127.0.0.2.
-
-    Example:
-        "1.0.0.10.80.4.3.2.1.ip-port.torhosts.example.com" should have the
-        value 127.0.0.2 if and only if there is a Tor server at 10.0.0.1
-        that allows connections to port 80 on 1.2.3.4.
-
-    Example use:
-        I'm running an IRC server at w.x.y.z:9999, and I want to tell
-        whether an incoming connection is from a Tor server.  I set
-        up my IRC server to give a special mask to any user coming from
-        an IP listed in 9999.z.y.x.w.ip-port.torhosts.example.com.
-
-        Later, when I get a connection from a.b.c.d, my ircd looks up
-        "d.c.b.a.9999.z.y.x.w.ip-port.torhosts.example.com" to see
-        if it's a Tor server that allows connections to my ircd.
-
-
-  Query type 2: "IP-port group"
-
-    Format:
-        {IP}.{listname}.list.torhosts.example.com
-
-    Rule:
-        Iff this Tor server is configured with an IP:Port list named
-        {listname}, and {IP} is a Tor server that permits connections to
-        any member of {listname}, then there exists an A record.
-
-    Example:
-        Suppose torhosts.example.com has a list of IP:Port called "foo".
-        There is an A record for 4.3.2.1.foo.list.torhosts.example.com
-        if and only if 1.2.3.4 is a Tor server that permits connections
-        to one of the addresses in list "foo".
-
-    Example use:
-        Suppose torhosts.example.com has a list of hosts in "examplenet",
-        a popular IRC network.  Rather than having them each set up to
-        query the appropriate "ip-port" list, they could instead all be
-        set to query a central examplenet.list.torhosts.example.com.
-
-    Problems:
-        We'd be better off if each individual server queried about hosts
-        that allowed connections to itself.  That way, if I wanted to
-        allow anonymous connections to foonet, but I wanted to be able to
-        connect to foonet from my own IP without being marked, I could add
-        just a few foonet addresses to my exit policy.
-
-
-  Query type 3: "My IP, with port"
-
-    Format:
-        {IP}.{port}.me.torhosts.example.com
-
-    Rule:
-        An A record exists iff there is a tor server at {IP} that permits
-        connections to {port} on the host that requested the lookup.
-
-    Example:
-        "4.3.2.1.80.me.torhosts.example.com" should have an A record if
-        and only if there is a Tor server at 1.2.3.4 that allows
-        connections to port 80 of the querying host.
-
-    Example use:
-        Somebody wants to set up a quick-and-dirty Tor detector for a
-        single webserver: just point them at 80.me.torhosts.example.com.
-
-    Problem:
-        This would be easiest to use, but DNS gets in the way. If you
-        create DNS records that give different results depending on who is
-        asking, you mess up caching.  There could be a fix here, but might
-        not.
-
-
-  RECOMMENDATION: Just build ip-port for now, and see what demand is
-  like.  There's no point in building mechanisms nobody wants.
-
-Web interface:
-
-  Should provide the same data as the dns interface.
-
-Other issues:
-
-  After a Tor server op turns off their server, it stops publishing server
-  descriptors. We should consider that server's IP address to still
-  represent a Tor node until 48 hours after its last descriptor was
-  published.
-
-  30-60 minutes is not an unreasonable TTL.
-
-  There could be some demand for address masks and port lists. Address
-  masks wider than /8 make me nervous here, as do port ranges.
-
-  We need an answer for what to do about hosts which exit from different
-  IPs than their advertised IP. One approach would be for the DNSEL
-  to launch periodic requests to itself through all exit servers whose
-  policies allow it -- and then see where the requests actually come from.
-
-References:
-
-  [DNSBL-EMAIL] Levine, J., "DNS Based Blacklists and Whitelists for
-  E-Mail", http://tools.ietf.org/html/draft-irtf-asrg-dnsbl-02, November
-  2005.
-
-  [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
-  Specification", RFC 1035, November 1987.