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.

1 files changed, 0 insertions, 89 deletions

diff --git a/doc/contrib/authority-policy.txt b/doc/contrib/authority-policy.txt
deleted file mode 100644
index 7072082d1b..0000000000
--- 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'
-
-