aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/TODO3
-rw-r--r--doc/contrib/authority-policy.txt89
-rw-r--r--doc/contrib/tor-rpm-creation.txt (renamed from doc/tor-rpm-creation.txt)0
-rw-r--r--doc/contrib/torel-design.txt181
-rw-r--r--doc/include.am2
-rw-r--r--doc/spec/README11
-rw-r--r--doc/tor-win32-mingw-creation.txt119
-rw-r--r--doc/translations.txt182
-rw-r--r--doc/v3-authority-howto.txt84
9 files changed, 0 insertions, 671 deletions
diff --git a/doc/TODO b/doc/TODO
deleted file mode 100644
index 7e547496e..000000000
--- a/doc/TODO
+++ /dev/null
@@ -1,3 +0,0 @@
-
-We no longer track our TODO lists in git. To see open Tor tasks, visit
-our bugtracker and wiki at trac.torproject.org.
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/tor-rpm-creation.txt b/doc/contrib/tor-rpm-creation.txt
index a03891e2b..a03891e2b 100644
--- a/doc/tor-rpm-creation.txt
+++ b/doc/contrib/tor-rpm-creation.txt
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.
diff --git a/doc/include.am b/doc/include.am
index 9eb919b9e..9695292bd 100644
--- a/doc/include.am
+++ b/doc/include.am
@@ -36,8 +36,6 @@ endif
EXTRA_DIST+= doc/HACKING doc/asciidoc-helper.sh \
$(html_in) $(man_in) $(txt_in) \
- doc/tor-rpm-creation.txt \
- doc/tor-win32-mingw-creation.txt doc/spec/README \
doc/state-contents.txt
docdir = @docdir@
diff --git a/doc/spec/README b/doc/spec/README
deleted file mode 100644
index ccd33a421..000000000
--- a/doc/spec/README
+++ /dev/null
@@ -1,11 +0,0 @@
-The Tor specifications and proposals have moved to a new repository.
-
-To browse the specifications, go to
- https://gitweb.torproject.org/torspec.git/tree
-
-To check out the specification repository, run
- git clone git://git.torproject.org/torspec.git
-
-For other information on the repository, see
- https://gitweb.torproject.org/torspec.git
-
diff --git a/doc/tor-win32-mingw-creation.txt b/doc/tor-win32-mingw-creation.txt
deleted file mode 100644
index 4a25e47a8..000000000
--- a/doc/tor-win32-mingw-creation.txt
+++ /dev/null
@@ -1,119 +0,0 @@
-##
-## Instructions for building Tor with MinGW (http://www.mingw.org/)
-##
-
-Stage One: Download and Install MinGW.
----------------------------------------
-
-Download mingw:
-http://prdownloads.sf.net/mingw/MinGW-5.1.6.exe?download
-
-Download msys:
-http://prdownloads.sf.net/ming/MSYS-1.0.11.exe?download
-
-Download msysDTK:
-http://sourceforge.net/projects/mingw/files/MSYS%20Supplementary%20Tools/msysDTK-1.0.1/msysDTK-1.0.1.exe/download
-
-Install MinGW, msysDTK, and MSYS in that order.
-
-Make sure your PATH includes C:\MinGW\bin. You can verify this by right
-clicking on "My Computer", choose "Properties", choose "Advanced",
-choose "Environment Variables", select PATH.
-
-Start MSYS(rxvt).
-
-Create a directory called "tor-mingw".
-
-Stage Two: Download, extract, compile openssl
-----------------------------------------------
-
-Download openssl:
-http://www.openssl.org/source/openssl-0.9.8l.tar.gz
-
-Extract openssl:
-Copy the openssl tarball into the "tor-mingw" directory.
-Type "cd tor-mingw/"
-Type "tar zxf openssl-0.9.8l.tar.gz"
-(Note: There are many symlink errors because Windows doesn't support
-symlinks. You can ignore these errors.)
-
-Make openssl libraries:
-Type "cd tor-mingw/openssl-0.9.8l/"
-Type "./Configure -no-idea -no-rc5 -no-mdc2 mingw"
-Edit Makefile and remove the "test:" and "tests:" sections.
-Type "rm -rf ./test"
-Type "cd crypto/"
-Type "find ./ -name "*.h" -exec cp {} ../include/openssl/ \;"
-Type "cd ../ssl/"
-Type "find ./ -name "*.h" -exec cp {} ../include/openssl/ \;"
-Type "cd .."
-Type "cp *.h include/openssl/"
-Type "find ./fips -type f -name "*.h" -exec cp {} include/openssl/ \;"
-# The next steps can take up to 30 minutes to complete.
-Type "make"
-Type "make install"
-
-
-Stage Three: Download, extract, compile zlib
----------------------------------------------
-
-Download zlib source:
-http://www.zlib.net/zlib-1.2.3.tar.gz
-
-Extract zlib:
-Copy the zlib tarball into the "tor-mingw" directory
-Type "cd tor-mingw/"
-Type "tar zxf zlib-1.2.3.tar.gz"
-
-CHOICE:
-
-Make zlib.a:
-Type "cd tor-mingw/zlib-1.2.3/"
-Type "./configure"
-Type "make"
-Type "make install"
-
-Done.
-
-
-Stage Four: Download, extract, and compile libevent
-------------------------------------------------------
-
-Download the latest libevent release:
-http://www.monkey.org/~provos/libevent/
-
-Copy the libevent tarball into the "tor-mingw" directory.
-Type "cd tor-mingw"
-
-Extract libevent.
-
-Type "./configure --enable-static --disable-shared"
-Type "make"
-Type "make install"
-
-Stage Five: Build Tor
-----------------------
-
-Download the current Tor alpha release source code from https://torproject.org/download.html.
-Copy the Tor tarball into the "tor-mingw" directory.
-Extract Tor:
-Type "tar zxf latest-tor-alpha.tar.gz"
-
-cd tor-<version>
-Type "./configure"
-Type "make"
-
-You now have a tor.exe in src/or/. This is Tor.
-You now have a tor-resolve.exe in src/tools/.
-
-Stage Six: Build the installer
--------------------------------
-
-Install the latest NSIS:
-http://nsis.sourceforge.net/Download
-
-Run the package script in contrib:
-From the Tor build directory above, run:
-"./contrib/package_nsis-mingw.sh"
-
-The resulting Tor installer executable is in ./win_tmp/.
diff --git a/doc/translations.txt b/doc/translations.txt
deleted file mode 100644
index 06d16f446..000000000
--- a/doc/translations.txt
+++ /dev/null
@@ -1,182 +0,0 @@
-## Instructions for helping translate text for Vidalia, TorButton
-## and TorCheck
-## ( More translation information for Tor related apps will accumulate here )
-
-Our translations are handled in one of two places. The Tor Translation Portal
-handles all of the translations for Vidalia, Torbutton and TorCheck. The Tor
-website itself is currently handled by hand translations using subversion.
-
--------------------------------------------------------------------------
-
-For the Tor website, you'll need a Tor SVN account.
-If you do not have one and you need one, please run this command with your
-desired username in place of 'USERNAME':
- htdigest -c passwd.tmp "Tor subversion repository" USERNAME
-and send us the contents of passwd.tmp.
-
--------------------------------------------------------------------------
-
-For the Portal-based projects, all three check in their respective .po
-files into the following subversion urls:
-
- https://tor-svn.freehaven.net/svn/translation/trunk/projects/torbutton
- https://tor-svn.freehaven.net/svn/translation/trunk/projects/torcheck
- https://svn.vidalia-project.net/svn/vidalia/trunk/src/vidalia/i18n/
-
-The current pootle configuration is checked into subversion as well:
-
- https://tor-svn.freehaven.net/svn/translation/trunk/pootle
-
----------------------------- TorCheck -------------------------------
-
-TorCheck uses our translation portal to accept translations. Users use
-the portal to check in their changes. To make use of the translations
-that users have committed to the translations/ subversion module, you'll
-need to ensure that you have a current checked out copy of TorCheck:
-
- cd check/trunk/i18n/
- check/trunk/i18n$ svn up
-
-You should see something like the following:
-
- Fetching external item into 'pootle'
- External at revision 15300.
-
- At revision 15300.
-
-Now if you had changes, you'd simply want to move the newly updated .po files
-into the current stable directory. Moving the .po files from
-'check/trunk/i18n/pootle/' into 'check/trunk/i18n' properly naming the files
-for their respective locale.
-
-Here's an example of how to move all of the current pootle translations into
-the svn trunk area of TorCheck:
-
- cd check/trunk/i18n/
- for locale in `ls -1 pootle/|grep -v template`;
- do
- mv -v pootle/$locale/TorCheck_$locale.po TorCheck_$locale.po;
- done
-
-Now check the differences (ensure the output looks reasonable):
-
- svn diff
-
-Ensure that msgfmt has no errors:
-
- msgfmt -C *.po
-
-And finally check in the changes:
-
- svn commit
-
----------------------------- Torbutton -------------------------------
-
-Torbutton uses our translation portal to accept translations. Users use
-the portal to check in their changes.
-
-To make use of the translations that users have committed to the translations/
-subversion module, you'll need to ensure that you have a current checked out
-copy of them in your torbutton git checkout:
-
- cd torbutton.git/trans_tools
- torbutton.git/trans_tools$ svn co https://tor-svn.freehaven.net/svn/translation/trunk/projects/torbutton pootle
-
-You should see something like the following:
-
- Checked out revision 21092.
-
-If you made changes to strings in Torbutton, you need to rebuild the
-templates in torbutton.git/trans_tools/pootle/templates. This is done with
-the following command from within the torbutton.git checkout directory:
-
- moz2po -P -i src/chrome/locale/en/ -o trans_tools/pootle/templates/
-
-You now have two options:
-
-Option 1 (The [shitty] Pootle Web UI Way):
-
-View then commit the changes to the template with:
-
- cd trans_tools/pootle
- svn diff templates
- svn commit templates
-
-Then poke Jake to 'svn up' on the Pootle side. If you do this enough
-times, he may give you a button to click to update templates in Pootle,
-or maybe even an account on the Pootle server. Persistence is a virtue.
-
-You then need to go to the Pootle website and click the checkbox next to
-every language on:
-https://translation.torproject.org/projects/torbutton/admin.html
-and then click "Update Languages" at the bottom.
-
-You then need to go to each language and go to "Editing Options" and click
-"Commit" for each one.
-
-You then need to 'svn up' locally, and follow the procedure above for
-rebuilding your .dtd and .properties files.
-
-Yes, this sucks. :/
-
-Option 2 (Use your own msgmerge: YMMV, may change .po flags and formatting):
-
-Run msgmerge yourself for each language:
-
- cd trans_tools
- for i in `ls -1 pootle`
- do
- msgmerge -U ./pootle/$i/torbutton.dtd.po ./pootle/templates/torbutton.dtd.pot
- msgmerge -U ./pootle/$i/torbutton.properties.po ./pootle/templates/torbutton.properties.pot
- done
- svn diff pootle
- svn commit pootle
-
-Then poke Jake to 'svn up' on the Pootle side. If you do this enough times,
-he may give you a button on Pootle, or maybe even an account on the Pootle
-server. Persistence is a virtue.
-
-You may notice that some .po file flags and string formatting have changed
-with this method, depending on your gettext version. It is unclear if this
-is a problem. Please update this doc if you hit a landmine and everything
-breaks :)
-
-After this process is done, you then need to regenerate the mozilla
-.dtd and .properties files as specified above.
-
-
-Regardless of whether or not you had changes in the torbutton strings, if there
-were updated strings in pootle that you checked out from svn you now need to
-convert from .po and move the newly updated mozilla files into the current
-stable locale directory. First convert them with the 'mkmoz.sh' script and
-then move the proper mozilla files from 'torbutton.git/trans_tools/moz/' into
-'torbutton.git/src/chrome/locale/' directory while properly naming the files
-for their respective locale.
-
-Here's an example of how to move all of the current pootle translations into
-the svn trunk area of Torbutton:
-
- cd trans_tools
- ./mkmoz.sh
- for locale in `ls -1 moz/`;
- do
- mv -v moz/$locale/*.{dtd,properties} ../src/chrome/locale/$locale/
- done
-
-Now check the differences to your git branch to ensure the output looks
-reasonable:
-
- cd ..
- git diff
-
-And finally check in the changes:
-
- cd src/chrome/locale
- git commit .
-
----------------------------- Vidalia -------------------------------
-
-Vidalia uses our translation portal to accept translations. Users use the
-portal to check in their changes. No conversion or moving is required other
-than normal pootle usage.
-
diff --git a/doc/v3-authority-howto.txt b/doc/v3-authority-howto.txt
deleted file mode 100644
index e4470e8c8..000000000
--- a/doc/v3-authority-howto.txt
+++ /dev/null
@@ -1,84 +0,0 @@
-
- How to add a v3 directory authority.
-
-What we'll be doing:
-
- We'll be configuring your Tor server as a v3 directory authority,
- generating a v3 identity key plus certificates, and adding your v3
- identity fingerprint to the list of default directory authorities.
-
-The steps:
-
-0) Make sure you're running ntp, and that your time is correct.
-
- Make sure you have Tor version at least r12724. In the short term,
- running a working authority may mean running the latest version of
- Tor from SVN trunk. Later on, we hope that it will become easier
- and you can just run a recent development release (and later still,
- a recent stable release).
-
-1) First, you'll need a certificate. Run ./src/tools/tor-gencert to
- generate one.
-
- Run tor-gencert in a separate, very secure directory. Maybe even on
- a more secure computer. The first time you run it, you will need to
- run it with the --create-identity-key option to make a v3 authority
- identity key. Subsequent times, you can just run it as-is.
-
- tor-gencert will make 3 files:
-
- authority_identity_key -- THIS IS VERY SECRET AND VERY SENSITIVE.
- DO NOT LEAK IT. DO NOT LOSE IT.
-
- authority_signing_key -- A key for signing votes and v3 conensuses.
-
- authority_certificate -- A document authenticating your signing key
- with your identity-key.
-
- You will need to rotate your signing key periodically. The current
- default lifetime is 1 year. We'll probably take this down to a month or
- two some time soon. To rotate your key, run tor-gencert as before,
- but without the --create-identity-key option.
-
-2) Copy authority_signing_key and authority_certificate to your Tor keys
- directory.
-
- For example if your data directory is /var/lib/tor/, you should run
- cp authority_signing_key authority_certificate /var/lib/tor/keys/
-
- You will need to repeat this every time you rotate your certificate.
-
-3) Tell your Tor to be a v3 authority by adding these lines to your torrc:
-
- AuthoritativeDirectory 1
- V3AuthoritativeDirectory 1
-
-4) Now your authority is generating a networkstatus opinion (called a
- "vote") every period, but none of the other authorities care yet. The
- next step is to get a Tor developer (likely Roger or Nick) to add
- your v3 identity fingerprint to the default list of dirservers.
-
- First, you need to learn your authority's v3 identity fingerprint.
- It should be in your authority_certificate file in a line like:
-
- fingerprint 3041632465FA8847A98B2C5742108C72325532D9
-
- One of the Tor developers then needs to add this fingerprint to
- the add_default_trusted_dirservers() function in config.c, using
- the syntax "v3ident=<fingerprint>". For example, if moria1's new v3
- identity fingerprint is FOO, the moria1 dirserver line should now be:
-
- DirServer moria1 v1 orport=9001 v3ident=FOO 128.31.0.34:9031 FFCB 46DB 1339 DA84 674C 70D7 CB58 6434 C437 0441
-
- The v3ident item must appear after the nickname and before the IP.
-
-5) Once your fingerprint has been added to config.c, we will try to
- get a majority of v3 authorities to upgrade, so they know about you
- too. At that point your vote will automatically be included in the
- networkstatus consensus, and you'll be a fully-functioning contributing
- v3 authority.
-
- Note also that a majority of the configured v3 authorities need to
- agree in order to generate a consensus: so this is also the point
- where extended downtime on your server means missing votes.
-