diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/TODO.022 | 39 | ||||
| -rw-r--r-- | doc/TODO.external | 13 | ||||
| -rw-r--r-- | doc/spec/control-spec.txt | 10 | ||||
| -rw-r--r-- | doc/spec/proposals/000-index.txt | 7 | ||||
| -rw-r--r-- | doc/spec/proposals/134-robust-voting.txt | 22 | ||||
| -rw-r--r-- | doc/spec/proposals/165-simple-robust-voting.txt | 133 | ||||
| -rw-r--r-- | doc/spec/proposals/ideas/xxx-bwrate-algs.txt | 106 | ||||
| -rw-r--r-- | doc/spec/proposals/ideas/xxx-encrypted-services.txt | 18 | ||||
| -rwxr-xr-x | doc/spec/proposals/reindex.py | 2 | ||||
| -rw-r--r-- | doc/tor.1.in | 40 |
10 files changed, 336 insertions, 54 deletions
diff --git a/doc/TODO.022 b/doc/TODO.022 index a0644f1af8..8bf50659fb 100644 --- a/doc/TODO.022 +++ b/doc/TODO.022 @@ -11,13 +11,14 @@ NOTE 2: It's easy to list stuff like this with no time estimates and - Design only - Begin design work for UDP transition; identify areas where we need to make changes or instrument stuff early. - [multiple weeks, ongoing. Need to do a draft early.] - Performance, mostly protocol-neutral. - Work with Libevent 2.0's bufferevent interface - Identify any performance stuff we need to push back into libevent to make it as fast as we want. + - Get a decent rate-limiting feature into Libevent + - Get openssl support into Libevent. - Revise how we do bandwidth limiting and round-robining between circuits on a connection. @@ -42,6 +43,7 @@ NOTE 2: It's easy to list stuff like this with no time estimates and - ... or group client circuits by IP at the server and rate-limit like that. + - Use if-modified-since to download consensuses - Other features @@ -54,34 +56,43 @@ NOTE 2: It's easy to list stuff like this with no time estimates and - Proposals to improve and implement - 158: microdescriptors -N - Revise proposal + o Revise proposal + - Implement - 160: list bandwidth in consensus -RNM? - Finish proposal +RNM? . Finish proposal - and actually set it reasonably - and actually use it. - Proposals to improve and implement if not broken - - IPv6 support. (Parts of 117, but figure out how to handle DNS + D IPv6 support. (Parts of 117, but figure out how to handle DNS requests.) - 140: Directory diffs + - Need a decent simple C diff implementation. + - Need a decent simple C ed patch implementation. - 149: learn info from netinfo cells. - - 134: handle authority fragmentation (Needs more analysis) - - - Needs a proposal, or at least some design - - Detect client-status better -N - Write proposal - - Have authorities report relay and voting status better: make it + o Start discussion + - Revise proposal based on discussion. + X 134: handle authority fragmentation (Needs more analysis) + - 165: Easy migration for voting authority sets + - 163: Detect client-status better + o Write proposal + - Possibly implement, depending on discussion. + - 164: Have authorities report relay and voting status better: make it easy to answer, "Why is my server not listed/not Guard/not Running/etc" -N - Write proposal - - Have consensuses come in multiple "flavours". -N - Write proposal + o Write proposal + - Possibly implement, depending on discussion + - 162: Have consensuses come in multiple "flavours". + o Write proposal + - Possibly implement, depending on discussion. + + - Needs a proposal, or at least some design - Weaken the requirements for being a Guard, based on K's measurements. K - Finish measurements K? - Write proposal - Adaptive timeouts for giving up on circuits and streams. -M/N - Revise proposal 151 +M - Revise proposal 151 - Downweight guards more sensibly: be more forgiving about using Guard nodes as non-first-hop. - Write proposal. diff --git a/doc/TODO.external b/doc/TODO.external index 948ad6a975..12048fa344 100644 --- a/doc/TODO.external +++ b/doc/TODO.external @@ -84,16 +84,9 @@ SM - 4.1, balance traffic better (rejigger the bandwidth numbers at the authorities based on Steven's algorithm), or Mike's plan (relay scanning to identify the unbalanced relays and fix them on the fly), or both. - - Figure out how to actually modify bandwidths in the consensus. We - may need to change the consensus voting algorithm to decide what - bandwidth to advertise based on something other than median: - if 7 authorities provide bandwidths, and 2 are doing scanning, - then the 5 that aren't scanning will outvote any changes. Should - all 7 scan? Should only some vote? Extra points if it doesn't - change all the numbers every new consensus, so consensus diffing - is still practical. -? - 4.5, Older entry guards are overloaded - - Pick a conservative timeout like a month, and implement. + - Implement Proposal 160 + o 4.5, Older entry guards are overloaded + o Pick a conservative timeout like a month, and implement. M - 5.2, better timeouts for giving up on circuits/streams - clients gather data about circuit timeouts, and then abandon circuits that take more than a std dev above that. diff --git a/doc/spec/control-spec.txt b/doc/spec/control-spec.txt index 6ca45aa27f..0c739eca03 100644 --- a/doc/spec/control-spec.txt +++ b/doc/spec/control-spec.txt @@ -773,9 +773,8 @@ Same as passing 'EXTENDED' to SETEVENTS; this is the preferred way to request the extended event syntax. - This will not be always-enabled until at least two stable releases - after 0.1.2.3-alpha, the release where it was first used for - anything. + This feaure was first used in 0.1.2.3-alpha. It is always-on in + Tor 0.2.2.1-alpha and later. VERBOSE_NAMES @@ -786,8 +785,9 @@ LongName format includes a Fingerprint, an indication of Named status, and a Nickname (if one is known). - This will not be always-enabled until at least two stable releases - after 0.1.2.2-alpha, the release where it was first available. + This will not be always-enabled until at least two stable + releases after 0.1.2.2-alpha, the release where it was first + available. It is always-on in Tor 0.2.2.1-alpha and later. 3.20. RESOLVE diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt index 26622e83a5..b26f382f6a 100644 --- a/doc/spec/proposals/000-index.txt +++ b/doc/spec/proposals/000-index.txt @@ -54,7 +54,7 @@ Proposals by number: 131 Help users to verify they are using Tor [NEEDS-REVISION] 132 A Tor Web Service For Verifying Correct Browser Configuration [DRAFT] 133 Incorporate Unreachable ORs into the Tor Network [DRAFT] -134 More robust consensus voting with diverse authority sets [ACCEPTED] +134 More robust consensus voting with diverse authority sets [REJECTED] 135 Simplify Configuration of Private Tor Networks [CLOSED] 136 Mass authority migration with legacy keys [CLOSED] 137 Keep controllers informed as Tor bootstraps [CLOSED] @@ -85,6 +85,7 @@ Proposals by number: 162 Publish the consensus in multiple flavors [OPEN] 163 Detecting whether a connection comes from a client [OPEN] 164 Reporting the status of server votes [OPEN] +165 Easy migration for voting authority sets [OPEN] Proposals by status: @@ -111,11 +112,11 @@ Proposals by status: 162 Publish the consensus in multiple flavors [for 0.2.2] 163 Detecting whether a connection comes from a client [for 0.2.2] 164 Reporting the status of server votes [for 0.2.2] + 165 Easy migration for voting authority sets ACCEPTED: 110 Avoiding infinite length circuits [for 0.2.1.x] [in 0.2.1.3-alpha] 117 IPv6 exits [for 0.2.1.x] 118 Advertising multiple ORPorts at once [for 0.2.1.x] - 134 More robust consensus voting with diverse authority sets [for 0.2.2.x] 140 Provide diffs between consensuses [for 0.2.2.x] 147 Eliminate the need for v2 directories in generating v3 directories [for 0.2.1.x] 157 Make certificate downloads specific [for 0.2.1.x] @@ -167,3 +168,5 @@ Proposals by status: 120 Shutdown descriptors when Tor servers stop 128 Families of private bridges 142 Combine Introduction and Rendezvous Points + REJECTED: + 134 More robust consensus voting with diverse authority sets diff --git a/doc/spec/proposals/134-robust-voting.txt b/doc/spec/proposals/134-robust-voting.txt index 5d5e77fa3b..c5dfb3b47f 100644 --- a/doc/spec/proposals/134-robust-voting.txt +++ b/doc/spec/proposals/134-robust-voting.txt @@ -2,8 +2,10 @@ Filename: 134-robust-voting.txt Title: More robust consensus voting with diverse authority sets Author: Peter Palfrader Created: 2008-04-01 -Status: Accepted -Target: 0.2.2.x +Status: Rejected + +History: + 2009 May 27: Added note on rejecting this proposal -- Nick Overview: @@ -103,3 +105,19 @@ Possible Attacks/Open Issues/Some thinking required: Q: Can this ever force us to build a consensus with authorities we do not recognize? A: No, we can never build a fully connected set with them in step 3. + +------------------------------ + +I'm rejecting this proposal as insecure. + +Suppose that we have a clique of size N, and M hostile members in the +clique. If these hostile members stop declaring trust for up to M-1 +good members of the clique, the clique with the hostile members will +in it will be larger than the one without them. + +The M hostile members will constitute a majority of this new clique +when M > (N-(M-1)) / 2, or when M > (N + 1) / 3. This breaks our +requirement that an adversary must compromise a majority of authorities +in order to control the consensus. + +-- Nick diff --git a/doc/spec/proposals/165-simple-robust-voting.txt b/doc/spec/proposals/165-simple-robust-voting.txt new file mode 100644 index 0000000000..e33d1772c9 --- /dev/null +++ b/doc/spec/proposals/165-simple-robust-voting.txt @@ -0,0 +1,133 @@ +Filename: 165-simple-robust-voting.txt +Title: Easy migration for voting authority sets +Author: Nick Mathewson +Created: 2009-05-28 +Status: Open + +Overview: + + This proposal describes any easy-to-implement, easy-to-verify way to + change the set of authorities without creating a "flag day" situation. + +Motivation: + + From proposal 134 ("More robust consensus voting with diverse + authority sets") by Peter Palfrader: + + Right now there are about five authoritative directory servers + in the Tor network, tho this number is expected to rise to about + 15 eventually. + + Adding a new authority requires synchronized action from all + operators of directory authorities so that at any time during the + update at least half of all authorities are running and agree on + who is an authority. The latter requirement is there so that the + authorities can arrive at a common consensus: Each authority + builds the consensus based on the votes from all authorities it + recognizes, and so a different set of recognized authorities will + lead to a different consensus document. + + In response to this problem, proposal 134 suggested that every + candidate authority list in its vote whom it believes to be an + authority. These A-says-B-is-an-authority relationships form a + directed graph. Each authority then iteratively finds the largest + clique in the graph and remove it, until they find one containing + them. They vote with this clique. + + Proposal 134 had some problems: + + - It had a security problem in that M hostile authorities in a + clique could effectively kick out M-1 honest authorities. This + could enable a minority of the original authorities to take over. + + - It was too complex in its implications to analyze well: it took us + over a year to realize that it was insecure. + + - It tried to solve a bigger problem: general fragmentation of + authority trust. Really, all we wanted to have was the ability to + add and remove authorities without forcing a flag day. + +Proposed protocol design: + + A "Voting Set" is a set of authorities. Each authority has a list of + the voting sets it considers acceptable. These sets are chosen + manually by the authority operators. they must always contain the + authority itself. Each authority lists all of these voting sets in + its votes. + + Authorities exchange votes with every other authority in any of their + voting sets. + + When it comes time to calculate a consensus, an authority votes with + whichever voting set it lists that is listed by the most members of + that set. In other words, given two sets S1 and S2 that an authority + lists, that authority will prefer to vote with S1 over S2 whenever + the number of other authorities in S1 that themselves list S1 is + higher than the number of other authorities in S2 that themselves + list S2. + + For example, suppose authority A recognizes two sets, "A B C D" and + "A E F G H". Suppose that the first set is recognized by all of A, + B, C, and D, whereas the second set is recognized only by A, E, and + F. Because the first set is recognize by more of the authorities in + it than the other one, A will vote with the first set. + + Ties are broken in favor of some arbitrary function of the identity + keys of the authorities in the set. + +How to migrate authority sets: + + In steady state, each authority operator should list only the current + actual voting set as accepted. + + When we want to add an authority, each authority operator configures + his or her server to list two voting sets: one containing all the old + authorities, and one containing the old authorities and the new + authority too. Once all authorities are listing the new set of + authorities, they will start voting with that set because of its + size. + + What if one or two authority operators are slow to list the new set? + Then the other operators can stop listing the old set once there are + enough authorities listing the new set to make its voting successful. + (Note that these authorities not listing the new set will still have + their votes counted, since they themselves will be members of the new + set. They will only fail to sign the consensus generated by the + other authorities who are using the new set.) + + When we want to remove an authority, the operators list two voting + sets: one containing all the authorities, and one omitting the + authority we want to remove. Once enough authorities list the new + set as acceptable, we start having authority operators stop listing + the old set. Once there are more listing the new set than the old + set, the new set will win. + +Data format changes: + + Add a new 'voting-set' line to the vote document format. Allow it to + occur any number of times. Its format is: + + voting-set SP 'fingerprint' SP 'fingerprint' ... NL + + where each fingerprint is the hex fingerprint of an identity key of + an authority. Sort fingerprints in ascending order. + + When the consensus method is at least 'X' (decide this when we + implement the proposal), add this line to the consensus format as + well, before the first dir-source line. [This information is not + redundant with the dir-source sections in the consensus: If an + authority is recognized didn't vote, that authority will appear in + the voting-set line but not in the dir-source sections.] + + We don't need to list other information about authorities in our + vote. + +Migration issues: + + We should keep track somewhere of which Tor client versions + recognized which authorities. + +Acknowledgments: + + The design came out of an IRC conversation with Peter Palfrader. He + had the basic idea first. diff --git a/doc/spec/proposals/ideas/xxx-bwrate-algs.txt b/doc/spec/proposals/ideas/xxx-bwrate-algs.txt new file mode 100644 index 0000000000..757f5bc55e --- /dev/null +++ b/doc/spec/proposals/ideas/xxx-bwrate-algs.txt @@ -0,0 +1,106 @@ +# The following two algorithms + + +# Algorithm 1 +# TODO: Burst and Relay/Regular differentiation + +BwRate = Bandwidth Rate in Bytes Per Second +GlobalWriteBucket = 0 +GlobalReadBucket = 0 +Epoch = Token Fill Rate in seconds: suggest 50ms=.050 +SecondCounter = 0 +MinWriteBytes = Minimum amount bytes per write + +Every Epoch Seconds: + UseMinWriteBytes = MinWriteBytes + WriteCnt = 0 + ReadCnt = 0 + BytesRead = 0 + + For Each Open OR Conn with pending write data: + WriteCnt++ + For Each Open OR Conn: + ReadCnt++ + + BytesToRead = (BwRate*Epoch + GlobalReadBucket)/ReadCnt + BytesToWrite = (BwRate*Epoch + GlobalWriteBucket)/WriteCnt + + if BwRate/WriteCnt < MinWriteBytes: + # If we aren't likely to accumulate enough bytes in a second to + # send a whole cell for our connections, send partials + Log(NOTICE, "Too many ORCons to write full blocks. Sending short packets.") + UseMinWriteBytes = 1 + # Other option: We could switch to plan 2 here + + # Service each writable ORConn. If there are any partial writes, + # return remaining bytes from this epoch to the global pool + For Each Open OR Conn with pending write data: + ORConn->write_bucket += BytesToWrite + if ORConn->write_bucket > UseMinWriteBytes: + w = write(ORConn, MIN(len(ORConn->write_data), ORConn->write_bucket)) + # possible that w < ORConn->write_data here due to TCP pushback. + # We should restore the rest of the write_bucket to the global + # buffer + GlobalWriteBucket += (ORConn->write_bucket - w) + ORConn->write_bucket = 0 + + For Each Open OR Conn: + r = read_nonblock(ORConn, BytesToRead) + BytesRead += r + + SecondCounter += Epoch + if SecondCounter < 1: + # Save unused bytes from this epoch to be used later in the second + GlobalReadBucket += (BwRate*Epoch - BytesRead) + else: + SecondCounter = 0 + GlobalReadBucket = 0 + GlobalWriteBucket = 0 + For Each ORConn: + ORConn->write_bucket = 0 + + + +# Alternate plan for Writing fairly. Reads would still be covered +# by plan 1 as there is no additional network overhead for short reads, +# so we don't need to try to avoid them. +# +# I think this is actually pretty similar to what we do now, but +# with the addition that the bytes accumulate up to the second mark +# and we try to keep track of our position in the write list here +# (unless libevent is doing that for us already and I just don't see it) +# +# TODO: Burst and Relay/Regular differentiation + +# XXX: The inability to send single cells will cause us to block +# on EXTEND cells for low-bandwidth node pairs.. +BwRate = Bandwidth Rate in Bytes Per Second +WriteBytes = Bytes per write +Epoch = MAX(MIN(WriteBytes/BwRate, .333s), .050s) + +SecondCounter = 0 +GlobalWriteBucket = 0 + +# New connections are inserted at Head-1 (the 'tail' of this circular list) +# This is not 100% fifo for all node data, but it is the best we can do +# without insane amounts of additional queueing complexity. +WriteConnList = List of Open OR Conns with pending write data > WriteBytes +WriteConnHead = 0 + +Every Epoch Seconds: + GlobalWriteBucket += BwRate*Epoch + WriteListEnd = WriteConnHead + + do + ORCONN = WriteConnList[WriteConnHead] + w = write(ORConn, WriteBytes) + GlobalWriteBucket -= w + WriteConnHead += 1 + while GlobalWriteBucket > 0 and WriteConnHead != WriteListEnd + + SecondCounter += Epoch + if SecondCounter >= 1: + SecondCounter = 0 + GlobalWriteBucket = 0 + + diff --git a/doc/spec/proposals/ideas/xxx-encrypted-services.txt b/doc/spec/proposals/ideas/xxx-encrypted-services.txt new file mode 100644 index 0000000000..3414f3c4fb --- /dev/null +++ b/doc/spec/proposals/ideas/xxx-encrypted-services.txt @@ -0,0 +1,18 @@ + +the basic idea might be to generate a keypair, and sign little statements +like "this key corresponds to this relay id", and publish them on karsten's +hs dht. + +so if you want to talk to it, you look it up, then go to that exit. +and by 'go to' i mean 'build a tor circuit like normal except you're sure +where to exit' + +connecting to it is slower than usual, but once you're connected, it's no +slower than normal tor. +and you get what wikileaks wants from its hidden service, which is really +just the UI piece. +indymedia also wants this. + +might be interesting to let an encrypted service list more than one relay, +too. + diff --git a/doc/spec/proposals/reindex.py b/doc/spec/proposals/reindex.py index 2b4c02516b..980bc0659f 100755 --- a/doc/spec/proposals/reindex.py +++ b/doc/spec/proposals/reindex.py @@ -4,7 +4,7 @@ import re, os class Error(Exception): pass STATUSES = """DRAFT NEEDS-REVISION NEEDS-RESEARCH OPEN ACCEPTED META FINISHED - CLOSED SUPERSEDED DEAD""".split() + CLOSED SUPERSEDED DEAD REJECTED""".split() REQUIRED_FIELDS = [ "Filename", "Status", "Title" ] CONDITIONAL_FIELDS = { "OPEN" : [ "Target" ], "ACCEPTED" : [ "Target "], diff --git a/doc/tor.1.in b/doc/tor.1.in index db0637a75f..3ac0f92fe2 100644 --- a/doc/tor.1.in +++ b/doc/tor.1.in @@ -244,7 +244,7 @@ fetching early. Normal users should leave it off. \fBFetchHidServDescriptors \fR\fB0\fR|\fB1\fR\fP If set to 0, Tor will never fetch any hidden service descriptors from the rendezvous directories. This option is only useful if you're using -a Tor controller that handles hidserv fetches for you. +a Tor controller that handles hidden service fetches for you. (Default: 1) .LP .TP @@ -264,31 +264,31 @@ script to enumerate Tor nodes that exit to certain addresses. (Default: 0) .LP .TP -\fBHttpProxy\fR \fIhost\fR[:\fIport\fR]\fP +\fBHTTPProxy\fR \fIhost\fR[:\fIport\fR]\fP Tor will make all its directory requests through this host:port (or host:80 if port is not specified), rather than connecting directly to any directory servers. .LP .TP -\fBHttpProxyAuthenticator\fR \fIusername:password\fP -If defined, Tor will use this username:password for Basic Http proxy +\fBHTTPProxyAuthenticator\fR \fIusername:password\fP +If defined, Tor will use this username:password for Basic HTTP proxy authentication, as in RFC 2617. This is currently the only form of -Http proxy authentication that Tor supports; feel free to submit a +HTTP proxy authentication that Tor supports; feel free to submit a patch if you want it to support others. .LP .TP -\fBHttpsProxy\fR \fIhost\fR[:\fIport\fR]\fP +\fBHTTPSProxy\fR \fIhost\fR[:\fIport\fR]\fP Tor will make all its OR (SSL) connections through this host:port (or host:443 if port is not specified), via HTTP CONNECT rather than connecting directly to servers. You may want to set \fBFascistFirewall\fR -to restrict the set of ports you might try to connect to, if your Https +to restrict the set of ports you might try to connect to, if your HTTPS proxy only allows connecting to certain ports. .LP .TP -\fBHttpsProxyAuthenticator\fR \fIusername:password\fP -If defined, Tor will use this username:password for Basic Https proxy +\fBHTTPSProxyAuthenticator\fR \fIusername:password\fP +If defined, Tor will use this username:password for Basic HTTPS proxy authentication, as in RFC 2617. This is currently the only form of -Https proxy authentication that Tor supports; feel free to submit a +HTTPS proxy authentication that Tor supports; feel free to submit a patch if you want it to support others. .LP .TP @@ -511,7 +511,7 @@ firewall allows connections to everything inside net 99, rejects port Like \fBReachableAddresses\fP, a list of addresses and ports. Tor will obey these restrictions when fetching directory information, using standard HTTP GET requests. If not set explicitly then the value of \fBReachableAddresses\fP -is used. If \fBHttpProxy\fR is set then these connections will go through that +is used. If \fBHTTPProxy\fR is set then these connections will go through that proxy. .LP .TP @@ -519,11 +519,11 @@ proxy. Like \fBReachableAddresses\fP, a list of addresses and ports. Tor will obey these restrictions when connecting to Onion Routers, using TLS/SSL. If not set explicitly then the value of \fBReachableAddresses\fP is used. If -\fBHttpsProxy\fR is set then these connections will go through that proxy. +\fBHTTPSProxy\fR is set then these connections will go through that proxy. The separation between \fBReachableORAddresses\fP and \fBReachableDirAddresses\fP is only interesting when you are connecting through -proxies (see \fBHttpProxy\fR and \fBHttpsProxy\fR). Most proxies limit TLS +proxies (see \fBHTTPProxy\fR and \fBHTTPSProxy\fR). Most proxies limit TLS connections (which Tor uses to connect to Onion Routers) to port 443, and some limit HTTP GET requests (which Tor uses for fetching directory information) to port 80. @@ -606,7 +606,7 @@ to hosts that match this value and attempt to reuse the same exit node for each. If the value is prepended with a '.', it is treated as matching an entire domain. If one of the values is just a '.', it means match everything. This option is useful if you frequently connect to -sites that will expire all your authentication cookies (ie log you out) if +sites that will expire all your authentication cookies (i.e. log you out) if your IP address changes. Note that this option does have the disadvantage of making it more clear that a given history is associated with a single user. However, most people who would wish to observe @@ -795,7 +795,7 @@ The following options are useful only for servers (that is, if \fBORPort\fP is n .LP .TP \fBAddress \fR\fIaddress\fP -The IP address or fqdn of this server (e.g. moria.mit.edu). You can +The IP address or fully qualified domain name of this server (e.g. moria.mit.edu). You can leave this unset, and Tor will guess your IP address. .LP .TP @@ -975,7 +975,7 @@ behalf of clients. (Defaults to use the system DNS configuration.) \fBServerDNSAllowBrokenConfig \fR\fB0\fR|\fB1\fR\fP If this option is false, Tor exits immediately if there are problems parsing the system DNS configuration or connecting to nameservers. -Otherwise, Tor continues to periodically retry the system namesevers +Otherwise, Tor continues to periodically retry the system nameservers until it eventually succeeds. (Defaults to "1".) .LP @@ -1056,7 +1056,7 @@ admins at tor-ops@freehaven.net if you think you should be a directory. .LP .TP \fBDirPortFrontPage \fIFILENAME\fP -When this option is set, it takes an html file and publishes it as "/" on +When this option is set, it takes an HTML file and publishes it as "/" on the DirPort. Now relay operators can provide a disclaimer without needing to set up a separate webserver. There's a sample disclaimer in contrib/tor-exit-notice.html. @@ -1212,14 +1212,14 @@ for publication by this authority. \fBAuthDirListBadDirs \fR\fB0\fR|\fB1\fR\fP Authoritative directories only. If set to 1, this directory has some opinion about which nodes are unsuitable as directory caches. (Do not -set this to 1 unless you plan to list nonfunctioning directories as bad; +set this to 1 unless you plan to list non-functioning directories as bad; otherwise, you are effectively voting in favor of every declared directory.) .LP .TP \fBAuthDirListBadExits \fR\fB0\fR|\fB1\fR\fP Authoritative directories only. If set to 1, this directory has some opinion about which nodes are unsuitable as exit nodes. (Do not -set this to 1 unless you plan to list nonfunctioning exits as bad; +set this to 1 unless you plan to list non-functioning exits as bad; otherwise, you are effectively voting in favor of every declared exit as an exit.) .LP @@ -1228,7 +1228,7 @@ as an exit.) Authoritative directories only. If set to 1, the directory server rejects all uploaded server descriptors that aren't explicitly listed in the fingerprints file. This acts as a "panic button" if we get -Sybiled. (Default: 0) +hit with a Sybil attack. (Default: 0) .LP .TP \fBAuthDirMaxServersPerAddr\fR \fINUM\fP |