Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:51:59Zhttps://gitlab.torproject.org/legacy/trac/-/issues/17778Memory leak in ntor test2020-06-13T14:51:59ZcypherpunksMemory leak in ntor testThe ntor test contains a memory leak by not freeing the keymap of `server1`.The ntor test contains a memory leak by not freeing the keymap of `server1`.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17776Buffer over-reads in directory and rendcache tests2020-06-13T14:51:59ZcypherpunksBuffer over-reads in directory and rendcache testsSome of the directory and rendcache tests contain buffer over-reads caused by using strings that are too short.Some of the directory and rendcache tests contain buffer over-reads caused by using strings that are too short.Tor: 0.2.8.x-finalcypherpunkscypherpunkshttps://gitlab.torproject.org/legacy/trac/-/issues/17766Comment-only changes to tor2020-06-13T14:51:55ZteorComment-only changes to torMy branch comments-20151204 contains comment-only changes to Tor:
* get_connection_array no longer takes "n"
* Move a comment in router_get_my_descriptor to the correct line
* Update comment for connection_connect
* port is in host ord...My branch comments-20151204 contains comment-only changes to Tor:
* get_connection_array no longer takes "n"
* Move a comment in router_get_my_descriptor to the correct line
* Update comment for connection_connect
* port is in host order, addr is a tor_addr_t so endianness is abstracted
* addr and port can be different from conn->addr and conn->port for proxies
* connection_get_by_type_addr_port_purpose also ignores connections
that are marked for close
Please see https://github.com/teor2345/tor.gitTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17763tor_addr_is_public_for_reject should return 0 for multicast addresses2020-06-13T14:51:54Zteortor_addr_is_public_for_reject should return 0 for multicast addressesThis makes the treatment of addresses from other sources consistent with the implementation of get_interface_address6_list.
This might need to be cherry-picked to:
* #17027 (0.2.7)
* #17610 (0.2.6)
But only once their implementations in...This makes the treatment of addresses from other sources consistent with the implementation of get_interface_address6_list.
This might need to be cherry-picked to:
* #17027 (0.2.7)
* #17610 (0.2.6)
But only once their implementations include tor_addr_is_public_for_reject.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17756Update to December GeoIP2 database2020-06-13T14:51:52ZKarsten LoesingUpdate to December GeoIP2 database[geoip-dec2015](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-dec2015) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4.[geoip-dec2015](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-dec2015) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.4.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17752Null pointer deref in connection_ap_attach_pending()2020-06-13T14:51:50ZDavid Gouletdgoulet@torproject.orgNull pointer deref in connection_ap_attach_pending()My tor client is running on version `0.2.8.0-alpha-dev (git-ee5337e90497e31c)` and I got a crash with a coredump this morning. It happened when one of my hidden service was rebooted and then the torsocks client did try to reconnect.
Las...My tor client is running on version `0.2.8.0-alpha-dev (git-ee5337e90497e31c)` and I got a crash with a coredump this morning. It happened when one of my hidden service was rebooted and then the torsocks client did try to reconnect.
Last notice log:
```
Dec 04 11:39:16.000 [notice] Closing stream for 'SCRUBBED ONION': hidden service is unavailable (try again later).
```
Here is the gdb backtrace of the coredump:
```
[snip]
#3 <signal handler called>
No locals.
#4 connection_ap_attach_pending (retry=retry@entry=1) at src/or/connection_edge.c:801
conn = 0x0
entry_conn_sl_idx = 3
entry_conn_sl_len = 4
entry_conn = 0x0
__FUNCTION__ = "connection_ap_attach_pending"
__func__ = "connection_ap_attach_pending"
#5 0x0000561584871bf4 in connection_ap_rescan_and_attach_pending () at src/or/connection_edge.c:779
entry_conn = 0x561586bcc260
conns = <optimized out>
__FUNCTION__ = "connection_ap_rescan_and_attach_pending"
#6 0x0000561584851da8 in circuit_build_needed_circs (now=now@entry=1449247161) at src/or/circuituse.c:1126
options = 0x561586bcc260
#7 0x00005615847c8288 in run_scheduled_events (now=1449247161) at src/or/main.c:1491
options = 0x561586bcc260
have_dir_info = <optimized out>
i = <optimized out>
[snip]
```
Apparently `conn` is NULL at that point thus this line exploded in`src/or/connection_edge.c`
```
connection_t *conn = ENTRY_TO_CONN(entry_conn);
if (conn->marked_for_close) {
```Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17739Refactor clock skew warning code to avoid duplication2020-06-13T14:51:45ZteorRefactor clock skew warning code to avoid duplicationThe following functions contain very similar clock skew code:
* connection_dir_client_reached_eof
* channel_tls_process_netinfo_cell
* or_state_load
We should unify this code to reduce redundancy and increase consistency.The following functions contain very similar clock skew code:
* connection_dir_client_reached_eof
* channel_tls_process_netinfo_cell
* or_state_load
We should unify this code to reduce redundancy and increase consistency.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17724Unreliable rend_cache_purge test2020-06-13T14:51:41ZcypherpunksUnreliable rend_cache_purge testThe `test_rend_cache_purge` function contains an assertion which verifies that the internal strmap does not change after a purge (`src/test/test_rendcache.c:1044` on 0a701e537778ac9da31049f4efebf7cb2bf9c285).
However, the `rend_cache_pu...The `test_rend_cache_purge` function contains an assertion which verifies that the internal strmap does not change after a purge (`src/test/test_rendcache.c:1044` on 0a701e537778ac9da31049f4efebf7cb2bf9c285).
However, the `rend_cache_purge` function frees the internal strmap and allocates a new one. This turns the assertion in a check whether memory allocation returns the same address as was just freed. The C11 standard mentions that a previous call to `free` is synchronized with a call to `malloc` [0].
I found the issue during a Valgrind run which probably changed the behavior of `free` and `malloc` to track them and caused the assertion to fail.
I am suggesting to remove the assertion because it verifies behavior that does not affect normal operation and (in my case) interferes with testing.
[0] [http://en.cppreference.com/w/c/memory/malloc]Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17722Undefined behavior in tor_cert_checksig2020-06-13T14:51:40ZcypherpunksUndefined behavior in tor_cert_checksigThere is undefined behavior in the `tor_cert_checksig` function when no separate public key is given (such as in the `src/test/test_routerkeys.c:140`).There is undefined behavior in the `tor_cert_checksig` function when no separate public key is given (such as in the `src/test/test_routerkeys.c:140`).Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17700Check full SHA digests in unit tests2020-06-13T14:51:34ZteorCheck full SHA digests in unit testsThe current test_crypto_sha unit test only checks the first 20 bytes of each digest. (The buffer sizes are somewhat out of whack, as we discovered in #17699.)
While it won't change the outcome of the tests, we really should check the en...The current test_crypto_sha unit test only checks the first 20 bytes of each digest. (The buffer sizes are somewhat out of whack, as we discovered in #17699.)
While it won't change the outcome of the tests, we really should check the entire length of each hash.
See my branch sha-unit-tests on https://github.com/teor2345/tor.gitTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17699SHA512 extension test fails with clang2020-06-13T14:51:34ZteorSHA512 extension test fails with clangThe SHA512 extension test fails with:
```
crypto/sha:
FAIL src/test/test_crypto.c:432: assert(d_out1 OP_EQ d_out2): DE642E63D5B73FC396C12BE38B2BD5D884257C32 vs 17807C728EE3BA35E7CF7AF823116D26E41E5D4D
[sha FAILED]
```
with x86_64 an...The SHA512 extension test fails with:
```
crypto/sha:
FAIL src/test/test_crypto.c:432: assert(d_out1 OP_EQ d_out2): DE642E63D5B73FC396C12BE38B2BD5D884257C32 vs 17807C728EE3BA35E7CF7AF823116D26E41E5D4D
[sha FAILED]
```
with x86_64 and i386 clang on OS X:
```
Apple LLVM version 7.0.0 (clang-700.1.76)
```
and x86_64 clang on Linux:
```
Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
```
But gcc works fine on Linux:
```
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17683Fail when TLS context fails to initialise2020-06-13T14:51:27ZteorFail when TLS context fails to initialise```
+ log_info(LD_GENERAL,"Rotating tls context.");
+ if (router_initialize_tls_context() < 0) {
+ log_warn(LD_BUG, "Error reinitializing TLS context");
+ /* XXX is it a bug here, that we just keep going? -RD */
}
```
I think...```
+ log_info(LD_GENERAL,"Rotating tls context.");
+ if (router_initialize_tls_context() < 0) {
+ log_warn(LD_BUG, "Error reinitializing TLS context");
+ /* XXX is it a bug here, that we just keep going? -RD */
}
```
I think it is - how about we assert() here, and see what happens?Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17675sandbox: ed25519 key creating failed2020-06-13T14:51:25Zcypherpunkssandbox: ed25519 key creating failedtor 0.2.7.5 (x86-64) failed to create ed25519 key and stop when sandbox/seccomp support is enabled
```
sandbox_intern_string(): Bug: No interned sandbox parameter found for /var/lib/tor/data/keys/ed25519_signing_secret_key_encrypted (on ...tor 0.2.7.5 (x86-64) failed to create ed25519 key and stop when sandbox/seccomp support is enabled
```
sandbox_intern_string(): Bug: No interned sandbox parameter found for /var/lib/tor/data/keys/ed25519_signing_secret_key_encrypted (on Tor 0.2.7.5 )
sandbox_intern_string(): Bug: No interned sandbox parameter found for /var/lib/tor/data/keys/ed25519_signing_public_key (on Tor 0.2.7.5 )
Could not open "/var/lib/tor/data/keys/ed25519_signing_public_key": Permission denied
```Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17659BUG : connection_ap_mark_as_pending_circuit()2020-06-13T14:51:18ZcypherpunksBUG : connection_ap_mark_as_pending_circuit()
```
Nov 23 [...] [warn] connection_ap_mark_as_pending_circuit(): Bug: What?? pending_entry_connections already contains 0x81b488f8! (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x8...
```
Nov 23 [...] [warn] connection_ap_mark_as_pending_circuit(): Bug: What?? pending_entry_connections already contains 0x81b488f8! (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81e10248 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81ab0338 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81a007d8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81b45800 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81e10170 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81b279e8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81d66cb8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81e11558 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x816458a8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x815c11a0 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81d4ddb8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81563fa0 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81b45f80 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x8129f718 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x814c7350 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x8158c3b0 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x819f4a48 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17576Add torrc option to disable default fallback directories2020-06-13T14:50:53ZteorAdd torrc option to disable default fallback directoriesThere's no easy way to disable the default fallback directories.
Tails depends on using the authorities for its consensuses as part of its time syncing proof:
https://tails.boum.org/contribute/design/Time_syncing/#index1h2
We should pr...There's no easy way to disable the default fallback directories.
Tails depends on using the authorities for its consensuses as part of its time syncing proof:
https://tails.boum.org/contribute/design/Time_syncing/#index1h2
We should provide an option to disable the default fallback directories entirely. (It should also conflict with any FallbackDir lines.)
Default fallbacks are also disabled when any other fallbacks are added, or when using non-default authorities.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17027policies_parse_exit_policy_internal should block all IPv4 and IPv6 local addr...2020-06-13T15:01:31Zteorpolicies_parse_exit_policy_internal should block all IPv4 and IPv6 local addressesCurrently it just handles a single IPv4 address, allowing IPv6 exits to be connected to on their IPv6 address, or multihomed IPv4 exits to be connected to on their other IPv4 addresses.
This is a potential security issue, as it allows c...Currently it just handles a single IPv4 address, allowing IPv6 exits to be connected to on their IPv6 address, or multihomed IPv4 exits to be connected to on their other IPv4 addresses.
This is a potential security issue, as it allows connections to local ports on an exit.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16651Tor fails to build on OpenBSD 5.8 due to libevent config options2020-06-16T01:26:59ZteorTor fails to build on OpenBSD 5.8 due to libevent config optionsCan we apply the patch in this thread?
http://lists.nycbug.org/pipermail/tor-bsd/2015-July/000328.htmlCan we apply the patch in this thread?
http://lists.nycbug.org/pipermail/tor-bsd/2015-July/000328.htmlTor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16056getinfo exit-policy/ipv6 does not show masks >= 322020-06-13T14:46:14ZTracgetinfo exit-policy/ipv6 does not show masks >= 32After enabling IPv6 on an exit node, I was discouraged by the lack of IPv6 policy displayed on Atlas, where there is a section in which IPv6 policy should be displayed, but the list is empty for my node, causing me to fear that my exit n...After enabling IPv6 on an exit node, I was discouraged by the lack of IPv6 policy displayed on Atlas, where there is a section in which IPv6 policy should be displayed, but the list is empty for my node, causing me to fear that my exit node could be used to relay spam on port 25 over IPv6, etc.
So I connected to the ControlPort and issued "getinfo exit-policy/ipv6" to confirm that there are sane defaults being applied to IPv6 policy. Indeed there are, and even private networks like "reject6 [fc00::]/7:*" are automatically configured, great!
However policies that I manually added, for example:
ExitPolicy reject6 [2610:148:1f10::]/48:*
...are not being output correctly by the getinfo command, for example:
reject6 [2610:148:1f10::]:*
...no mask!
Turns out that in function policy_write_item in src/or/policies.c the mask is being hidden if mask bits is >= 32, which makes sense for IPv4, but for IPv6 the test should be 128.
Attached is a trivial patch which I've tested and confirmed it corrects the getinfo policy output.
**Trac**:
**Username**: gturnerTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15775Add IPv4 Fallback Directory List to tor, active by default2020-06-13T14:51:37ZteorAdd IPv4 Fallback Directory List to tor, active by defaultweasel writes on tor-dev:
Tor has included a feature to fetch the initial consensus from nodes
other than the authorities for a while now. We just haven't shipped a
list of alternate locations for clients to go to yet.
Reasons why we ...weasel writes on tor-dev:
Tor has included a feature to fetch the initial consensus from nodes
other than the authorities for a while now. We just haven't shipped a
list of alternate locations for clients to go to yet.
Reasons why we might want to ship tor with a list of additional places
where clients can find the consensus is that it makes authority
reachability and BW less important.
At the last Tor dev meeting we came up with a list of arbitrary
requirements that nodes should meet to be included in this list.
We want them to have been around and using their current key, address,
and port for a while now (120 days), and have been running, a guard, and
a v2 directory mirror for most of that time.
I have written a script to come up with a list of notes that match our
criteria. It's currently at
https://www.palfrader.org/volatile/fallback-dir/get-fallback-dir-candidates
It currently produces
https://www.palfrader.org/volatile/2015-04-17-VjBkc8DWV8c/list
See https://lists.torproject.org/pipermail/tor-dev/2015-April/008674.html
This file current has 329 entries, and takes up approximately 32kB.
If we hard-coded it in the binary like the authorities, it would increase the binary size by approximately 2% on my platform.
Edit: nickm favours putting it in `torrc.defaults`
Edit 2: weasel notes `torrc.defaults` is for package maintainers. Putting it in a list of strings in the code. Much like the authorities.
Do we expect this in by 0.2.7?
Edit: Yes
Do we want to work on a signed file first (#15774)?
(A signed file needs a well-defined threat model and signature verification has to work without access to the authorities or fallback directories.)
Edit: No clear threat model, defer.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/12538Make all relays automatically be dir caches2020-06-13T18:13:30ZcypherpunksMake all relays automatically be dir cachesDuring the entry guard discussions, we have decided that it's a good idea to make all relays directory servers. We mainly needed the entry guards to be directories, but it seems easier and more elegant to just turn all relays to director...During the entry guard discussions, we have decided that it's a good idea to make all relays directory servers. We mainly needed the entry guards to be directories, but it seems easier and more elegant to just turn all relays to directory servers.
This is easier nowadays than in the past because `BEGIN_DIR` makes it so that directory servers don't need to have a separate DirPort open. (However, maybe relays get the `V2Dir` flag only if they have a DirPort open?)
Also, since all relays have all the directory documents anyway, it doesn't further bloat their disk to become directory servers.Tor: 0.2.8.x-final