The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:53:11Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26395tor_bug_occurred_(): Bug: ../src/or/consdiffmgr.c:261: cdm_diff_ht_check_and_...2020-06-27T13:53:11ZTractor_bug_occurred_(): Bug: ../src/or/consdiffmgr.c:261: cdm_diff_ht_check_and_note_pending: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed.Logged by my relay : B143D439B72D239A419F8DCE07B8A8EB1B486FA7
Here is the full entry
```
Jun 17 17:00:54.000 [warn] tor_bug_occurred_(): Bug: ../src/or/consdiffmgr.c:261: cdm_diff_ht_check_and_note_pending: Non-fatal assertion ent->cd...Logged by my relay : B143D439B72D239A419F8DCE07B8A8EB1B486FA7
Here is the full entry
```
Jun 17 17:00:54.000 [warn] tor_bug_occurred_(): Bug: ../src/or/consdiffmgr.c:261: cdm_diff_ht_check_and_note_pending: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed. (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug: Non-fatal assertion ent->cdm_diff_status != CDM_DIFF_PRESENT failed in cdm_diff_ht_check_and_note_pending at ../src/or/consdiffmgr.c:261. Stack trace: (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x42) [0x7ff791259802] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xca) [0x7ff7912744aa] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug: /usr/bin/tor(consdiffmgr_rescan+0xc9d) [0x7ff7911f070d] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug: /usr/bin/tor(+0x5739f) [0x7ff79112639f] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x414) [0x7ff7907dd254] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x255) [0x7ff791127585] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug: /usr/bin/tor(tor_main+0x1e75) [0x7ff79112aff5] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x7ff791122d49] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7ff78f7f2ead] (on Tor 0.3.2.10 )
Jun 17 17:00:54.000 [warn] Bug: /usr/bin/tor(+0x53d99) [0x7ff791122d99] (on Tor 0.3.2.10 )
```
**Trac**:
**Username**: fcornuTor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26388Update tor copyright headers to year 20182020-06-27T13:53:11Zrl1987Update tor copyright headers to year 2018Now it says:
```
* Copyright (c) 2007-2017, The Tor Project, Inc. */
```
Should be updated to 2018. We have updateCopyright.pl for this.Now it says:
```
* Copyright (c) 2007-2017, The Tor Project, Inc. */
```
Should be updated to 2018. We have updateCopyright.pl for this.Tor: 0.3.4.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/26387sandbox incompatible with glibc 2.272020-06-27T13:53:11Zcypherpunkssandbox incompatible with glibc 2.27Similar to legacy/trac#24315. If I enable the sandbox on my system, I get killed with:
```
(Sandbox) Caught a bad syscall attempt (syscall openat)
tor(+0x1a439a)[0x55d0af97d39a]
/lib64/libpthread.so.0(open64+0x4b)[0x7f74ed0951cb]
/lib6...Similar to legacy/trac#24315. If I enable the sandbox on my system, I get killed with:
```
(Sandbox) Caught a bad syscall attempt (syscall openat)
tor(+0x1a439a)[0x55d0af97d39a]
/lib64/libpthread.so.0(open64+0x4b)[0x7f74ed0951cb]
/lib64/libpthread.so.0(open64+0x4b)[0x7f74ed0951cb]
tor(tor_open_cloexec+0x40)[0x55d0af963440]
tor(start_writing_to_file+0x17a)[0x55d0af976e7a]
tor(+0x19df5b)[0x55d0af976f5b]
tor(+0x19e0a8)[0x55d0af9770a8]
tor(or_state_save+0x15b)[0x55d0af8954cb]
tor(+0x52e3b)[0x55d0af82be3b]
/usr/lib64/libevent-2.1.so.6(+0x236fa)[0x7f74eddf06fa]
/usr/lib64/libevent-2.1.so.6(event_base_loop+0x57f)[0x7f74eddf164f]
tor(do_main_loop+0x254)[0x55d0af82cb54]
tor(tor_run_main+0x1025)[0x55d0af82ef15]
tor(tor_main+0x3a)[0x55d0af8276ba]
tor(main+0x19)[0x55d0af827449]
/lib64/libc.so.6(__libc_start_main+0xe7)[0x7f74eccdb9f7]
tor(_start+0x2a)[0x55d0af82749a]
```
strace:
```
write(1, "(Sandbox) Caught a bad syscall a"..., 48(Sandbox) Caught a bad syscall attempt (syscall ) = 48
write(1, "openat", 6openat) = 6
```https://gitlab.torproject.org/tpo/core/tor/-/issues/26383Move structures out of or.h2020-06-27T13:53:11ZNick MathewsonMove structures out of or.hAs part of the big 0.3.5 refactoring, we want to split or.h into lots of little headers. And as part of that, we want to get each structure into its own header.As part of the big 0.3.5 refactoring, we want to split or.h into lots of little headers. And as part of that, we want to get each structure into its own header.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26379Rend-spec isn't clear about role of first layer of descriptor encryption2020-06-27T13:53:11ZSteven MurdochRend-spec isn't clear about role of first layer of descriptor encryptionIn `[HS-DESC-FIRST-LAYER]` of `rend-spec-v3.txt` it says:
The first layer of HS descriptor encryption is designed to protect
descriptor confidentiality against entities who don't know the blinded
public key of the hidden service.
...In `[HS-DESC-FIRST-LAYER]` of `rend-spec-v3.txt` it says:
The first layer of HS descriptor encryption is designed to protect
descriptor confidentiality against entities who don't know the blinded
public key of the hidden service.
However the HSDir does know the blinded public key, as that's part of the `descriptor-signing-key-cert` described in `[DESC-OUTER]`. Should the above quote instead be "...against entities who don't know the _public identity master key_ of the hidden service"Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26378test_rust.sh fails on src/rust/crypto2020-06-27T13:53:11ZGeorge Kadianakistest_rust.sh fails on src/rust/cryptoThe latest travis builds fail on the rust tests after legacy/trac#26258 got merged (i guess). Here are some fails:
```
--> external/crypto_digest.rs:74:1
|
74 | const N_DIGEST_ALGORITHMS: usize = DIGEST_SHA3_512 as usize + 1;
| ...The latest travis builds fail on the rust tests after legacy/trac#26258 got merged (i guess). Here are some fails:
```
--> external/crypto_digest.rs:74:1
|
74 | const N_DIGEST_ALGORITHMS: usize = DIGEST_SHA3_512 as usize + 1;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(dead_code)] on by default
warning: type alias is never used: `smartlist_t`
--> external/crypto_digest.rs:120:1
|
120 | type smartlist_t = Stringlist;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
warning: constant item is never used: `N_DIGEST_ALGORITHMS`
--> external/crypto_digest.rs:74:1
|
74 | const N_DIGEST_ALGORITHMS: usize = DIGEST_SHA3_512 as usize + 1;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(dead_code)] on by default
warning: type alias is never used: `smartlist_t`
--> external/crypto_digest.rs:120:1
|
120 | type smartlist_t = Stringlist;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Finished dev [unoptimized + debuginfo] target(s) in 3.39 secs
Running /home/travis/build/torproject/tor/tor-0.3.4.2-alpha-dev/_build/src/rust/target/debug/deps/external-99409f0e61b6d8c2
```
See https://api.travis-ci.org/v3/job/392350333/log.txt etc.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26376add cross compiling docs2022-06-22T15:08:16ZAlex Xuadd cross compiling docssince apparently nobody on #tor-dev knows, I wrote a document.
https://cgit.alxu.ca/tor.git/commit/?h=building-tor-mingw-docs
setting catalyst as reviewer since they say they tried it and it works.since apparently nobody on #tor-dev knows, I wrote a document.
https://cgit.alxu.ca/tor.git/commit/?h=building-tor-mingw-docs
setting catalyst as reviewer since they say they tried it and it works.https://gitlab.torproject.org/tpo/core/tor/-/issues/26374MacOS Sandbox2020-07-28T19:28:53ZAlexander Færøyahf@torproject.orgMacOS SandboxMaybe we should have a sandbox for little-t-tor for MacOS.
Here are some documents that might be relevant:
- https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf
- https://www.unix.com/man-page/osx/7/sandbox/
...Maybe we should have a sandbox for little-t-tor for MacOS.
Here are some documents that might be relevant:
- https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf
- https://www.unix.com/man-page/osx/7/sandbox/
- https://dl.packetstormsecurity.net/papers/general/apple-sandbox.pdf
- https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html
Some slides:
- http://newosxbook.com/files/HITSB.pdfTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26373test_rust.sh should detect when it's being invoked improperly and error out2020-07-28T19:19:51ZTaylor Yutest_rust.sh should detect when it's being invoked improperly and error outWhile attempting to test legacy/trac#26258, I noticed that running src/test/test_rust.sh from the top of the source tree exited with status 0 and no output. It should probably detect that it failed to find any Cargo.toml files and exit ...While attempting to test legacy/trac#26258, I noticed that running src/test/test_rust.sh from the top of the source tree exited with status 0 and no output. It should probably detect that it failed to find any Cargo.toml files and exit with a failure status with an error message. (This seems to happen because some necessary environment variables aren't set.)
Prior to legacy/trac#26258, the find invocation failing would probably have taken care of this, so this change should probably get back ported to the same releases.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26372Search for python3 with a better list of names.2020-06-27T13:53:12ZNick MathewsonSearch for python3 with a better list of names.Right now we search with:
```
AC_CHECK_PROGS(PYTHON, [python python2 python2.7 python3 python3.3])
```
But we'd like to prefer python3, and we'd like to prefer more recent versions. Ben McGinnes, who reported this bug, recommends
```
AC...Right now we search with:
```
AC_CHECK_PROGS(PYTHON, [python python2 python2.7 python3 python3.3])
```
But we'd like to prefer python3, and we'd like to prefer more recent versions. Ben McGinnes, who reported this bug, recommends
```
AC_CHECK_PROGS(PYTHON, [python3.6 python3.5 python3.4 python3.3 python3 python2.7 python2])
```
As an alternative, he suggests that we have a look at the GPGME Python binding M4 files, modulo license issues.
Personally, I'm thinking we'd like something like "python3, then known python3.x versions in descending order, then python, then python2, then python 2.7".
Having typed this ticket out, "Python" no longer looks like a word to me.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26369Re-fetch onion service descriptor for isolated request2021-09-30T13:46:30ZMatthew FinkelRe-fetch onion service descriptor for isolated requestWhen tor receives a new request for connecting to an onion service and this request has different isolation flags/parameters than a previous (recent) request, then tor should re-fetch the service descriptor (if we already have it). Curre...When tor receives a new request for connecting to an onion service and this request has different isolation flags/parameters than a previous (recent) request, then tor should re-fetch the service descriptor (if we already have it). Currently, tor notices it already has the descriptor in its cache and it doesn't refetch. This is a nice performance optimization, but if a client is requesting an isolated circuit for an onion service, then we shouldn't leak that we already have the descriptor in our cache.
Instead of only using the onion service name as the map-key, we can add a unique value of the circuit isolation information (hash?).Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26368Consider circuit isolation when closing redundant intro points2022-06-17T13:31:46ZMatthew FinkelConsider circuit isolation when closing redundant intro pointsWhen tor receives more than one request for connecting to an onion service within a short amount of time, and these requests are circuit-isolated (by sockauth, or something else), tor will launch multiple connections to an intro point (o...When tor receives more than one request for connecting to an onion service within a short amount of time, and these requests are circuit-isolated (by sockauth, or something else), tor will launch multiple connections to an intro point (one for each isolated request). When the first introduction succeeds (intro acks), tor closes any circuits it considers redundant (`rend_client_close_other_intros`). Tor should only close circuits if the socks request isolation bits match.https://gitlab.torproject.org/tpo/core/tor/-/issues/26367Consider removing tor2web mode2021-09-30T13:46:30ZAlexander Færøyahf@torproject.orgConsider removing tor2web modeIt sounds like tor2web mode wont work after the DoS protection code was added.
Would it make sense to get rid of this?It sounds like tor2web mode wont work after the DoS protection code was added.
Would it make sense to get rid of this?Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/26366Possible duplicated logic in connection_edge_finished_connecting() and connec...2021-09-30T13:46:30ZAlexander Færøyahf@torproject.orgPossible duplicated logic in connection_edge_finished_connecting() and connection_exit_connect()There's some possible duplicated logic in `connection_edge_finished_connecting()` and `connection_exit_connect()`:
When `conn->state = EXIT_CONN_STATE_OPEN` is set we have some duplicated code on when to begin writing. There is a commen...There's some possible duplicated logic in `connection_edge_finished_connecting()` and `connection_exit_connect()`:
When `conn->state = EXIT_CONN_STATE_OPEN` is set we have some duplicated code on when to begin writing. There is a comment that might be relevant around some Windows logic in the switch/case block around the `result` variable in `connection_exit_connect()`.https://gitlab.torproject.org/tpo/core/tor/-/issues/26360Transport plugins deadlock if they write too much to stderr2020-06-27T13:53:13ZDavid Fifielddcf@torproject.orgTransport plugins deadlock if they write too much to stderr[launch_managed_proxy](https://gitweb.torproject.org/tor.git/tree/src/or/transports.c?id=bc951e83aac770d123118bf485d14490c2539048#n516), via [tor_spawn_background](https://gitweb.torproject.org/tor.git/tree/src/common/util.c?id=bc951e83a...[launch_managed_proxy](https://gitweb.torproject.org/tor.git/tree/src/or/transports.c?id=bc951e83aac770d123118bf485d14490c2539048#n516), via [tor_spawn_background](https://gitweb.torproject.org/tor.git/tree/src/common/util.c?id=bc951e83aac770d123118bf485d14490c2539048#n4232), opens a pipe from the child process's stderr, but never reads from the pipe. If the child process writes too much to its stderr, eventually an OS buffer fills up and the child process hangs. This manifests in the tor log as "No running bridges."
Seems like this has always been a problem, but it only showed up recently with Snowflake, which by default logs to stderr and is more chatty than past transports have been. See legacy/trac#25600. The problem went away when instructing snowflake-client to log to a file instead of to stderr.
Ccing ahf as suggested by arma.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26359DoS and timed attacks via unencrypted network time protocols2022-06-17T14:07:59ZTracDoS and timed attacks via unencrypted network time protocolsIf a device relies on NTP (or any other unencrypted network time protocol), ISP or other party in the middle can manipulate unencrypted packages to set wrong time. Tor relies on correct time, so ISP can deny Tor usage any time it wants t...If a device relies on NTP (or any other unencrypted network time protocol), ISP or other party in the middle can manipulate unencrypted packages to set wrong time. Tor relies on correct time, so ISP can deny Tor usage any time it wants to. Moreover, attacker controlling the ISP (government or hackers compromising ISP's server) can manipulate time on tor-using device, assisting attacks that involve wrong time.
Embedded systems like routers have no real-time clock hardware and need to set time via network. PCs are often configured to synchronize time via NTP.
Tor should have other way to set the time it needs. It could set time from directory servers and known relays.
**Trac**:
**Username**: time_attackerhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26358relaycell/circbw warning2020-06-27T13:53:13Zrl1987relaycell/circbw warningWhenever I `make test` on macOS, I get this warning:
```
relaycell/circbw: [forking] Jun 12 16:40:58.870 [warn] connection_edge_process_relay_cell: Bug: Somehow I had a connection that matched a data cell with stream ID 0. (on Tor 0.3.4...Whenever I `make test` on macOS, I get this warning:
```
relaycell/circbw: [forking] Jun 12 16:40:58.870 [warn] connection_edge_process_relay_cell: Bug: Somehow I had a connection that matched a data cell with stream ID 0. (on Tor 0.3.4.2-alpha b13abcce480ed766)
```
We should look if there's anything to be fixed.Tor: 0.3.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/26356Tor 0.3.3.6 fails to compile under cygwin (x86_64)2020-07-28T19:23:27ZGeorg KoppenTor 0.3.3.6 fails to compile under cygwin (x86_64)From the 0.3.3.6 blog post's comments (https://blog.torproject.org/comment/275501#comment-275501):
```
I try to build latest tor 0.3.3.6 from source under "x86_64 Cygwin".
Earlier versions did compile, I'm running now "Tor version 0.3.2....From the 0.3.3.6 blog post's comments (https://blog.torproject.org/comment/275501#comment-275501):
```
I try to build latest tor 0.3.3.6 from source under "x86_64 Cygwin".
Earlier versions did compile, I'm running now "Tor version 0.3.2.9 (git-9e8b762fcecfece6)."
Compilation now Fails with the following erros:
make all-am
make[1]: Entering directory '/cygdrive/f/tor-0.3.3.6'
CC src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_0.o
In file included from src/ext/ed25519/ref10/crypto_int32.h:6,
from src/ext/ed25519/ref10/fe.h:4,
from src/ext/ed25519/ref10/fe_0.c:1:
./src/common/torint.h:214:2: error: #error "Can't define ssize_t."
#error "Can't define ssize_t."
^~~~~
./src/common/torint.h:237:2: error: #error "void * is either >8 bytes or <= 2. In either case, I am confused."
#error "void * is either >8 bytes or <= 2. In either case, I am confused."
^~~~~
./src/common/torint.h:241:2: error: #error "Missing type int8_t"
#error "Missing type int8_t"
^~~~~
./src/common/torint.h:244:2: error: #error "Missing type uint8_t"
#error "Missing type uint8_t"
^~~~~
./src/common/torint.h:247:2: error: #error "Missing type int16_t"
#error "Missing type int16_t"
^~~~~
./src/common/torint.h:250:2: error: #error "Missing type uint16_t"
#error "Missing type uint16_t"
^~~~~
./src/common/torint.h:253:2: error: #error "Missing type int32_t"
#error "Missing type int32_t"
^~~~~
./src/common/torint.h:256:2: error: #error "Missing type uint32_t"
#error "Missing type uint32_t"
^~~~~
./src/common/torint.h:259:2: error: #error "Missing type int64_t"
#error "Missing type int64_t"
^~~~~
./src/common/torint.h:262:2: error: #error "Missing type uint64_t"
#error "Missing type uint64_t"
^~~~~
./src/common/torint.h:269:2: error: #error "Seems that your platform doesn't use 2's complement arithmetic. Argh."
#error "Seems that your platform doesn't use 2's complement arithmetic. Argh."
^~~~~
./src/common/torint.h:277:2: error: #error "Can't define LONG_MAX"
#error "Can't define LONG_MAX"
^~~~~
./src/common/torint.h:287:2: error: #error "Can't define INT_MAX"
#error "Can't define INT_MAX"
^~~~~
./src/common/torint.h:299:2: error: #error "Can't define UINT_MAX"
#error "Can't define UINT_MAX"
^~~~~
./src/common/torint.h:309:2: error: #error "Can't define SHORT_MAX"
#error "Can't define SHORT_MAX"
^~~~~
./src/common/torint.h:367:2: error: #error "Can't define SSIZE_MAX"
#error "Can't define SSIZE_MAX"
^~~~~
make[1]: *** [Makefile:6513: src/ext/ed25519/ref10/src_ext_ed25519_ref10_libed25519_ref10_a-fe_0.o] Error 1
make[1]: Leaving directory '/cygdrive/f/tor-0.3.3.6'
make: *** [Makefile:3409: all] Error 2
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26351Update to June GeoIP2 database2020-06-27T13:53:13ZKarsten LoesingUpdate to June GeoIP2 database[My geoip-2018-06-07 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-06-07) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branch...[My geoip-2018-06-07 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-06-07) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.9 and other branches that are still maintained.
(Note to self when I use this ticket as template for next month: 0.3.1 is end of life on 1 July 2018.)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26343Add IPv6 orport for dannenberg2020-06-27T13:53:13ZLinus Nordberglinus@torproject.orgAdd IPv6 orport for dannenbergDirectory authority dannenberg has the following IPv6 ORPort
[2001:678:558:1000::244]:443
The 'dannenberg_ipv6' branch in my public repo adds it to auth_dirs.inc.Directory authority dannenberg has the following IPv6 ORPort
[2001:678:558:1000::244]:443
The 'dannenberg_ipv6' branch in my public repo adds it to auth_dirs.inc.Tor: 0.3.4.x-final