The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:57:30Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21038configure step and "implicit-function-declaration"2020-06-27T13:57:30Ztoralfconfigure step and "implicit-function-declaration"This breaks :
```
./configure CFLAGS="-O2 -pipe -march=native -Werror=implicit-function-declaration"
...
checking for pthread_create... yes
checking for pthread_condattr_setclock... yes
checking for libevent directory... configure: WARNI...This breaks :
```
./configure CFLAGS="-O2 -pipe -march=native -Werror=implicit-function-declaration"
...
checking for pthread_create... yes
checking for pthread_condattr_setclock... yes
checking for libevent directory... configure: WARNING: We found the libraries for libevent, but we could not find the C header files. You may need to install a devel package.
configure: error: Missing headers; unable to proceed.
```
but neither this :
```
./configure --enable-gcc-warnings
```
nor this
```
./configure CFLAGS="-O2 -pipe -march=native" --enable-gcc-warnings
```
Shouldn't the later break too ?Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21039Refactor and simplify guard code of circuit_send_next_onion_skin()2021-09-16T14:33:05ZGeorge KadianakisRefactor and simplify guard code of circuit_send_next_onion_skin()As part of prop271 (legacy/trac#19877), we added about 70 fresh lines of code to `circuit_send_next_onion_skin()` which is an already convoluted function.
Ideally we should abstract this new circuit-related guard code and put it in its ...As part of prop271 (legacy/trac#19877), we added about 70 fresh lines of code to `circuit_send_next_onion_skin()` which is an already convoluted function.
Ideally we should abstract this new circuit-related guard code and put it in its own functions, to reduce complexity of `circuit_send_next_onion_skin()` and maybe even make it unittestable.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40028Onion-Location ".onion available" shown when on Onion-Location2020-07-09T08:50:26ZErik MoellerOnion-Location ".onion available" shown when on Onion-LocationIn Tor Browser 9.5.1, the ".onion available" banner is shown on https://secrdrop5wyphb5x.onion/ (the current Onion Service for securedrop.org, sorry for v2), which serves up the `Onion-Location` header for that exact address. Is that the...In Tor Browser 9.5.1, the ".onion available" banner is shown on https://secrdrop5wyphb5x.onion/ (the current Onion Service for securedrop.org, sorry for v2), which serves up the `Onion-Location` header for that exact address. Is that the expected behavior? Our expectation would be that the browser detects that this is the currently loaded address, and therefore ignores the `Onion-Location` header pointing to the same address.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40029Use Windows firefox shortcuts on non-Windows platform2022-11-29T16:02:15ZranyUse Windows firefox shortcuts on non-Windows platformWhen running Tor Browser on non-Windows OSes, websites think that the user is running on Windows (for fingerprinting protection). This has the effect of causing web application's shortcuts to interfere with Firefox's shortcuts.
I think...When running Tor Browser on non-Windows OSes, websites think that the user is running on Windows (for fingerprinting protection). This has the effect of causing web application's shortcuts to interfere with Firefox's shortcuts.
I think this only affects non-Windows OSes.
For example: alt-num should become ctrl-numhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21043Make ClientUseIPv4 and ClientUseIPv6 equivalent to ReachableAddresses2020-07-27T23:33:29ZteorMake ClientUseIPv4 and ClientUseIPv6 equivalent to ReachableAddressesOnce legacy/trac#20996 is fixed, we should also make ClientUseIPv4 and ClientUseIPv6 work the same as the equivalent ReachableAddresses settings.
For example:
ClientUseIPv4 = accept/reject 0.0.0.0/0 = accept/reject *4
ClientUseIPv6 = ac...Once legacy/trac#20996 is fixed, we should also make ClientUseIPv4 and ClientUseIPv6 work the same as the equivalent ReachableAddresses settings.
For example:
ClientUseIPv4 = accept/reject 0.0.0.0/0 = accept/reject *4
ClientUseIPv6 = accept/reject [::]/0 = accept6/reject6 * = accept/reject *6
Bootstrap and guards should also work if ReachableAddresses blocks almost all addresses of a particular type.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40030TBB is not detecting a .onion on a website2020-07-09T19:04:24ZGuinnessTBB is not detecting a .onion on a websiteIf we go on this website : https://bureburebure.info, we can see in the footer that there is a HSv3 available. However, the TBB doesn't show the «.onion available».
I don't know why it is so, and I don't know how this button works, but t...If we go on this website : https://bureburebure.info, we can see in the footer that there is a HSv3 available. However, the TBB doesn't show the «.onion available».
I don't know why it is so, and I don't know how this button works, but there might be a bug, no?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40031Easier flow to navigate back to clear-URL after an onion-location redirect, e...2022-11-30T14:08:36ZJim NewsomeEasier flow to navigate back to clear-URL after an onion-location redirect, e.g. when onion is brokenI've configured TBB to automatically follow onion-location redirects. Occasionally such a redirect goes to a broken onion site, while the clear-site is working fine. Unfortunately there's not an easy flow to navigate back to the clear-ur...I've configured TBB to automatically follow onion-location redirects. Occasionally such a redirect goes to a broken onion site, while the clear-site is working fine. Unfortunately there's not an easy flow to navigate back to the clear-url (and not redirect again).https://gitlab.torproject.org/tpo/core/tor/-/issues/21045Silent crash at 80% Bootstrap Tor 0.2.9.8 OSX10.42020-06-27T13:57:30ZTracSilent crash at 80% Bootstrap Tor 0.2.9.8 OSX10.4Since upgrading to Tor 0.2.9.8, Tor crashes on my OSX10.4 machine at 80% bootstrap.
Some debug-level lines:
```
Dec 20 23:58:45.000 [notice] Bootstrapped 80%: Connecting to the Tor network
...
Dec 20 23:58:46.000 [info] connection_ap_mak...Since upgrading to Tor 0.2.9.8, Tor crashes on my OSX10.4 machine at 80% bootstrap.
Some debug-level lines:
```
Dec 20 23:58:45.000 [notice] Bootstrapped 80%: Connecting to the Tor network
...
Dec 20 23:58:46.000 [info] connection_ap_make_link(): Making internal direct tunnel to [scrubbed]:443 ...
Dec 20 23:58:46.000 [debug] connection_add_impl(): new conn type Socks, socket -1, address (Tor_internal), n_conns 5.
Dec 20 23:58:46.000 [info] connection_ap_make_link(): ... application connection created and linked.
Dec 20 23:58:46.000 [debug] connection_add_impl(): new conn type Directory, socket -1, address 195.154.164.243, n_conns 6.
```
Those are the last four entries in the log.
This is a bridge/client, with some exit node restrictions: torrc
```
ControlPort 9051
ExcludeNodes Qwerty,freeMe69,JustANode,AIVD,MIVD,afe5ab469c027cf3deec72ae6873ba62ae735414,dc914d754b27e1a0f196330bec599bc9d640f30c
ExitPolicy reject *:*
HashedControlPassword 16:xxxxxxx
Nickname xxxxxxxxxxx
ORPort auto
ExtORPort auto
BridgeRelay 1
ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed
StrictNodes 1
ExcludeExitNodes {gb}
```
It was compiled thusly:
```
$ unset LDFLAGS
$ CFLAGS="-O -g -mmacosx-version-min=10.4 -arch ppc"
$ ./configure --prefix=/Library/Tor --with-libevent-dir=/opt/local --with-openssl-dir=/opt/local --disable-dependency-tracking CC="gcc-4.0"
$ make
```
I noticed lots of warnings about shadow declarations and implicit truncation from 64 bit to 32 bit.
Console.log says (and this looks more like the time I started Tor rather than when it crashed):
```
Dec 20 23:42:25 Power-Mac-G4 crashdump[2083]: tor crashed
Dec 20 23:42:25 Power-Mac-G4 crashdump[2083]: crash report written to: /Users/tor/Library/Logs/CrashReporter/tor.crash.log
```
```
Host Name: xxxxxxxxxx
Date/Time: 2016-12-20 23:42:13.859 +0000
OS Version: 10.4.11 (Build 8S165)
Report Version: 4
Command: tor
Path: /usr/bin/tor
Parent: bash [2081]
Version: ??? (???)
PID: 2082
Thread: 0
Exception: EXC_BAD_INSTRUCTION (0x0002)
Code[0]: 0x00000002
Code[1]: 0x0120a4e0
Thread 0 Crashed:
0 libcrypto.1.0.0.dylib 0x0120a4e0 OPENSSL_ppc64_probe + 0
1 libcrypto.1.0.0.dylib 0x0120a744 OPENSSL_cpuid_setup + 196
2 libcrypto.1.0.0.dylib 0x012a6724 OPENSSL_add_all_algorithms_noconf + 20
3 tor 0x00121360 crypto_early_init + 64 (crypto.c:3355)
4 tor 0x0000493c tor_init + 188 (main.c:2782)
5 tor 0x00005e30 tor_main + 80 (main.c:3461)
6 tor 0x00002250 main + 16 (tor_main.c:35)
7 tor 0x00001e4c _start + 760
8 tor 0x00001b50 start + 48
Thread 0 crashed with PPC Thread State 64:
srr0: 0x000000000120a4e0 srr1: 0x000000000208f030 vrsave: 0x0000000000000000
cr: 0x24000222 xer: 0x0000000000000004 lr: 0x000000000120a744 ctr: 0x00000000900019c0
r0: 0x0000000000000000 r1: 0x00000000bffff1b0 r2: 0x000000000000001a r3: 0x0000000000000000
r4: 0x0000000000000000 r5: 0x000000000120a738 r6: 0x0000000001365d98 r7: 0x00000000000000ff
r8: 0x0000000001365d84 r9: 0x00000000fffff927 r10: 0x000000000000000e r11: 0x0000000022000222
r12: 0x00000000900019c0 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000
r16: 0x0000000000000000 r17: 0x0000000000000000 r18: 0x0000000000000000 r19: 0x0000000000000000
r20: 0x00000000bffff884 r21: 0x000000000000000c r22: 0x0000000000000000 r23: 0x0000000000000000
r24: 0x0000000000000000 r25: 0x000000000000000c r26: 0x0000000000201330 r27: 0x00000000bffff8b8
r28: 0x00000000bffff884 r29: 0x00000000bffff320 r30: 0x000000000136a688 r31: 0x000000000120a688
Binary Images Description:
0x1000 - 0x1f5fff tor /usr/bin/tor
0x607000 - 0x618fff libz.1.dylib /opt/local/lib/libz.1.dylib
0x61c000 - 0x64efff libevent-2.0.5.dylib /opt/local/lib/libevent-2.0.5.dylib
0x65b000 - 0x6abfff libssl.1.0.0.dylib /opt/local/lib/libssl.1.0.0.dylib
0x1205000 - 0x1351fff libcrypto.1.0.0.dylib /opt/local/lib/libcrypto.1.0.0.dylib
0x8fe00000 - 0x8fe52fff dyld 46.16 /usr/lib/dyld
0x90000000 - 0x901bcfff libSystem.B.dylib /usr/lib/libSystem.B.dylib
0x90214000 - 0x90219fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib
0x91434000 - 0x9143ffff libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib
```
Not too much detail in the body of the ticket I hope.
**Trac**:
**Username**: downieTor: unspecifiedhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40033Revert #21537: Mark .onion cookies as secure2020-07-22T13:18:35ZMatthew FinkelRevert #21537: Mark .onion cookies as secureFollowing a conversation about the #21537 patch, we should back out that change. The patch is correct from the perspective that a connection with an onion service is a secure channel, however there are circumstances where the onion servi...Following a conversation about the #21537 patch, we should back out that change. The patch is correct from the perspective that a connection with an onion service is a secure channel, however there are circumstances where the onion services connects with a remote web server and potentially sends secure cookies over an insecure (plaintext) channel.
While this configuration is entirely dependent on how the web site was configured, and it is not a flaw in onion services, Tor Browser should take this into account instead of assuming all onion service connections are end-to-end encrypted and authenticated secure channels.
We should find an (opt-in) alternative solution for allowing the use of secure cookies over onion service connections that are secure channels, without exposing secure cookies on onion services connections that are not secure channels.https://gitlab.torproject.org/tpo/core/tor/-/issues/21051configure complains of missing libevent C-headers2020-06-27T13:57:30ZTracconfigure complains of missing libevent C-headersThe configure script aborts with the following output:
```
WARNING: We found the libraries for libevent, but we could not find the C header files. You may need to install a devel package.
```
The test that fails complains of an implici...The configure script aborts with the following output:
```
WARNING: We found the libraries for libevent, but we could not find the C header files. You may need to install a devel package.
```
The test that fails complains of an implicit function declaration of event_init. This can be resolved by including the headers
```
event2/event_compat.h
```
I have attached the patch I used (taken from iCepa) to accomplish this.
**Trac**:
**Username**: rainwolfTor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21052Bad prop271 behavior when exhausting all guards2020-06-27T13:57:29ZGeorge KadianakisBad prop271 behavior when exhausting all guardsHere is a weird prop271 behavior. If you get Tor to exhaust all of its
primary/confirmed/sampled guards, it will just get stuck until a guard gets
marked for retry (which can take half an hour or more).
Specifically, if you disable the ...Here is a weird prop271 behavior. If you get Tor to exhaust all of its
primary/confirmed/sampled guards, it will just get stuck until a guard gets
marked for retry (which can take half an hour or more).
Specifically, if you disable the network until Tor starts hitting:
```
if (guard == NULL) {
log_warn(LD_GUARD, "Absolutely no sampled guards were available.");
return NULL;
}
```
it will just get stuck in a `"Absolutely no sampled guards were available."`
loop until a guard gets marked for retry.
In our pre-prop271 guard algorithm, we used to mark all guards as retriable if
we exhaust all of them. I think this is a strictly better behavior than just
waiting until a guard retry timeout triggers.
Furthermore in our pre-prop271 guard algorithm, when we exhaust all of our
guards, we mark our network as likely-down. The idea is that if our network was
marked as likely-down and then we managed to connect to a guard, we would treat
that as a network-up event and then start trying guards from the top of our
list.
This was a pretty effective heuristic that really saved lots of guard exposure
to people with unstable internet. We have a similar one for prop271 but it's
only based on time (get_internet_likely_down_interval() etc.) and not on behavior. I think doing
this old heuristic in prop271 might be a great idea. Here is how it could work:
When we exhaust all our guards, we mark all guards as retriable. The next time
we manage to connect to a guard, we stall the circuit and we call
mark_primary_guards_maybe_reachable() so that we attempt to connect to our
primaries again, before using that low-priority guard.Tor: 0.3.0.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40035Fix TorStrings rebase mistake2020-07-22T09:46:21ZAlex CatarineuFix TorStrings rebase mistakeI missed a `SecurityLevelStrings` -> `TorString` while addressing a previous rebase issue.
This was pointed out in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/33533#note_2688080.I missed a `SecurityLevelStrings` -> `TorString` while addressing a previous rebase issue.
This was pointed out in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/33533#note_2688080.Tor Browser: 10.0https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40036remove product version and update channel portions of #13379 mar tool patch2020-07-22T09:29:55ZMark Smithremove product version and update channel portions of #13379 mar tool patchIn https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40026#note_2694584, gk pointed out that we should remove the portion of the #13379 mar tool patch that overrides the product version and update channel.In https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40026#note_2694584, gk pointed out that we should remove the portion of the #13379 mar tool patch that overrides the product version and update channel.Tor Browser: 10.0https://gitlab.torproject.org/tpo/core/tor/-/issues/21054hs: BUG() is triggered with ephemeral service on config reload2021-09-16T14:33:05ZDavid Gouletdgoulet@torproject.orghs: BUG() is triggered with ephemeral service on config reloadTicket legacy/trac#20853 introduced the issue with commit `63d3ba96f973735ded16e78bd0b8406b6fcdec35` (tor-0.3.0.1-alpha) with:
```
+ if (BUG(rend_service_is_ephemeral(new)) ||
+ BUG(rend_service_is_ephemeral(old))) {
+...Ticket legacy/trac#20853 introduced the issue with commit `63d3ba96f973735ded16e78bd0b8406b6fcdec35` (tor-0.3.0.1-alpha) with:
```
+ if (BUG(rend_service_is_ephemeral(new)) ||
+ BUG(rend_service_is_ephemeral(old))) {
+ continue;
```
The new service list does not ONLY contains ephemeral service so if you have one regular service and then you add an ephemeral one, a config reload will trigger `BUG(rend_service_is_ephemeral(new)` because that `new` object is from the global list containing all types of service.
Furthermore, this whole loop that is suppose to copy the intro points from the current service to the newly configured one is broken with that commit.
I'm working on a refactoring to first fix this bug then extract this large loop into a function and improve few things along the way _with_ unit tests. It is also an important piece of work for legacy/trac#20657 (prop224 service) because we'll need it for the v3 service list.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40037Rebase the branch used for our nightly builds to 78.1.0esr2022-10-04T19:36:46ZGeorg KoppenRebase the branch used for our nightly builds to 78.1.0esrMight be worth having an extra issue tracking the rebase of our esr78 branches until we move on to our "normal" workflow.Might be worth having an extra issue tracking the rebase of our esr78 branches until we move on to our "normal" workflow.Tor Browser: 10.0https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40038Review RemoteSettings for ESR782020-08-25T10:35:19ZAlex CatarineuReview RemoteSettings for ESR78We should revisit #31740 for ESR78. In a first inspection I could see requests to `url-classifier-skip-urls`, which the current patch should have removed.
We could also use the opportunity to simplify the patch a bit, for example trying...We should revisit #31740 for ESR78. In a first inspection I could see requests to `url-classifier-skip-urls`, which the current patch should have removed.
We could also use the opportunity to simplify the patch a bit, for example trying to make all the changes in a single place (e.g. something like a blacklist of bucket/collection somewhere in the RemoteSettings client code).Tor Browser: 10.0https://gitlab.torproject.org/tpo/core/tor/-/issues/21056Could not pick one of the responsible hidden service directories, because we ...2020-06-27T13:57:29ZTracCould not pick one of the responsible hidden service directories, because we requested them all recently without success.I am seeing connections to hidden services reliably fail, with this in the log:
Dec 21 13:50:16.000 [info] connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID '[scrubbed]'
Dec 21 13:50:16.000 [info] connect...I am seeing connections to hidden services reliably fail, with this in the log:
Dec 21 13:50:16.000 [info] connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID '[scrubbed]'
Dec 21 13:50:16.000 [info] connection_ap_handshake_rewrite_and_attach(): Unknown descriptor [scrubbed]. Fetching.
Dec 21 13:50:16.000 [debug] rend_client_refetch_v2_renddesc(): Fetching v2 rendezvous descriptor for service [scrubbed]
Dec 21 13:50:16.000 [info] pick_hsdir(): Could not pick one of the responsible hidden service directories, because we requested them all recently without success.
Dec 21 13:50:16.000 [info] pick_hsdir(): Could not pick one of the responsible hidden service directories, because we requested them all recently without success.
Dec 21 13:50:16.000 [info] fetch_v2_desc_by_addr(): Could not pick one of the responsible hidden service directories to fetch descriptors, because we already tried them all unsuccessfully.
In my test case, I have 2 hidden services running on a machine. Both have been started up for the first time in the past 5-10 minutes. On the same machine, I open concurrently two socks connections, one to each hidden service. Reiably, one of the socks connections succeeds, and the other fails. After it starts failing, retries using that onion address continue to fail for several minutes.
Kind of looks like one socks request is breaking the other one. This seems similar to legacy/trac#16501 and legacy/trac#15937 but I am pretty sure I am only making 2 socks connections, to two different onion addresses.
Attached log shows this occurring, and then after a while the bad state cleared and a retry to connect to the hidden service that it had not been able to resolve succeeded.
**Trac**:
**Username**: joeyhTor: 0.3.1.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40039esr78 updater regressions2020-07-23T22:12:02ZMark Smithesr78 updater regressionsKathy and I found a few updater-related regressions when running some tests on macOS with the tor-browser-78.0.1esr-10.0-1 branch. Specifically:
- The build date is displayed in the about box.
- The `visit our website` link on the about...Kathy and I found a few updater-related regressions when running some tests on macOS with the tor-browser-78.0.1esr-10.0-1 branch. Specifically:
- The build date is displayed in the about box.
- The `visit our website` link on the about:tbupdate page does not pick up the URL from the applied update.Tor Browser: 10.0https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40040fix error: 'downloading' is an invalid string label2020-07-31T15:20:31ZMark Smithfix error: 'downloading' is an invalid string label@brade and I noticed the following message on the browser console during while testing esr78-based updates:
```
'downloading' is an invalid string label
```
This error is familiar to us because we fixed the cause already while uplifting ...@brade and I noticed the following message on the browser console during while testing esr78-based updates:
```
'downloading' is an invalid string label
```
This error is familiar to us because we fixed the cause already while uplifting the `downloading` patches (see [Bugzilla 1642404](https://bugzilla.mozilla.org/show_bug.cgi?id=1642404)). We should backport the missing portion of the patch that is now in Firefox. Alternatively, we could remove the #28885 parts of our #4234 patch and backport all of the uplifted code from [Bugzilla 1642404](https://bugzilla.mozilla.org/show_bug.cgi?id=1642404) and [Bugzilla 1642754](https://bugzilla.mozilla.org/show_bug.cgi?id=1642754). Those fixes are included in Firefox 79.Tor Browser: 10.0https://gitlab.torproject.org/tpo/core/tor/-/issues/21058Manual Modifications: Correction and Improvement2020-06-27T13:57:29ZTracManual Modifications: Correction and ImprovementPlease modify the Manual as follows: 1) At StrictNodes: A) Please change "will treat" to "treats **solely**"; B) At the end of the first sentence, please add "(StrictNodes applies to neither ExcludeExitNodes nor to ExitNodes)"; 2) At Exc...Please modify the Manual as follows: 1) At StrictNodes: A) Please change "will treat" to "treats **solely**"; B) At the end of the first sentence, please add "(StrictNodes applies to neither ExcludeExitNodes nor to ExitNodes)"; 2) At ExcludeExitNodes, please bold "**outside**" 3) At ExitNodes: A) please bold both usages of "**outside**"; B) In the third paragraph, to the end of the second sentence, please add: "(i.e. Onion Circuits shows third nodes which DO NOT _EXIT_ the Tor network, but are used exclusively internally by Tor)".
For further discussion of this, https://tor.stackexchange.com/questions/13134 has some relevance.
It is imperative, in order to maintain user trust in Tor, that the manual accurately and precisely describe Tor's behavior.
**PLEASE NOTE:** I am uncertain if, in fact, StrictNodes applies **_solely**_ to ExcludeNodes; so please verify that as necessary. I am quite certain regarding the other requested modification [1B] to StrictNodes. All other requested modifications merely improve understandability.
In-line, the above modifications would modify the relevant portions of the Manual to read as follows [modifications offset by ">>" and "<<"]:
StrictNodes 0|1
If StrictNodes is set to 1, Tor >>treats '''solely'''<< the ExcludeNodes option as a requirement to follow for all the circuits you generate, even if doing so will break functionality for you >>(StrictNodes applies to neither ExcludeExitNodes nor to ExitNodes)<<. If StrictNodes is set to 0, Tor will still try to avoid nodes in the ExcludeNodes list, but it will err on the side of avoiding unexpected errors. Specifically, StrictNodes 0 tells Tor that it is okay to use an excluded node when it is '''necessary''' to perform relay reachability self-tests, connect to a hidden service, provide a hidden service to a client, fulfill a .exit request, upload directory information, or download directory information. (Default: 0)
ExcludeExitNodes node,node,…
A list of identity fingerprints, country codes, and address patterns of nodes to never use when picking an exit node---that is, a node that delivers traffic for you >>'''outside'''<< the Tor network. Note that any node listed in ExcludeNodes is automatically considered to be part of this list too. See the '''ExcludeNodes''' option for more information on how to specify nodes. See also the caveats on the "ExitNodes" option below.
ExitNodes node,node,…
A list of identity fingerprints, country codes, and address patterns of nodes to use as exit node---that is, a node that delivers traffic for you >>'''outside'''<< the Tor network. See the '''ExcludeNodes''' option for more information on how to specify nodes.
Note that if you list too few nodes here, or if you exclude too many exit nodes with ExcludeExitNodes, you can degrade functionality. For example, if none of the exits you list allows traffic on port 80 or 443, you won’t be able to browse the web.
Note also that not every circuit is used to deliver traffic >>'''outside'''<< of the Tor network. It is normal to see non-exit circuits (such as those used to connect to hidden services, those that do directory fetches, those used for relay reachability self-tests, and so on) that end at a non-exit node >>(i.e. Onion Circuits shows third nodes which DO NOT ''EXIT'' the Tor network, but are used exclusively internally by Tor)<<. To keep a node from being used entirely, see ExcludeNodes and StrictNodes.
The ExcludeNodes option overrides this option: any node listed in both ExitNodes and ExcludeNodes is treated as excluded.
The .exit address notation, if enabled via AllowDotExit, overrides this option.
**Trac**:
**Username**: agdTor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org