Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:16:32Zhttps://gitlab.torproject.org/legacy/trac/-/issues/24044Resolved [scrubbed] which was already resolved; ignoring2020-06-13T15:16:32ZMoritz BartlResolved [scrubbed] which was already resolved; ignoringI'm seeing lots of these warnings on Tor 0.3.2.2-alpha (git-cd94726331b8fc28 from the experimental repository) across various machines (exit relays). I should test this with 0.3.2.3-alpha too.
```
Oct 30 01:15:56: Resolved [scrubbed] wh...I'm seeing lots of these warnings on Tor 0.3.2.2-alpha (git-cd94726331b8fc28 from the experimental repository) across various machines (exit relays). I should test this with 0.3.2.3-alpha too.
```
Oct 30 01:15:56: Resolved [scrubbed] which was already resolved; ignoring
Oct 30 01:15:59: Resolved [scrubbed] which was already resolved; ignoring
Oct 30 01:16:05: Resolved [scrubbed] which was already resolved; ignoring
Oct 30 01:16:12: Resolved [scrubbed] which was already resolved; ignoring
Oct 30 01:16:14: Resolved [scrubbed] which was already resolved; ignoring
Oct 30 01:16:19: Resolved [scrubbed] which was already resolved; ignoring
Oct 30 01:16:19: Resolved [scrubbed] which was already resolved; ignoring
Oct 30 01:16:49: Resolved [scrubbed] which was already resolved; ignoring
Oct 30 01:16:59: Resolved [scrubbed] which was already resolved; ignoring
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24029Test all rust functions' behavior when called from C with bad UTF82020-06-13T15:16:28ZNick MathewsonTest all rust functions' behavior when called from C with bad UTF8We should make sure that the various rust implementations of our protover functions will correctly detect and reject strings that aren't UTF-8We should make sure that the various rust implementations of our protover functions will correctly detect and reject strings that aren't UTF-8Tor: 0.3.3.x-finalChelsea KomloChelsea Komlohttps://gitlab.torproject.org/legacy/trac/-/issues/23815routerstatus download status fields should be explicitly set2020-06-13T15:15:26Zteorrouterstatus download status fields should be explicitly setAll the other zero-valued enums are correct, but we should still set them:
```
/* Use exponential-backoff scheduling when downloading microdescs */
rs->dl_status.backoff = DL_SCHED_RANDOM_EXPONENTIAL;
```All the other zero-valued enums are correct, but we should still set them:
```
/* Use exponential-backoff scheduling when downloading microdescs */
rs->dl_status.backoff = DL_SCHED_RANDOM_EXPONENTIAL;
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23785[HELP!] 7.5a5's(IIRC) Tor cause DNS disruption!2020-06-13T15:15:22Zcypherpunks[HELP!] 7.5a5's(IIRC) Tor cause DNS disruption!0. Download CURRENT latest ALPHA version of Tor Browser[1]
1. Copy Tor executable folder to your system[2], overwrite them.
2. Start Tor as usual, from services.msc.
3. Query/Browse some websites.
4. Suddenly, Tor failed to resolve any d...0. Download CURRENT latest ALPHA version of Tor Browser[1]
1. Copy Tor executable folder to your system[2], overwrite them.
2. Start Tor as usual, from services.msc.
3. Query/Browse some websites.
4. Suddenly, Tor failed to resolve any domain names!! This is critical!
5. Download current STABLE version of Tor.
6. Stop Tor daemon and overwrite with stable files.
7. Start Tor. Now Tor successfully query any domains as normal.
A part of my Torrc:
"DNSPort ...."
TL;DR
I am using Tor as SOCKS proxy and DNS resolver(DNSPort).
Latest Tor, which incuded in current alpha, caused a problem.
Please fix it.
[1] I did this because I want to test v3 onions.
[2] I already have Tor daemon on this PC.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23756tor's .gitlab-ci.yml is doing mirroring? why?2020-06-13T15:42:36ZIsis Lovecrufttor's .gitlab-ci.yml is doing mirroring? why?Currently in master we have the following stanza in our .gitlab-ci.yml (from #22891):
```
update: ...Currently in master we have the following stanza in our .gitlab-ci.yml (from #22891):
```
update:
script:
- "apt-get install -y --fix-missing git openssh-client"
# Run ssh-agent (inside the build environment)
- eval $(ssh-agent -s)
# Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store
- ssh-add <("$DEPLOY_KEY")
# For Docker builds disable host key checking. Be aware that by adding that
# you are suspectible to man-in-the-middle attacks.
# WARNING: Use this only with the Docker executor, if you use it with shell
# you will overwrite your user's SSH config.
- mkdir -p ~/.ssh
- '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
# In order to properly check the server's host key, assuming you created the
# SSH_SERVER_HOSTKEYS variable previously, uncomment the following two lines
# instead.
- mkdir -p ~/.ssh
- '[[ -f /.dockerenv ]] && echo "$SSH_SERVER_HOSTKEYS" > ~/.ssh/known_hosts'
- echo "merging from torgit"
- git config --global user.email "labadmin@oniongit.eu"
- git config --global user.name "gitadmin"
- "mkdir tor"
- "cd tor"
- git clone --bare https://git.torproject.org/tor.git
- git push --mirror git@oniongit.eu:network/tor.git
```
Why are we doing this? Can we put a cronjob on the oniongit.eu server instead? It's pretty weird and frankly unexpected that my personal fork of tor at https://gitlab.com/isis/tor is cloning the official tor repo and then trying to mirror it to oniongit.eu. It also has a bunch of other problems:
* The `ssh-add` line [is broken, causing CI to fail because it sits there forever waiting for a passphrase](https://gitlab.com/isis/tor/-/jobs/34990901).
I was originally going to patch the `ssh-add` line to instead be `[[ -n "${DEPLOY_KEY}" -a -r "$DEPLOY_KEY" ]] && ssh-add "$DEPLOY_KEY" <<<""` but if I fix that, then all the rest of this script would run, so I'm rather glad it's failing on a more innocuous command.
* Even if the `ssh-add` line weren't broken, this whole thing fails unless it's being run from a fork on oniongit.eu.
* Why is it disabling SSH hostkey checking?!
* Why is it making the `~/.ssh` directory twice?
* Why is it assuming that environment variables are set? e.g. `$FOO` versus `${FOO}` or better `test -n ${FOO}`
* Why is it unconditionally setting (global!) git config options? (I assume to disable the warning that git spits out when you don't have `$GIT_{AUTHOR,COMMITTER}_{NAME,EMAIL}` set, but why would a CI config set them globally instead of just setting the correct environment variables?)
* Why are the mirror URLs hardcoded?
* Why is the git username and email hardcoded?
* Why is any of this even running when I push to https://gitlab.com/isis/tor?
* Why is any of this even running when I push anywhere?
* Why is it unconditionally starting an ssh-agent?
* Why is using the existence of a ([deprecated!](https://superuser.com/questions/1021834/what-are-dockerenv-and-dockerinit#1021925)) `/.dockerenv` file to determine if we're in a docker container?
* Why is it assuming we're in the _correct_ docker container, when lots of things, especially lots of CI systems, use docker?
I'm sorry if this is all necessary and I'm just not understanding the setup, but it's all just extremely unexpected behaviour from what is supposed to be a CI config file. Further, it's not even doing the same testing as our .travis.yml, but I'll make another ticket for that issue.Tor: unspecifiedTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/23620Tor lies about "Optimistically trying directory fetches again"2020-06-13T15:14:31ZteorTor lies about "Optimistically trying directory fetches again"My tor hasn't sent anything to the network for 15 minutes, but it keeps telling me `Application request when we haven't used client functionality lately. Optimistically trying directory fetches again.`
My laptop was asleep, and when I w...My tor hasn't sent anything to the network for 15 minutes, but it keeps telling me `Application request when we haven't used client functionality lately. Optimistically trying directory fetches again.`
My laptop was asleep, and when I woke it up, Tor tried to connect to the network a few times, and then ended up in this state.
```
21/9/17, 12:35:33.100 [NOTICE] Average packaged cell fullness: 67.067%. TLS write overhead: 4%
21/9/17, 12:46:37.900 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working.
21/9/17, 12:46:37.900 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working.
22/9/17, 11:42:02.700 [NOTICE] Your system clock just jumped 65128 seconds forward; assuming established circuits no longer work.
22/9/17, 11:42:02.700 [NOTICE] Heartbeat: Tor's uptime is 4 days 16:01 hours, with 0 circuits open. I've sent 11.27 MB and received 124.39 MB.
22/9/17, 11:42:02.700 [NOTICE] Average packaged cell fullness: 67.151%. TLS write overhead: 4%
22/9/17, 11:52:39.800 [NOTICE] Application request when we haven't used client functionality lately. Optimistically trying directory fetches again.
22/9/17, 11:54:39.000 [NOTICE] Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. (waiting for circuit)
22/9/17, 12:05:05.400 [NOTICE] Application request when we haven't used client functionality lately. Optimistically trying directory fetches again.
(repeats many times)
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23613some control protocol GETINFO downloads/networkstatus keys are lies2020-06-13T15:14:29ZTaylor Yusome control protocol GETINFO downloads/networkstatus keys are liesSome of the `GETINFO downloads/networkstatus/*` keys are misleadingly named, and some can't possibly produce what they claim to do given the internal state of tor.
During bootstrap, only one flavor of consensus gets downloaded, but ther...Some of the `GETINFO downloads/networkstatus/*` keys are misleadingly named, and some can't possibly produce what they claim to do given the internal state of tor.
During bootstrap, only one flavor of consensus gets downloaded, but there are separate download schedules for mirror vs authority. After bootstrap, there are separate download schedules for each flavor of consensus. Currently, the control protocol returns authority and mirror bootstrap schedules when asked for ns and microdesc bootstrap schedules, respectively.
We should accept `downloads/networkstatus/mirror/bootstrap` and `downloads/networkstatus/authority/bootstrap` keywords and return the appropriate schedules.
`downloads/networkstatus/ns/bootstrap` and `downloads/networkstatus/microdesc/bootstrap` should only return valid results for the flavor we're using to bootstrap. There is the question of whether to return the mirror or authority schedule.
If the controller doesn't specify bootstrap vs running, should we use the "running" schedule during bootstrap if we're asked for a flavor that we're not using to bootstrap?
We should return an error code like `552` (unrecognized entity -- or is a different code better here?) if the requested information isn't available.
Thanks to teor for feedback.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23357Build with non-Cross-DSO CFI2020-06-13T15:13:10ZTracBuild with non-Cross-DSO CFIControl Flow Integrity is an exploit mitigation. clang/llvm has a CFI implementation that can be used on hardened operating systems like HardenedBSD.
When lld is the compiler, non-Cross-DSO CFI from clang/llvm can be used. I've tested t...Control Flow Integrity is an exploit mitigation. clang/llvm has a CFI implementation that can be used on hardened operating systems like HardenedBSD.
When lld is the compiler, non-Cross-DSO CFI from clang/llvm can be used. I've tested this on HardenedBSD with a very basic configuration.
Attached is a candidate patch for enabling non-Cross-DSO CFI for the core Tor application.
**Trac**:
**Username**: shawn.webbTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23250tor-0.3.0.10: test failure on NetBSD2020-06-13T15:12:44ZTractor-0.3.0.10: test failure on NetBSDWhen running the self tests on NetBSD, there is one problem:
```
===> Testing for tor-0.3.0.10
/usr/bin/make check-TESTS check-local
PASS: src/test/test
PASS: src/test/test-slow
PASS: src/test/test-memwipe
PASS: src/test/test_workqueue...When running the self tests on NetBSD, there is one problem:
```
===> Testing for tor-0.3.0.10
/usr/bin/make check-TESTS check-local
PASS: src/test/test
PASS: src/test/test-slow
PASS: src/test/test-memwipe
PASS: src/test/test_workqueue
PASS: src/test/test_keygen.sh
PASS: src/test/test-timers
SKIP: src/test/fuzz_static_testcases.sh
PASS: src/test/test_zero_length_keys.sh
PASS: src/test/test_workqueue_cancel.sh
SKIP: src/test/test_workqueue_efd.sh
SKIP: src/test/test_workqueue_efd2.sh
PASS: src/test/test_workqueue_pipe.sh
PASS: src/test/test_workqueue_pipe2.sh
PASS: src/test/test_workqueue_socketpair.sh
SKIP: src/test/test_switch_id.sh
PASS: src/test/test_ntor.sh
FAIL: src/test/test_bt.sh
============================================================================
Testsuite summary for tor 0.3.0.10
============================================================================
# TOTAL: 17
# PASS: 12
# SKIP: 4
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
============================================================================
```
The test log:
```
# less ./src/test/test_bt.sh.log
OK
[1] Abort trap (core dumped) "${builddir:-.}/... |
Done "${PYTHON:-pytho...
BAD
============================================================ T= 1502824395
Tor died: Caught signal 11
0x73c0a4bd <crash_handler+0x73c00041> at ./src/test/test-bt-cl
[1] Abort trap (core dumped) "${builddir:-.}/... |
Done(1) "${PYTHON:-pytho...
-158318
FAIL src/test/test_bt.sh (exit status: 1)
```
**Trac**:
**Username**: wizTor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/23234Possible problem with bootstrapping logic (Problem bootstrapping. Stuck at 53...2020-06-13T15:12:42Zs7rPossible problem with bootstrapping logic (Problem bootstrapping. Stuck at 53%: Loading relay descriptors. (No route to host; NOROUTE; count 7; recommendation warn)After an upgrade to latest git master `Tor 0.3.2.0-alpha-dev (git-257f50b22fbaf9c9)` got some bootstrapping complaints that seam to be triggered by the DirGuard being offline. This is a bridge, and was taken offline few days ago by a pow...After an upgrade to latest git master `Tor 0.3.2.0-alpha-dev (git-257f50b22fbaf9c9)` got some bootstrapping complaints that seam to be triggered by the DirGuard being offline. This is a bridge, and was taken offline few days ago by a power failure. The hard drive was not affected so the files in datadirectory were kept.
```
Aug 14 00:28:57.000 [notice] Starting with guard context "default"
Aug 14 00:28:57.000 [notice] Bootstrapped 45%: Asking for relay descriptors
Aug 14 00:28:57.000 [warn] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (No route to host; NOROUTE; count 1; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (No route to host; NOROUTE; count 3; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] 2 connections have failed:
Aug 14 00:28:58.000 [warn] 2 connections died in state connect()ing with SSL state (No SSL object)
Aug 14 00:28:58.000 [warn] Problem bootstrapping. Stuck at 45%: Asking for relay descriptors. (No route to host; NOROUTE; count 4; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] 3 connections have failed:
Aug 14 00:28:58.000 [warn] 3 connections died in state connect()ing with SSL state (No SSL object)
Aug 14 00:28:58.000 [notice] Bootstrapped 53%: Loading relay descriptors
Aug 14 00:28:58.000 [warn] Problem bootstrapping. Stuck at 53%: Loading relay descriptors. (No route to host; NOROUTE; count 2; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] 5 connections have failed:
Aug 14 00:28:58.000 [warn] 5 connections died in state connect()ing with SSL state (No SSL object)
Aug 14 00:28:58.000 [warn] Problem bootstrapping. Stuck at 53%: Loading relay descriptors. (No route to host; NOROUTE; count 4; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] 7 connections have failed:
Aug 14 00:28:58.000 [warn] 7 connections died in state connect()ing with SSL state (No SSL object)
Aug 14 00:28:58.000 [warn] Problem bootstrapping. Stuck at 53%: Loading relay descriptors. (No route to host; NOROUTE; count 6; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] 9 connections have failed:
Aug 14 00:28:58.000 [warn] 9 connections died in state connect()ing with SSL state (No SSL object)
Aug 14 00:28:58.000 [warn] Problem bootstrapping. Stuck at 53%: Loading relay descriptors. (No route to host; NOROUTE; count 7; recommendation warn; host 5EB8D862E70981B8690DEDEF546789E26AB2BD24 at 109.163.234.5:443)
Aug 14 00:28:58.000 [warn] 10 connections have failed:
Aug 14 00:28:58.000 [warn] 10 connections died in state connect()ing with SSL state (No SSL object)
```
The complaints stop when Bootstrap reaches 80%, but the "missing descriptors from some of our primary entry guards" follows immediately:
```
Aug 14 00:29:10.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Aug 14 00:29:10.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Aug 14 00:29:11.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Aug 14 00:29:12.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Aug 14 00:29:12.000 [notice] Bootstrapped 100%: Done
Aug 14 00:29:12.000 [notice] Now checking whether ORPort xx.br.id.ge:yy is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Aug 14 00:29:13.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for some of our primary entry guards
Aug 14 00:29:13.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for some of our primary entry guards
Aug 14 00:29:13.000 [notice] We now have enough directory information to build circuits.
Aug 14 00:29:13.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Aug 14 00:29:13.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
```
One problem is: How come it just bootstrapped 100%, and 1 second later Tor realizes it is missing descriptors for some of our primary guards?
Second: Why does it report no route to host and SSL connections failing in state connect if the internet connection is working good and the problem is just at the endpoint? Even if the problem is not at the endpoint this particular log message is awfully confusing.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23168Guard sample calls relay descriptors a "consensus"2020-06-13T15:12:38ZteorGuard sample calls relay descriptors a "consensus"[info] router_load_routers_from_string: 96 elements to add
[info] sampled_guards_update_from_consensus: Updating sampled guard status based on received consensus.
The message should either say "received directory document(s)", or actual...[info] router_load_routers_from_string: 96 elements to add
[info] sampled_guards_update_from_consensus: Updating sampled guard status based on received consensus.
The message should either say "received directory document(s)", or actually describe the directory document it just received.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23116tor stops responding to Ctrl-C and circuits while in infinite descriptor down...2020-06-13T15:12:28Zteortor stops responding to Ctrl-C and circuits while in infinite descriptor download loopI'm running tor master (ce07b4dd9) and 0.3.0.9 on macOS 10.12.5 x86_64 on a relay with a private IP address over a slow link.
It seems to get in an infinite loop with these kinds of messages, and stops responding on the ORPort and to Ct...I'm running tor master (ce07b4dd9) and 0.3.0.9 on macOS 10.12.5 x86_64 on a relay with a private IP address over a slow link.
It seems to get in an infinite loop with these kinds of messages, and stops responding on the ORPort and to Ctrl-C (shutdown):
```
Aug 05 09:04:10.000 [info] handle_response_fetch_microdesc: Received answer to microdescriptor request (status 200, body size 40905) from server '149.172.149.170:9030'
Aug 05 09:04:10.000 [info] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for some of our primary entry guards
Aug 05 09:04:10.000 [info] update_consensus_router_descriptor_downloads: 0 router descriptors downloadable. 0 delayed; 0 present (0 of those were in old_routers); 0 would_reject; 0 wouldnt_use; 6960 in progress.
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22926The Tor compression code can call functions that are NULL2020-06-13T15:11:45ZteorThe Tor compression code can call functions that are NULLThe new Tor compression code in 0.3.1 assumes that all the compression functions are bound at runtime.
For example, tor_lzma_method_supported() returns 1 when HAVE_LZMA is defined, but that doesn't mean that lzma_version_string() has ac...The new Tor compression code in 0.3.1 assumes that all the compression functions are bound at runtime.
For example, tor_lzma_method_supported() returns 1 when HAVE_LZMA is defined, but that doesn't mean that lzma_version_string() has actually been bound to a non-NULL address in the binary.
This is more likely to happens when tor is used as a shared library rather than linked as an executable (shadow, iOS), and when using weak, lazy symbol binding.
This might not be an issue we can solve unless we check for all the symbols being NULL at runtime. Maybe the responsibility for proper linking is on people who are compiling tor with weak, lazy symbol binding.
This bug was discovered by Rob Jansen when running shadow.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22817SAFECOOKIE description in control spec does not have verifiable test vectors2020-06-13T15:11:15ZTracSAFECOOKIE description in control spec does not have verifiable test vectorsThe SAFECOOKIE documentation in https://gitweb.torproject.org/torspec.git/tree/control-spec.txt describes the hashing process, but doesn't provide verifiable sample input/output pairs that would be hugely helpful for implementing it.
I ...The SAFECOOKIE documentation in https://gitweb.torproject.org/torspec.git/tree/control-spec.txt describes the hashing process, but doesn't provide verifiable sample input/output pairs that would be hugely helpful for implementing it.
I worked around this by using the server hash reported by the Tor server and access to the Stem code to verify the expected inputs and outputs, but this is a lot of extra overhead beyond the spec document.
A possible example of useful information:
example server hash: F917E3B73CBEDC66A85EBD60F25E100552B89645FDEC87D69E9BD4E81E25B604
example server nonce: F8B52E3424733A4081FCCD2A64FC9C67F0FD3A9639C1E09D5558C3B4B9B973E1
example client nonce: 3b
example client hash: c6213ce626df95c1b5f5c0b4fe77c8ff1a05c7fd7f5e5a9843d2b4d009b5d340
The above vectors should be decoded to bytes and input to an HMAC initialized with the appropriate server-to-controller initialization key described in this spec to produce a matching hex string as provided by the Tor process in its AUTHCHALLENGE reply. The same vectors should also be decoded to bytes and input to an HMAC initialized with the appropriate controller-to-server initialization key described in this spec to produce the client hash.
**Trac**:
**Username**: amphetamineTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22717Rename channelpadding.c's CHANNEL_IS_CLIENT to avoid confusion2020-06-13T15:20:43ZteorRename channelpadding.c's CHANNEL_IS_CLIENT to avoid confusionThere is already a channel_is_client() function in channel.[ch], with different arguments and semantics.
And while we're doing that, we should make the newly renamed CHANNEL_IS_CLIENT() call channel.h's channel_is_client(), because it's...There is already a channel_is_client() function in channel.[ch], with different arguments and semantics.
And while we're doing that, we should make the newly renamed CHANNEL_IS_CLIENT() call channel.h's channel_is_client(), because it's the right abstraction to use.
We could survive releasing 0.3.1 without this fix, because it's not a bug (yet).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22689hs: Stop intro points being used as single hop proxies2020-06-13T15:22:26Zteorhs: Stop intro points being used as single hop proxiesThis prevents them knowing both the service and client IP addresses, and therefore being targets for network traffic logging, sybil, or hacking attacks.
We need to implement the following checks:
* if an introduction point was made usin...This prevents them knowing both the service and client IP addresses, and therefore being targets for network traffic logging, sybil, or hacking attacks.
We need to implement the following checks:
* if an introduction point was made using a direct connection (single onion services), refuse direct client connections,
* for v3 intro points, always refuse direct client connections
* for v2 intro points, refuse direct client connections based on a consensus parameter
* ~~if the rend point was made using a direct connection (custom client, no tor2web for HSv3), refuse direct service connections (single onion services).~~
See #22688 for how this is done for HSDir3s using channel_is_client(). The comments in that patch explain why it works.
We could even refactor the common code out of connection_dir_is_anonymous() into connection_is_anonymous(), and avoid including channel[tls].h into directory.c.
I'm not sure if I will get time to do this, so please feel free to take this ticket.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22355Update dir-spec with client fallback directory mirror attempt and timeout beh...2020-06-13T15:09:20ZteorUpdate dir-spec with client fallback directory mirror attempt and timeout behaviourLet's add these lines:
Clients try several fallback directory mirrors, and use the first one that connects. Each attempt happens after a short delay, regardless of the state of the previous attempt, until at least one attempt has connec...Let's add these lines:
Clients try several fallback directory mirrors, and use the first one that connects. Each attempt happens after a short delay, regardless of the state of the previous attempt, until at least one attempt has connected.
When several fallback directory mirrors have failed, clients start trying directory authorities in a similar fashion.
Somewhere near:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3292
I don't think we designed any explicit timeout behaviour, so we are probably using whatever was there before 0.2.8.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/22310Tor 0.3.x clients won't use Guard-flagged relays as Guards if they don't have...2020-06-13T15:09:12ZRoger DingledineTor 0.3.x clients won't use Guard-flagged relays as Guards if they don't have V2Dir, throwing off consensus position weightsStarting in Tor 0.3.0, clients have additional constraints on what counts as a usable guard. Specifically, `node_is_possible_guard()` now demands `node_is_dir(node)` before it will consider node as a guard.
But the path position weights...Starting in Tor 0.3.0, clients have additional constraints on what counts as a usable guard. Specifically, `node_is_possible_guard()` now demands `node_is_dir(node)` before it will consider node as a guard.
But the path position weights in the consensus are based on the Guard flag.
This inconsistency will lead to Guards that don't have the V2Dir flag being way underused, and Guards that do have the V2Dir flag being overused.Tor: 0.3.3.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/21676Increase MIN_BW_TO_ADVERTISE_DIRSERVER above RELAY_REQUIRED_MIN_BANDWIDTH2020-06-13T15:09:13ZteorIncrease MIN_BW_TO_ADVERTISE_DIRSERVER above RELAY_REQUIRED_MIN_BANDWIDTHMIN_BW_TO_ADVERTISE_DIRSERVER is 50KB, but RELAY_REQUIRED_MIN_BANDWIDTH is 75KB. So we might want to make the DIRSERVER bandwidth at least 150 KB, so that a dirserver can at least deliver one client one consensus in 10 seconds (clients g...MIN_BW_TO_ADVERTISE_DIRSERVER is 50KB, but RELAY_REQUIRED_MIN_BANDWIDTH is 75KB. So we might want to make the DIRSERVER bandwidth at least 150 KB, so that a dirserver can at least deliver one client one consensus in 10 seconds (clients generally wait a few seconds for dirservers to deliver a consensus).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21425entry_list_is_constrained() should look at the guard_selection_t object2020-06-13T15:06:12ZNick Mathewsonentry_list_is_constrained() should look at the guard_selection_t objectWe use entry_list_is_constrained() in a few places to find out if our list of entry points is highly limited (e.g., to a few bridges or a few EntryNodes). But it doesn't do that very well: instead, it looks to see if EntryNodes is set ...We use entry_list_is_constrained() in a few places to find out if our list of entry points is highly limited (e.g., to a few bridges or a few EntryNodes). But it doesn't do that very well: instead, it looks to see if EntryNodes is set or UseBridges is set.
We have better ways: we should be looking at the size of the guard sample, or something.Tor: unspecified