The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:02:56Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12194rend_client_note_connection_attempt_ended() gets called redundantly2020-06-27T14:02:56ZAndrea Shepardrend_client_note_connection_attempt_ended() gets called redundantlyWhen hidden service connection attempts fail, rend_client_note_connection_attempt_ended() can get called once from connection_mark_unattached_ap() and then again from rend_client_desc_trynow() after it returns. See the log snippet in le...When hidden service connection attempts fail, rend_client_note_connection_attempt_ended() can get called once from connection_mark_unattached_ap() and then again from rend_client_desc_trynow() after it returns. See the log snippet in legacy/trac#10616 for an example.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11679Download status for consensus scheduled as generic2020-06-27T14:03:03ZcypherpunksDownload status for consensus scheduled as genericCurrently download status scheduled as generic (DL_SCHED_GENERIC = 0);
```
/** Download status for the current consensus networkstatus. */
static download_status_t consensus_dl_status[N_CONSENSUS_FLAVORS];
```
Before [implementing](https...Currently download status scheduled as generic (DL_SCHED_GENERIC = 0);
```
/** Download status for the current consensus networkstatus. */
static download_status_t consensus_dl_status[N_CONSENSUS_FLAVORS];
```
Before [implementing](https://gitweb.torproject.org/tor.git/commitdiff/851a980065e6b2df8d7cb35a22d0675b8918214b) of consensus for md it was DL_SCHED_CONSENSUS:
```
static download_status_t consensus_dl_status = { 0, 0, DL_SCHED_CONSENSUS };
```
That means unfriendly schedule for client with fragile network connection.
```
/** Schedule for when clients should download things in general. */
static const int client_dl_schedule[] = {
0, 0, 60, 60*5, 60*10, INT_MAX
};
```
vs.
```
/** Schedule for when clients should download consensuses. */
static const int client_consensus_dl_schedule[] = {
0, 0, 60, 60*5, 60*10, 60*30, 60*60, 60*60, 60*60, 60*60*3, 60*60*6, 60*60*12
};
```
Tor will reset download status by `networkstatus_reset_download_failures` once a hour so client will have a chance to retry, so no unresolved state actually.
Is it worth to initialize download status for consensus schedule? Or to rename schedule if planned to use it for certs only?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11543Clarify libseccomp "platform not supported" warning.2020-06-27T14:03:07ZNick MathewsonClarify libseccomp "platform not supported" warning.Here's an unhelpful thing: "Sandboxing is not implemented for your platform. The feature is currently disabled".
Probably better to distinguish whether sandboxing would work if we had a different kernel (old linux), or if we had libsecc...Here's an unhelpful thing: "Sandboxing is not implemented for your platform. The feature is currently disabled".
Probably better to distinguish whether sandboxing would work if we had a different kernel (old linux), or if we had libseccomp (new linux, built without libseccomp), or not at all (freebsd etc).Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11542Add a new logging domain for transport proxies2020-06-27T14:03:07ZwfnAdd a new logging domain for transport proxiesvelope suggested (and nickm is not against the idea of) adding a new logging domain for all the stuff to do with transport proxies / PTs. It would sure be nice to have transport proxy output like legacy/trac#9957 go to that specific doma...velope suggested (and nickm is not against the idea of) adding a new logging domain for all the stuff to do with transport proxies / PTs. It would sure be nice to have transport proxy output like legacy/trac#9957 go to that specific domain; it would make debugging PT things easier, I think.
Does this make sense, or is there simply no need for it, really?Tor: 0.4.0.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11452undef DEAD_CERT_LIFETIME too in trusted_dirs_remove_old_certs()2020-06-27T14:03:12ZRoger Dingledineundef DEAD_CERT_LIFETIME too in trusted_dirs_remove_old_certs()In trusted_dirs_remove_old_certs() we have
```
#define DEAD_CERT_LIFETIME (2*24*60*60)
#define OLD_CERT_LIFETIME (7*24*60*60)
[...use them...]
#undef OLD_CERT_LIFETIME
```
Shouldn't we undef both (or neither)?
Introduced in git commit ...In trusted_dirs_remove_old_certs() we have
```
#define DEAD_CERT_LIFETIME (2*24*60*60)
#define OLD_CERT_LIFETIME (7*24*60*60)
[...use them...]
#undef OLD_CERT_LIFETIME
```
Shouldn't we undef both (or neither)?
Introduced in git commit 8157b8b7.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11325RFE: Adhere to XDB base directory specification2020-06-27T14:03:15ZTracRFE: Adhere to XDB base directory specificationAs noted by a Fedora user [1], when running Tor as a regular user it creates "$HOME/.tor" instead of "$XDG_CACHE_HOME/.tor", which is advised by the XDG specification [2] for user-specific non-essential (cached) data. Would you consider ...As noted by a Fedora user [1], when running Tor as a regular user it creates "$HOME/.tor" instead of "$XDG_CACHE_HOME/.tor", which is advised by the XDG specification [2] for user-specific non-essential (cached) data. Would you consider adhering to this specification?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=968163
[2] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
**Trac**:
**Username**: jamielinuxTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11279Quiet some warns for protocol errors setting rendezvous points2020-06-27T14:03:17ZRoger DingledineQuiet some warns for protocol errors setting rendezvous pointsIn https://lists.torproject.org/pipermail/tor-relays/2014-March/004031.html we see a relay operator reporting lots of "Invalid length on ESTABLISH_RENDEZVOUS" errors.
The code in question is in rend_mid_establish_rendezvous():
```
if ...In https://lists.torproject.org/pipermail/tor-relays/2014-March/004031.html we see a relay operator reporting lots of "Invalid length on ESTABLISH_RENDEZVOUS" errors.
The code in question is in rend_mid_establish_rendezvous():
```
if (request_len != REND_COOKIE_LEN) {
log_warn(LD_PROTOCOL, "Invalid length on ESTABLISH_RENDEZVOUS.");
```
Seems to me that log_warn should be a log_protocol_warn, since there's nothing the relay operator should do about some client not obeying the protocol.
Are there other log_warns in this vicinity that we should change also? I looked around a bit and didn't see others.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11060socks-extensions.txt says username/password are ignored2021-07-22T16:26:02ZRoger Dingledinesocks-extensions.txt says username/password are ignoredIn torspec's socks-extensions.txt, we say
```
and as of Tor 0.2.3.2-alpha, the "USERNAME/PASSWORD" (SOCKS5)
authentication method [02] is supported too. Any credentials passed to
the latter are ignored.
```
But don't we use ...In torspec's socks-extensions.txt, we say
```
and as of Tor 0.2.3.2-alpha, the "USERNAME/PASSWORD" (SOCKS5)
authentication method [02] is supported too. Any credentials passed to
the latter are ignored.
```
But don't we use them for stream isolation now?
Also (hit-and-run two-bugs-in-one-ticket faux pas, sorry), the Tor man page says:
```
IsolateSOCKSAuth
Don’t share circuits with streams for which different SOCKS
authentication was provided. (On by default; you can disable it
with NoIsolateSOCKSAuth.)
```
which makes it sound like we look at SOCKS4 username too -- maybe we should change SOCKS to SOCKS5 in this man page stanza?Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10485Heartbeat doesn't include 'circuit stats since last time'2020-06-27T14:03:34ZcypherpunksHeartbeat doesn't include 'circuit stats since last time'This message is shown every 30 minutes, as per my HeartbeatPeriod.
```
[NOTICE] Heartbeat: Tor's uptime is xxx hours, with xxx circuits open. I've sent xxx and received xxx GB.
```
This message is not (and I don't know how to control ho...This message is shown every 30 minutes, as per my HeartbeatPeriod.
```
[NOTICE] Heartbeat: Tor's uptime is xxx hours, with xxx circuits open. I've sent xxx and received xxx GB.
```
This message is not (and I don't know how to control how frequently it is shown).
```
[NOTICE] Circuit handshake stats since last time: x/x TAP, x/x NTor.
```
How can I make the latter message as frequent/infrequent as I like? Can it be merged into the HeartbeatPeriod?Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10427Point operators of new relay to the lifecycle document2020-06-27T14:03:36ZLunarPoint operators of new relay to the lifecycle documentIt's quite often that operators of new relays wonder why they are not seeing all their bandwidth used immediately. I wonder if it would help to add a log message like: _You are running a new relay. Thanks for helping the Tor network! If ...It's quite often that operators of new relays wonder why they are not seeing all their bandwidth used immediately. I wonder if it would help to add a log message like: _You are running a new relay. Thanks for helping the Tor network! If you wish to know what will happen in the upcoming weeks regarding its usage, have a look at https://blog.torproject.org/blog/lifecycle-of-a-new-relay_Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10168Use monotonic clocks for time as appropriate2020-07-24T15:21:57ZNick MathewsonUse monotonic clocks for time as appropriateIn some places, like or or, we want to use wall-clock time. But in others, like timers and so forth, we should be using a monotonic timer so we just don't have to worry about time moving backwards.
Libevent 2.1 has a subsystem for this...In some places, like or or, we want to use wall-clock time. But in others, like timers and so forth, we should be using a monotonic timer so we just don't have to worry about time moving backwards.
Libevent 2.1 has a subsystem for this; we could just use it as needed. Or we could snarf the code and adapt it for our uses.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10060allow tor to start if torrc does not exist2020-06-27T14:03:41ZMark Smithallow tor to start if torrc does not existFor TBB 3.x, we now put all of the default settings in a torrc-defaults file. The torrc file within the Tor data directory will be reserved for the user's custom settings. The goal is to not overwrite the user's settings when they (or ...For TBB 3.x, we now put all of the default settings in a torrc-defaults file. The torrc file within the Tor data directory will be reserved for the user's custom settings. The goal is to not overwrite the user's settings when they (or our future automatic updater) overlays a new version of TBB on top of an existing installation, while still providing a way to include default settings.
But tor will not start up if the -f command line option points to a torrc file that does not exist. Here is a proposal: if a torrc-defaults file is provided, do not require that torrc exist. If this is too difficult to implement or distasteful in some way, we could probably instead modify the programs and scripts that start the TBB browser to create an empty torrc before starting anything. That would be a little more fragile though.Tor: 0.2.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9971for_discovery option in add_an_entry_guard() is confusingly named2021-09-16T14:35:28ZRoger Dingledinefor_discovery option in add_an_entry_guard() is confusingly namedIn legacy/trac#9946 I added a new argument "for_discovery" to add_an_entry_guard(). Nick prefers "provisional" or "probationary".
In parallel, I think we should probably rename the made_contact field in entry guard t, to be *why* we're ...In legacy/trac#9946 I added a new argument "for_discovery" to add_an_entry_guard(). Nick prefers "provisional" or "probationary".
In parallel, I think we should probably rename the made_contact field in entry guard t, to be *why* we're remembering that we've made contact, rather than simply that we have.
And lastly, we should do something about the godawful number of int arguments that add_an_entry_guard() now takes.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9926Stop being willing to build 2-hop circuits when there aren't 3 relays2020-06-27T14:03:46ZRoger DingledineStop being willing to build 2-hop circuits when there aren't 3 relaysnew_route_len() ends with
```
if (num_acceptable_routers < 2) {
log_info(LD_CIRC,
"Not enough acceptable routers (%d). Discarding this circuit.",
num_acceptable_routers);
return -1;
}
if (num_acce...new_route_len() ends with
```
if (num_acceptable_routers < 2) {
log_info(LD_CIRC,
"Not enough acceptable routers (%d). Discarding this circuit.",
num_acceptable_routers);
return -1;
}
if (num_acceptable_routers < routelen) {
log_info(LD_CIRC,"Not enough routers: cutting routelen from %d to %d.",
routelen, num_acceptable_routers);
routelen = num_acceptable_routers;
}
```
We should replace this with the simpler
```
if (num_acceptable_routers < 3) {
log_info(LD_CIRC,
"Not enough acceptable routers (%d). Discarding this circuit.",
num_acceptable_routers);
return -1;
}
```
to simplify things.
Note that the "oh hey let's just use two hops" case doesn't trigger in a real Tor network, because we won't be willing to make circuits if we don't have at least x% of the descriptors, so this code only comes into play when the consensus says there are 5 or something relays total.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9841Faster implementation for circuit_get_by_rend_token_and_purpose()2020-06-27T14:03:48ZNick MathewsonFaster implementation for circuit_get_by_rend_token_and_purpose()According to https://lists.torproject.org/pipermail/tor-relays/2013-September/002715.html , https://lists.torproject.org/pipermail/tor-relays/2013-September/002715.html can be 6% of a relay's runtime.
This is another function that does ...According to https://lists.torproject.org/pipermail/tor-relays/2013-September/002715.html , https://lists.torproject.org/pipermail/tor-relays/2013-September/002715.html can be 6% of a relay's runtime.
This is another function that does a linear search when a hashtable lookup would be more appropriate.
We'll need to be a little careful, since there's nothing preventing collisions here: An intro circuit and a rendezvous circuit can have the same "token" pretty easily.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9839man page doesn't document cached-certs file2020-06-27T14:03:49ZRoger Dingledineman page doesn't document cached-certs fileThe man page has a FILES section at the end that talks about things you'll find in your DataDirectory. It looks like we never documented the cached-certs file.
(Are we missing anything else?)The man page has a FILES section at the end that talks about things you'll find in your DataDirectory. It looks like we never documented the cached-certs file.
(Are we missing anything else?)Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9716Don't hardcode listen() backlog2020-06-27T14:03:53ZTracDon't hardcode listen() backlogWhile investigating Ticket legacy/trac#9708, I also found a lot of kernel messages along the lines of:
- sonewconn: pcb 0xfffffe005b7af000: Listen queue overflow: 193 already in queue awaiting acceptance
This despite the fact that "ke...While investigating Ticket legacy/trac#9708, I also found a lot of kernel messages along the lines of:
- sonewconn: pcb 0xfffffe005b7af000: Listen queue overflow: 193 already in queue awaiting acceptance
This despite the fact that "kern.somaxconn", which controls the length of the listen queue, was set to 4096.
Reading through the code, I found two instances of "listen(s,SOMAXCONN)" in src/or/connection.c. I think using SOMAXCONN as backlog is wrong. I think the correct backlog parameter is -1 -- which tells the kernel to accept as many connections as it's configured to accept, rather than a hardcoded constant (which happens to be the default the kernel will accept -- if not configured diferently).
SOMAXCONN is defined to 128 in <sys/socket.h> and is the default for kern.somaxconn. I'm not sure why it's exposed to userland. Possibly hysterical raisins?
Setting the backlog to -1 will allow tor to accept more connections faster if kern.somaxconn > SOMAXCONN (ie > 128).
This is true for FreeBSD (viz solisten_proto() in sys/kern/uipc_socket.) I've not tested Linux, but looking at the code (SYSCALL_DEFINE2(listen, int, fd, int, backlog) in net/socket.c) it should behave the same if I'm reading that cast correctly. On Linux, the moral equivalent of kern.somaxconn is configured with /proc/sys/net/core/somaxconn. It's also set to 128 by default. If raised to something huge, and listen() given a backlog of -1, it will also accept more connections.
**Trac**:
**Username**: philipTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9698Add source-ip + port to "New control connection opened" message2020-06-27T14:03:54ZTracAdd source-ip + port to "New control connection opened" messageI just noticed an unexpected entry "New control connection opened" in my logs; I'm wondering who opened this connection (I have bound the controlport to a non-loopback address).
Could this message be extended with the source ip and addr...I just noticed an unexpected entry "New control connection opened" in my logs; I'm wondering who opened this connection (I have bound the controlport to a non-loopback address).
Could this message be extended with the source ip and address of this connection?
**Trac**:
**Username**: Spider.007Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9666Autogen error for autoreconf could be more helpful2020-06-27T14:03:56ZDamian JohnsonAutogen error for autoreconf could be more helpfulHi, minor nitpick but when I pulled and re-ran tor's autogen it failed due to a new dependency...
```
atagar@odin:~/Desktop/tor/tor$ ./autogen.sh
Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 196.
Use o...Hi, minor nitpick but when I pulled and re-ran tor's autogen it failed due to a new dependency...
```
atagar@odin:~/Desktop/tor/tor$ ./autogen.sh
Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 196.
Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 196.
```
This is all well and good, but we usually provide a more helpful error message (preferably including the debian package the person needs). The following did the trick for me...
```
sudo apt-get install dh-autoreconf
```
Cheers! -DamianTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9665if no bridges are usable, tor should report a bootstrap error2020-06-27T14:03:56ZMark Smithif no bridges are usable, tor should report a bootstrap errorIn testing Tor Launcher changes while working on legacy/trac#9445, Kathy Brade and I found that when tor is only configured with bridges it cannot use due to a lack of PT plugins, the bootstrap process just stops making progress. It wou...In testing Tor Launcher changes while working on legacy/trac#9445, Kathy Brade and I found that when tor is only configured with bridges it cannot use due to a lack of PT plugins, the bootstrap process just stops making progress. It would be much better if an error was reported via the control port. Here is our torrc:
AvoidDiskWrites 1
bridge obfs2 91.143.91.97:34770
ControlPort 9151
CookieAuthentication 1
DataDirectory /Users/brade/dev/tor/tbb-for-tl-testing/TBB-3.0a2.app/Contents/Resources/Data/Tor
DirReqStatistics 0
GeoIPFile ../../Contents/Resources/Data/Tor/geoip
Log notice stdout
SocksListenAddress 127.0.0.1
SocksPort 9150
UseBridges 1
Here is the tor log:
Sep 04 11:37:33.689 [notice] Tor v0.2.4.14-alpha (git-f5729b8c1d45933f) running on Darwin with Libevent 2.0.21-stable and OpenSSL 1.0.1e.
Sep 04 11:37:33.689 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Sep 04 11:37:33.689 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Sep 04 11:37:33.710 [notice] Read configuration file "/Users/brade/dev/tor/tbb-for-tl-testing/TBB-3.0a2.app/Library/Vidalia/torrc".
Sep 04 11:37:33.714 [notice] Opening Socks listener on 127.0.0.1:9150
Sep 04 11:37:33.714 [notice] Opening Control listener on 127.0.0.1:9151
Sep 04 11:37:33.000 [notice] New control connection opened.
Sep 04 11:37:33.000 [notice] New control connection opened.
Sep 04 11:37:34.000 [notice] Bootstrapped 5%: Connecting to directory server.
Sep 04 11:37:34.000 [warn] We were supposed to connect to bridge '91.143.91.97:34770' using pluggable transport 'obfs2', but we can't find a pluggable transport proxy supporting 'obfs2'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.Tor: 0.2.5.x-final