Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-03-22T13:02:42Zhttps://gitlab.torproject.org/legacy/trac/-/issues/8240Raise our guard rotation period, if appropriate2022-03-22T13:02:42ZRoger DingledineRaise our guard rotation period, if appropriateTariq's COGS paper from WPES 2012 shows that a significant component of guard churn is due to voluntary rotation, rather than actual network changes:
http://freehaven.net/anonbib/#wpes12-cogs
In short, if the target client makes sensiti...Tariq's COGS paper from WPES 2012 shows that a significant component of guard churn is due to voluntary rotation, rather than actual network changes:
http://freehaven.net/anonbib/#wpes12-cogs
In short, if the target client makes sensitive connections continuously every day for months, and you (the attacker) run some fast guards, the odds get pretty good that you'll become the client's guard at some point and get to do a correlation attack.
We could argue that the "continuously every day for months" assumption is unrealistic, so in practice we don't know how bad this issue really is. But for hidden services, it could well be a realistic assumption.
There are going to be (at least) two problems with raising the guard rotation period. The first is that we unbalance the network further wrt old guards vs new guards, and I'm not sure by how much, so I'm not sure how much our bwauth measurers will have to compensate. The second (related) problem is that we'll expand the period during which new guards don't get as much load as they will eventually get. This issue already results in confused relay operators trying to shed their Guard flag so they can resume having load.
In sum, if we raise the rotation period enough that it really results in load changes, then we could have unexpected side effects like having the bwauths raise the weights of new (and thus totally unloaded) guards to huge numbers, thus ensuring that anybody who rotates a guard will basically for sure get one of these new ones.
The real plan here needs a proposal, and should be for 0.2.5 or later. I wonder if we can raise it 'some but not too much' in the 0.2.4 timeframe though?Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20509Directory authorities should reject relays with #20499 bug2020-07-31T12:44:02ZRoger DingledineDirectory authorities should reject relays with #20499 bugOnce we resolve #20499, or more precisely, once we figure out which versions it affects, we should teach the directory authorities to withhold the Guard flag from relays that are running those versions.
Right now you can't bootstrap fro...Once we resolve #20499, or more precisely, once we figure out which versions it affects, we should teach the directory authorities to withhold the Guard flag from relays that are running those versions.
Right now you can't bootstrap from e.g. sofia, which is a huge guard running 0.2.9.3-alpha.
Then later -- or maybe this will turn out to be the easiest solution for everything -- we can teach the directory authorities to simply reject descriptors from relays running these buggy versions.
[I'm not sure which milestone to put this in, since it will need to get into a majority of directory authorities for it to matter. :/ ]Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13966Publish guidelines for reporting exploits2020-06-15T23:22:43ZTracPublish guidelines for reporting exploitsThere exists no easy to find documentation (on the wiki nor elsewhere) that advises how to report a suspected Tor (proxy, browser, bundle, transport...) exploit. And no search on keyservers shows up a 'security' key for a tor-sec@torproj...There exists no easy to find documentation (on the wiki nor elsewhere) that advises how to report a suspected Tor (proxy, browser, bundle, transport...) exploit. And no search on keyservers shows up a 'security' key for a tor-sec@torproject.org or similar account.
A blueprint for working this task could be: Just figure out how we've been handling exploit reporting in the past (tor-assistants@ maybe?) and make sure it's a consensus, and write it down in the wiki.
**Trac**:
**Username**: michaelTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18329Let bridges indicate when they don't want BridgeDB to distribute their address2020-06-13T18:28:59ZKarsten LoesingLet bridges indicate when they don't want BridgeDB to distribute their addressRight now, bridges can decide whether they want to be a public bridge that gets distributed via BridgeDB or a private bridge that only gets used by clients who learn its address via some other, private channel. The default is that a bri...Right now, bridges can decide whether they want to be a public bridge that gets distributed via BridgeDB or a private bridge that only gets used by clients who learn its address via some other, private channel. The default is that a bridge is a public bridges, unless it sets `PublishServerDescriptor 0` in its `torrc` file. This works fine with respect to BridgeDB not distributing private bridges. But a lesser known problem is that a bridge that doesn't publish its descriptor also does not contribute to bridge usage statistics on Metrics that are based on bridge extra-info descriptors.
The major use case that comes to mind is a bundled bridge whose address is shipped together with Tor Browser or another application. In the past we tried to remind operators of these bridges to also publish descriptors, so that their statistics are included on Metrics. But it turns out that some censors, who carefully scrape bridge addresses from BridgeDB, do not extract bridge addresses from the various bundles. Still, bundled bridges see a large number of bridge users and we should really include them in the statistics.
Another use case could be private bridges that somebody sets up for themselves and their friends. Maybe these operators would be fine contributing to the statistics if that doesn't automatically mean they need to share their bridge with other users.
I think this feature is relatively easy to build. We would need:
- a new descriptor line "bridgedb off", or something even more intuitive and extensible, that tells BridgeDB that this bridge's address should not be distributed,
- a new torrc option or extension of an existing option, maybe "PublishServerDescriptor bridge-auth" or, again, something more intuitive, to include the line above in the descriptor, and
- an extension of BridgeDB to ignore bridges with this line when parsing descriptors.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22207Add bridge authority fingerprint to sanitized bridge network statuses2020-06-13T17:51:45ZKarsten LoesingAdd bridge authority fingerprint to sanitized bridge network statusesWhen I looked through existing code that uses methods from `DescriptorFile` other than `DescriptorFile#getDescriptors()` for #22141, I spotted [this code in metrics-web](https://gitweb.torproject.org/metrics-web.git/tree/modules/legacy/s...When I looked through existing code that uses methods from `DescriptorFile` other than `DescriptorFile#getDescriptors()` for #22141, I spotted [this code in metrics-web](https://gitweb.torproject.org/metrics-web.git/tree/modules/legacy/src/main/java/org/torproject/ernie/cron/network/ConsensusStatsFileHandler.java#n205):
```
if (descriptorFile.getFileName().contains(
"4A0CCD2DDC7995083D73F5D667100C8A5831F16D")) {
authority = "Tonga";
} else if (descriptorFile.getFileName().contains(
"1D8F3A91C37C5D1C4C19B1AD1D0CFBE8BF72D8E1")) {
authority = "Bifroest";
}
```
Not beautiful, I know, but that's not the point. The point is that we need to parse the bridge authority fingerprint from the file name, because it's not contained in the descriptor itself. That seems bad, and relatively easy to fix.
Right now, the header of a sanitized bridge network status looks like this:
```
@type bridge-network-status 1.1
published 2017-05-09 07:57:32
flag-thresholds stable-uptime=1075980 stable-mtbf=2384868 fast-speed=21000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=318000 guard-bw-exc-exits=318000 enough-mtbf=1 ignoring-advertised-bws=0
```
We could easily include a "fingerprint" line there, like this:
```
@type bridge-network-status 1.2
published 2017-05-09 07:57:32
flag-thresholds stable-uptime=1075980 stable-mtbf=2384868 fast-speed=21000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=318000 guard-bw-exc-exits=318000 enough-mtbf=1 ignoring-advertised-bws=0
fingerprint 1D8F3A91C37C5D1C4C19B1AD1D0CFBE8BF72D8E1
```
Ideally, we'd modify the bridge authority code to include this line, too, and then go through archived bridge network statuses and retroactively put it in.
This is somewhat related to #12951 when we added a `"published"` line to bridge network statuses in a similar way.
I'm copying isis to hear what they think about putting in a `"fingerprint"` line.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1922torrc.d-style configuration directories2020-06-13T16:52:58ZTractorrc.d-style configuration directoriestorrc.d-style configuration directories
**Trac**:
**Username**: aa138346torrc.d-style configuration directories
**Trac**:
**Username**: aa138346Tor: 0.3.1.x-finalJigsaw52Jigsaw52https://gitlab.torproject.org/legacy/trac/-/issues/24503Rust build fails2020-06-13T16:07:55ZTracRust build failsWhen compiling it with rust support it will fail with:
checking rust crate dependencies... configure: error: Rust dependency directory ./src/ext/rust/ does not exist. Specify a dependency directory using the RUST_DEPENDENCIES variable or...When compiling it with rust support it will fail with:
checking rust crate dependencies... configure: error: Rust dependency directory ./src/ext/rust/ does not exist. Specify a dependency directory using the RUST_DEPENDENCIES variable or allow cargo to fetch crates using --enable-cargo-online-mode.
**Trac**:
**Username**: tortuxTor: 0.3.1.x-finalOndrej MikleOndrej Miklehttps://gitlab.torproject.org/legacy/trac/-/issues/22285Announce new list of fallback directory mirrors in 0.3.12020-06-13T16:06:04ZteorAnnounce new list of fallback directory mirrors in 0.3.1The rebuilt list of fallbacks in #21564 was merged into 0.3.1 (and backported to 0.2.8 onwards).
I should send an email to tor-relays about this very soon.
I used to BCC all the operators, but I'm not sure if that's worth the effort an...The rebuilt list of fallbacks in #21564 was merged into 0.3.1 (and backported to 0.2.8 onwards).
I should send an email to tor-relays about this very soon.
I used to BCC all the operators, but I'm not sure if that's worth the effort any more. Now we have a 90 day stability requirement, I think I just want to do a quick rebuild every release.
To avoid a mass mail-out of operators before the next rebuild, I'll add a note to the announcement saying: "want to be on this list next time? email me with your relay fingerprint and I will put your relay on the list of potential fallbacks".Tor: 0.3.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/21564Regenerate fallback list for 0.3.1 or 0.3.22020-06-13T16:06:01ZteorRegenerate fallback list for 0.3.1 or 0.3.2This involves:
* checking for new relays
* contacting potential fallback operators
* rebuilding the list
* contacting all fallback operators
See detailed instructions here:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallb...This involves:
* checking for new relays
* contacting potential fallback operators
* rebuilding the list
* contacting all fallback operators
See detailed instructions here:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrorsTor: 0.3.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/21121Update fallback whitelist2020-06-13T16:06:00ZteorUpdate fallback whitelistRelay operators have emailed me with updates.
I'm tracking them in my github branch fallbacks-201701.Relay operators have emailed me with updates.
I'm tracking them in my github branch fallbacks-201701.Tor: 0.3.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/20913Increase fallback stability, flag percentage, and bandwidth2020-06-13T16:05:54ZteorIncrease fallback stability, flag percentage, and bandwidthIn #18828, I had to decrease the fallback criteria to get ~160 fallbacks.
It would be great to increase these to:
* Stability: 3 months+ (from 7 days)
* Flags: 95%+ (from 90%)
* Bandwidth: 2MBytes/s+ (from 1MByte/s)In #18828, I had to decrease the fallback criteria to get ~160 fallbacks.
It would be great to increase these to:
* Stability: 3 months+ (from 7 days)
* Flags: 95%+ (from 90%)
* Bandwidth: 2MBytes/s+ (from 1MByte/s)Tor: 0.3.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/22368double-free of MyFamily lines2020-06-13T16:03:44ZRoger Dingledinedouble-free of MyFamily linesRun a relay under valgrind with "myfamily moria1", and then ctrl-C it once it bootstraps. Upon exit, you'll get:
```
==17604== Invalid free() / delete / delete[] / realloc()
==17604== at 0x4C29E90: free (in /usr/lib/valgrind/vgpreload...Run a relay under valgrind with "myfamily moria1", and then ctrl-C it once it bootstraps. Upon exit, you'll get:
```
==17604== Invalid free() / delete / delete[] / realloc()
==17604== at 0x4C29E90: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17604== by 0x277E75: config_free_lines (confline.c:323)
==17604== by 0x1F56F2: or_options_free (config.c:898)
==17604== by 0x1F6583: config_free_all (config.c:907)
==17604== by 0x157CCC: tor_free_all (main.c:3238)
==17604== by 0x157DB0: tor_cleanup (main.c:3310)
==17604== by 0x2614E5: hibernate_begin (hibernate.c:818)
==17604== by 0x1584E9: process_signal (main.c:2686)
==17604== by 0x1584E9: signal_callback (main.c:2663)
==17604== by 0x5361A14: event_base_loop (in /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5.1.9)
==17604== by 0x156E23: run_main_loop_once (main.c:2594)
==17604== by 0x156E23: run_main_loop_until_done (main.c:2648)
==17604== by 0x156E23: do_main_loop (main.c:2561)
==17604== by 0x15A664: tor_main (main.c:3745)
==17604== by 0x152628: main (tor_main.c:34)
==17604== Address 0x668f9a0 is 0 bytes inside an unallocated block of size 16 in arena "client"
```
User DeS originally found this bug on #22255, with this stack trace:
```
==33656== Invalid free() / delete / delete[] / realloc()
==33656== at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==33656== by 0x1A4378: routerinfo_free (routerlist.c:3172)
==33656== by 0x199BF6: router_rebuild_descriptor (router.c:2449)
==33656== by 0x199CD2: router_get_my_routerinfo (router.c:2013)
==33656== by 0x1D183E: channel_tls_process_netinfo_cell (channeltls.c:1679)
==33656== by 0x1D183E: channel_tls_handle_cell (channeltls.c:1133)
==33656== by 0x2137A0: connection_or_process_cells_from_inbuf (connection_or.c:2085)
==33656== by 0x20ABE4: connection_handle_read_impl (connection.c:3451)
==33656== by 0x153CB0: conn_read_callback (main.c:736)
==33656== by 0x5363F23: event_base_loop (in /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5.1.9)
==33656== by 0x154DDC: run_main_loop_once (main.c:2594)
==33656== by 0x154DDC: run_main_loop_until_done (main.c:2648)
==33656== by 0x154DDC: do_main_loop (main.c:2561)
==33656== by 0x158594: tor_main (main.c:3745)
==33656== by 0x1507C8: main (tor_main.c:34)
==33656== Address 0x6453720 is 0 bytes inside a block of size 42 free'd
==33656== at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==33656== by 0x1995BC: router_build_fresh_descriptor (router.c:2327)
==33656== by 0x199BE2: router_rebuild_descriptor (router.c:2445)
==33656== by 0x199CD2: router_get_my_routerinfo (router.c:2013)
==33656== by 0x1D183E: channel_tls_process_netinfo_cell (channeltls.c:1679)
==33656== by 0x1D183E: channel_tls_handle_cell (channeltls.c:1133)
==33656== by 0x2137A0: connection_or_process_cells_from_inbuf (connection_or.c:2085)
==33656== by 0x20ABE4: connection_handle_read_impl (connection.c:3451)
==33656== by 0x153CB0: conn_read_callback (main.c:736)
==33656== by 0x5363F23: event_base_loop (in /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5.1.9)
==33656== by 0x154DDC: run_main_loop_once (main.c:2594)
==33656== by 0x154DDC: run_main_loop_until_done (main.c:2648)
==33656== by 0x154DDC: do_main_loop (main.c:2561)
==33656== by 0x158594: tor_main (main.c:3745)
==33656== by 0x1507C8: main (tor_main.c:34)
==33656==
==33656== Invalid free() / delete / delete[] / realloc()
==33656== at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==33656== by 0x1995BC: router_build_fresh_descriptor (router.c:2327)
==33656== by 0x199BE2: router_rebuild_descriptor (router.c:2445)
==33656== by 0x199CD2: router_get_my_routerinfo (router.c:2013)
==33656== by 0x19A358: router_my_exit_policy_is_reject_star (router.c:1963)
==33656== by 0x247025: dns_resolve_impl.constprop.9 (dns.c:720)
==33656== by 0x249A68: dns_resolve (dns.c:614)
==33656== by 0x2101BA: connection_exit_begin_conn (connection_edge.c:3292)
==33656== by 0x17B4A0: connection_edge_process_relay_cell (relay.c:1648)
==33656== by 0x17CCD8: circuit_receive_relay_cell (relay.c:328)
==33656== by 0x1EF725: command_process_relay_cell (command.c:542)
==33656== by 0x1EF725: command_process_cell (command.c:196)
==33656== by 0x1D19A2: channel_tls_handle_cell (channeltls.c:1152)
==33656== Address 0x6452e10 is 80 bytes inside a block of size 128 alloc'd
==33656== at 0x4C2CE8E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==33656== by 0x5858E68: CRYPTO_realloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==33656== by 0x58DF3B9: sk_dup (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==33656== by 0x55D900D: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==33656== by 0x55D13B3: SSL_set_cipher_list (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==33656== by 0x29407E: tor_tls_session_secret_cb (tortls.c:1599)
==33656== by 0x55AD7D5: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==33656== by 0x55B1DAC: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==33656== by 0x55BF863: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==33656== by 0x2973A2: tor_tls_handshake (tortls.c:1901)
==33656== by 0x216D7F: connection_tls_continue_handshake (connection_or.c:1420)
==33656== by 0x217137: connection_tls_start_handshake (connection_or.c:1372)
==33656==
==33656== Invalid read of size 8
==33656== at 0x58E41E1: EVP_MD_CTX_cleanup (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==33656== by 0x58E463D: EVP_MD_CTX_destroy (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==33656== by 0x55BA0D0: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==33656== by 0x55B789B: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==33656== by 0x55D44DA: SSL_free (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==33656== by 0x295BD5: tor_tls_free (tortls.c:1794)
==33656== by 0x204EA7: connection_free_ (connection.c:572)
==33656== by 0x1536BD: conn_close_if_marked (main.c:908)
==33656== by 0x1536BD: close_closeable_connections (main.c:700)
==33656== by 0x153FE0: run_scheduled_events (main.c:1474)
==33656== by 0x153FE0: second_elapsed_callback (main.c:2175)
==33656== by 0x5363F23: event_base_loop (in /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5.1.9)
==33656== by 0x154DDC: run_main_loop_once (main.c:2594)
==33656== by 0x154DDC: run_main_loop_until_done (main.c:2648)
==33656== by 0x154DDC: do_main_loop (main.c:2561)
==33656== by 0x158594: tor_main (main.c:3745)
==33656== Address 0x699aeaf2 is not stack'd, malloc'd or (recently) free'd
```
Once we've resolved this ticket, we should take a closer look at that last "Invalid read of size 8" stanza, and open a new ticket for it if needed.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17592Clean up connection timeout logic2020-06-13T16:03:44ZMike PerryClean up connection timeout logicIn #6799, it was decided to keep TLS connections open for a random amount of time after they are idle, to defend against an attack that used internal Tor network connectivity information to determine Guard nodes (Slides: https://www.cryp...In #6799, it was decided to keep TLS connections open for a random amount of time after they are idle, to defend against an attack that used internal Tor network connectivity information to determine Guard nodes (Slides: https://www.cryptolux.org/images/8/85/ESORICS-2012-Presentation-2.pdf Paper: https://eprint.iacr.org/2012/432.pdf).
Unfortunately, this logic (in connection_or_set_canonical()) is kind of a mess. Relays and clients are treated the same, and client connections are also kept alive for an additional hour by predictive circuit building even when otherwise idle, where as relays are not.
If we treat relays and clients separately for this timeout, we could reduce total client keep-alive time significantly (down to 30 minutes or so), and significantly increase relay connection lifetime. This should result in reduced total connection counts on relays, with better defenses against Torscan.
This is also needed in order to put reasonable bounds on padding overhead in #16861 for mobile clients. Furthermore, aside from the wieners running middle relays behind junky home routers who will whine about connection overflow, having a more well-connected Tor network is a good idea for many reasons (not just Torscan).Tor: 0.3.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/17604Try to use only one canonical connection2020-06-13T15:53:07ZMike PerryTry to use only one canonical connectionFor #16861, I would like to experiment with padding between relays, as well as generally keep relay-to-relay orconns open much longer. This will be beneficial against attacks like Torscan (https://eprint.iacr.org/2012/432.pdf), as well a...For #16861, I would like to experiment with padding between relays, as well as generally keep relay-to-relay orconns open much longer. This will be beneficial against attacks like Torscan (https://eprint.iacr.org/2012/432.pdf), as well as related netflow-based attacks that attempt to determine the guard node of a connection by using netflow data to accomplish the same thing as the Torscan attack.
Unfortunately, the logic for preferring orconns (is_canonical and channel_is_better()) is a mind-bender, but it appears to be the case that we may have situations where multiple orconns can be opened between relays where each side disagrees over which connection is canonical. This can happen because the source port won't match the orport in the descriptor of the remote relay for incoming connections. It will also be the case for nodes that make outgoing connections from different IP address than those in their descriptor.
I asked on #tor-dev, and two relay operators reported cases of such multiple connections to relays.
I think the following changes will improve the situation:
1. Mark all authenticated connections as canonical (everything with link proto v3 and higher will authenticate, yes?)
2. Alter channel_is_better() to prefer older orconns in the case of multiple canonical connections, and use the orconn with more circuits on it in case of age ties.
I think age is more important than number of circuits because we want to avoid giving an attacker the ability to switch an orconn between relays by creating a new one and opening a bunch of circuits on it. channel_is_better() is doing the opposite of this behavior right now, on both fronts.Tor: 0.3.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/21788Very small memory leak with --verify-config2020-06-13T15:45:05ZJigsaw52Very small memory leak with --verify-configWhen tor is run with the flag --verify-config, there is a memory leak of 45 bytes. Although the leak is insignificant, not leaking any memory helps testing the configuration related code against memory leaks.
This leak is due to clean_u...When tor is run with the flag --verify-config, there is a memory leak of 45 bytes. Although the leak is insignificant, not leaking any memory helps testing the configuration related code against memory leaks.
This leak is due to clean_up_backtrace_handler not being called during tor shutdown process. I believe the fix is calling it inside tor_free_all. I will post a link to a branch with my proposed fix.
Valgrind log:
```
user@lubuntu:~/Desktop/tor$ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all /usr/local/bin/tor --verify-config
==19135== Memcheck, a memory error detector
==19135== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==19135== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==19135== Command: /usr/local/bin/tor --verify-config
==19135==
Mar 20 00:59:33.916 [notice] Tor 0.3.1.0-alpha-dev (git-411736a13250586c) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g and Zlib 1.2.8.
Mar 20 00:59:34.005 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 20 00:59:34.008 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Mar 20 00:59:34.036 [notice] Read configuration file "/usr/local/etc/tor/torrc".
Configuration was valid
==19135==
==19135== HEAP SUMMARY:
==19135== in use at exit: 45 bytes in 1 blocks
==19135== total heap usage: 8,709 allocs, 8,708 frees, 460,735 bytes allocated
==19135==
==19135== 45 bytes in 1 blocks are still reachable in loss record 1 of 1
==19135== at 0x4C2CB3F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19135== by 0x61CBB4F: __vasprintf_chk (vasprintf_chk.c:80)
==19135== by 0x2669F3: vasprintf (stdio2.h:210)
==19135== by 0x2669F3: tor_vasprintf (compat.c:539)
==19135== by 0x2669F3: tor_asprintf (compat.c:516)
==19135== by 0x2657E1: configure_backtrace_handler (backtrace.c:232)
==19135== by 0x1556AF: tor_main (main.c:3609)
==19135== by 0x14F238: main (tor_main.c:34)
==19135==
==19135== LEAK SUMMARY:
==19135== definitely lost: 0 bytes in 0 blocks
==19135== indirectly lost: 0 bytes in 0 blocks
==19135== possibly lost: 0 bytes in 0 blocks
==19135== still reachable: 45 bytes in 1 blocks
==19135== suppressed: 0 bytes in 0 blocks
==19135==
==19135== For counts of detected and suppressed errors, rerun with: -v
==19135== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
```Tor: 0.3.1.x-finalJigsaw52Jigsaw52https://gitlab.torproject.org/legacy/trac/-/issues/16858Non-ascii country code in extrainfo descriptor2020-06-13T15:30:35ZDamian JohnsonNon-ascii country code in extrainfo descriptorHi, starting recently (fifteen hours ago) torzurwelt started publishing extrainfo descriptors with a non-ascii country code in its dirreq-v3-reqs lines...
```
extra-info torzurwelt EA63329F9E4DC3C7366BC9244AA92B61F9BE77B1
published 2015...Hi, starting recently (fifteen hours ago) torzurwelt started publishing extrainfo descriptors with a non-ascii country code in its dirreq-v3-reqs lines...
```
extra-info torzurwelt EA63329F9E4DC3C7366BC9244AA92B61F9BE77B1
published 2015-08-19 05:50:58
...
geoip-db-digest C1EB5237F2FBAF63381D8551157F13D12EFCCA25
geoip6-db-digest 1F99B6B0EC78E9DB34D61AE7E0FC261D558E8E5D
dirreq-stats-end 2015-08-18 18:17:14 (86400 s)
dirreq-v3-ips de=16,it=16,us=16,??=8,ar=8,at=8,au=8,be=8,bg=8,br=8,ch=8,cz=8,es=8,fr=8,gb=8,ie=8,in=8,ir=8,jp=8,lt=8,ma=8,nl=8,pe=8,pl=8,pt=8,re=8,ro=8,ru=8,sa=8,tn=8,tt=8,tw=8,uy=8,ve=8
dirreq-v3-reqs ñÏ=32,de=16,it=16,us=16,??=8,ar=8,at=8,au=8,be=8,bg=8,br=8,ch=8,cz=8,es=8,fr=8,gb=8,ie=8,in=8,ir=8,jp=8,lt=8,ma=8,nl=8,pe=8,pl=8,pt=8,re=8,ro=8,ru=8,sa=8,tn=8,tt=8,tw=8,uy=8,ve=8
dirreq-v3-resp ok=104,not-enough-sigs=0,unavailable=0,not-found=0,not-modified=24,busy=8
dirreq-v3-direct-dl complete=0,timeout=0,running=0
```
Not sure how these are slipping in but pretty sure the authorities should reject these as malformed.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25452FAIL ../src/test/test_hs_service.c:420: assert(ip->time_to_expire OP_GE now +...2020-06-13T15:22:51ZGeorge KadianakisFAIL ../src/test/test_hs_service.c:420: assert(ip->time_to_expire OP_GE now + INTRO_POINT_LIFETIME_MIN_SECONDS + 5)weasel reported the `test_service_intro_point()` test failing here:
```
ip = helper_create_service_ip();
tt_assert(ip);
/* Make sure the authentication keypair is not zeroes. */
tt_int_op(tor_mem_is_zero((const char *) &i...weasel reported the `test_service_intro_point()` test failing here:
```
ip = helper_create_service_ip();
tt_assert(ip);
/* Make sure the authentication keypair is not zeroes. */
tt_int_op(tor_mem_is_zero((const char *) &ip->auth_key_kp,
sizeof(ed25519_keypair_t)), OP_EQ, 0);
/* The introduce2_max MUST be in that range. */
tt_u64_op(ip->introduce2_max, OP_GE,
INTRO_POINT_MIN_LIFETIME_INTRODUCTIONS);
tt_u64_op(ip->introduce2_max, OP_LE,
INTRO_POINT_MAX_LIFETIME_INTRODUCTIONS);
/* Time to expire MUST also be in that range. We add 5 seconds because
* there could be a gap between setting now and the time taken in
* service_intro_point_new. On ARM, it can be surprisingly slow... */
tt_u64_op(ip->time_to_expire, OP_GE,
now + INTRO_POINT_LIFETIME_MIN_SECONDS + 5);
tt_u64_op(ip->time_to_expire, OP_LE,
now + INTRO_POINT_LIFETIME_MAX_SECONDS + 5);
```Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18859A new SOCKS connection should use a pre-built circuit for its first stream2020-06-13T15:20:49ZArthur EdelsteinA new SOCKS connection should use a pre-built circuit for its first streamSince #3455, we use SOCKS auth isolation in Tor Browser to separate URL bar domains to different tor circuits. When the user browses to a new URL bar domain, a new SOCKS connection is opened with a SOCKS username/password unique to the s...Since #3455, we use SOCKS auth isolation in Tor Browser to separate URL bar domains to different tor circuits. When the user browses to a new URL bar domain, a new SOCKS connection is opened with a SOCKS username/password unique to the site's domain.
By telneting to the tor control port, I observed that immediately after I entered a new URL bar domain in a Tor Browser tab, a new circuit was built and assigned the SOCK_USERNAME and SOCKS_PASSWORD for that URL bar domain.
It seems there would be better performance if we could use an existing, pre-built (yet-unused) circuit when a new SOCKS connection opens, and assign the SOCKS_USERNAME and SOCKS_PASSWORD to the pre-built circuit. That way the user wouldn't have to wait for a circuit to be established after requesting a new website.
I don't know yet whether this is something that can be adjusted by config settings or if we would need to patch tor somehow.Tor: 0.3.1.x-finalArthur EdelsteinArthur Edelsteinhttps://gitlab.torproject.org/legacy/trac/-/issues/22060Remove deprecated options from 0.2.9.2-alpha2020-06-13T15:20:44ZDavid Gouletdgoulet@torproject.orgRemove deprecated options from 0.2.9.2-alphaWe have a set of deprecated options in `src/or/config.c` in the `option_deprecation_notes_` array.
We should `OBSOLETE()` them and remove the associated code. Let's do one option removal per commit.
#21522 and #21031 asks to not get ri...We have a set of deprecated options in `src/or/config.c` in the `option_deprecation_notes_` array.
We should `OBSOLETE()` them and remove the associated code. Let's do one option removal per commit.
#21522 and #21031 asks to not get rid of `ClientDNSRejectInternalAddresses` so let's not for this ticket.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/23533Repair bug in geoip/rephist reporting from relays that only download microdes...2020-06-13T15:20:42ZNick MathewsonRepair bug in geoip/rephist reporting from relays that only download microdescriptors.Tor: 0.3.1.x-finalNick MathewsonNick Mathewson