diff options
Diffstat (limited to 'doc/contrib')
| -rw-r--r-- | doc/contrib/authority-policy.txt | 89 | ||||
| -rw-r--r-- | doc/contrib/tor-rpm-creation.txt | 56 | ||||
| -rw-r--r-- | doc/contrib/torel-design.txt | 181 |
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. |