The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-09T17:21:59Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10027Tor Windows service should be installed with the NetworkService account2021-07-09T17:21:59ZRoger DingledineTor Windows service should be installed with the NetworkService account```
<GITNE> nickm: I have checked running Tor under the NetworkService account.
Works fine. The problem I had the last time was a missing write permission on
the log file.
<GITNE> nickm: So it should probably be safe to change GENSRV_USE...```
<GITNE> nickm: I have checked running Tor under the NetworkService account.
Works fine. The problem I had the last time was a missing write permission on
the log file.
<GITNE> nickm: So it should probably be safe to change GENSRV_USERACCT to "NT
AUTHORITY\NetworkService"
> gitne: was that because the log file was trying to go somewhere it
shouldn't? or what
> gitne: also, does that change work for every windows, or only some of them?
<GITNE> armadev: those three predefinded accounts LocalSystem, LocalService,
and NetworkService are available since Windows 2000 so Tor should be safe
with that.
```https://gitlab.torproject.org/tpo/core/tor/-/issues/9998resolve "localhost", "host", "hostname" and "host.localdomain" to 127.0.0.12021-06-18T18:21:28Zproperresolve "localhost", "host", "hostname" and "host.localdomain" to 127.0.0.1I would be useful, if Tor would resolve:
* localhost
* host
* hostname
* host.localdomain
to 127.0.0.1.
For example, webhttrac wants to open http://host:8080/. Why not resolve host to 127.0.0.1? There are also other web interfaces (i2...I would be useful, if Tor would resolve:
* localhost
* host
* hostname
* host.localdomain
to 127.0.0.1.
For example, webhttrac wants to open http://host:8080/. Why not resolve host to 127.0.0.1? There are also other web interfaces (i2p, yacy, etc.) which may use http://localhost:someport/ etc.
At least Tails and Whonix [reached consensus](https://labs.riseup.net/code/issues/5655) using ["host" as hostname (and so forth)](https://mailman.boum.org/pipermail/tails-dev/2013-January/002486.html).
Unless you're seeing any security issues with that, of course.https://gitlab.torproject.org/tpo/core/tor/-/issues/9982Use a better password-based KDF for controller passwords, authority identity ...2021-06-18T18:21:28ZNick MathewsonUse a better password-based KDF for controller passwords, authority identity key encryption, and moreWith the ed25519 key transition, we'll want to start bringing offline identity keys to regular relay operators (and ideally hidden service operators too somehow, if we can figure out a non-stupid way for it to interact with legacy/trac#8...With the ed25519 key transition, we'll want to start bringing offline identity keys to regular relay operators (and ideally hidden service operators too somehow, if we can figure out a non-stupid way for it to interact with legacy/trac#8106).
As we do this, we'll want a better password-based KDF. Right now we have the very silly "NID_pbe_WithSHA1And3_Key_TripleDES_CBC" for protecting authority keys, and the very silly OpenPGP KDF for hashing controller passwords. Let's do something from the 21st century.
This is a bikeshed discussion. I nominate: "Derive keys with scrypt-jane, with salsa20/8 and SHA512."https://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/9860junk log messages every time SETCONF changes the set of ORPorts2021-07-09T17:21:59ZZack Weinbergjunk log messages every time SETCONF changes the set of ORPortsEvery time you use SETCONF (from a controller) to change the set of ORPorts, Tor emits log messages like this:
```
Sep 30 23:45:59.000 [notice] Opening OR listener on 0.0.0.0:9022
Sep 30 23:45:59.000 [notice] Tor 0.2.4.17-rc-dev (git-00...Every time you use SETCONF (from a controller) to change the set of ORPorts, Tor emits log messages like this:
```
Sep 30 23:45:59.000 [notice] Opening OR listener on 0.0.0.0:9022
Sep 30 23:45:59.000 [notice] Tor 0.2.4.17-rc-dev (git-00fb525+ace95c5+0e691f1) opening log file.
Sep 30 23:46:00.000 [notice] Your Tor server's identity key fingerprint is 'tbbscraperentry 73EFD4FE8D5D2466ECBDCFAC11894A72A322FD3C'
Sep 30 23:47:42.000 [notice] Opening OR listener on 0.0.0.0:9023
Sep 30 23:47:42.000 [notice] Tor 0.2.4.17-rc-dev (git-00fb525+ace95c5+0e691f1) opening log file.
Sep 30 23:47:42.000 [notice] Your Tor server's identity key fingerprint is 'tbbscraperentry 73EFD4FE8D5D2466ECBDCFAC11894A72A322FD3C'
Sep 30 23:50:40.000 [notice] Closing no-longer-configured OR listener on 0.0.0.0:9008
Sep 30 23:50:40.000 [notice] Tor 0.2.4.17-rc-dev (git-00fb525+ace95c5+0e691f1) opening log file.
Sep 30 23:50:40.000 [notice] Closing old OR listener on 0.0.0.0:9008
Sep 30 23:50:40.000 [notice] Your Tor server's identity key fingerprint is 'tbbscraperentry 73EFD4FE8D5D2466ECBDCFAC11894A72A322FD3C'
Sep 30 23:50:45.000 [notice] Closing no-longer-configured OR listener on 0.0.0.0:9012
Sep 30 23:50:45.000 [notice] Tor 0.2.4.17-rc-dev (git-00fb525+ace95c5+0e691f1) opening log file.
Sep 30 23:50:45.000 [notice] Closing old OR listener on 0.0.0.0:9012
Sep 30 23:50:45.000 [notice] Your Tor server's identity key fingerprint is 'tbbscraperentry 73EFD4FE8D5D2466ECBDCFAC11894A72A322FD3C'
```
The "opening log file" and "Your Tor server's identity key fingerprint is" lines should not be printed for every configuration change. And I'm not sure why it tells me it's closing a listener twice.https://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/9775Authorities should report when they don't vote Running but some addresses are...2022-06-22T15:18:20ZRoger DingledineAuthorities should report when they don't vote Running but some addresses are still reachableWe withhold the Running flag if *any* of the relay's addresses is unreachable.
I just spent a while debugging 'trouble', where his IPv4 address was set up correctly, and moria1 kept logging
```
Sep 19 02:22:45.986 [info] dirserv_orconn_...We withhold the Running flag if *any* of the relay's addresses is unreachable.
I just spent a while debugging 'trouble', where his IPv4 address was set up correctly, and moria1 kept logging
```
Sep 19 02:22:45.986 [info] dirserv_orconn_tls_done(): Found router
$67DE1CFEC8957833EAEE623F561BF57EB2D9CF2B~trouble at 5.9.125.198 to be
reachable at 5.9.125.198:443. Yay.
```
but his IPv6 address was port forwarding incorrectly.
The result was that 2 relays voted Running (I assume they're the ones who don't have IPv6 support), and the rest voted not Running.
One option is that we (e.g. consensus-health) should paw through the votes each hour to look for relays that have that same pattern of Running votes so we can contact them.
Another option would be for the authority votes to add an annotation somewhere, like in their votes, saying "partially reachable" or some such. That approach has the benefit that we could automatically have a record over time of how big an issue this is.
(If it's a big issue, it might argue for working harder to put partially reachable relays into the consensus somehow.)https://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-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9655Tor manual's config default options could be clearer2021-07-22T16:26:02ZTracTor manual's config default options could be clearerCurrently the default value for an option is suffixed on the description body, e.g.
**UseMicrodescriptors** **0**|**1**|**auto**:: Microdescriptors are a smaller version of the information that Tor needs in order to build its circuits....Currently the default value for an option is suffixed on the description body, e.g.
**UseMicrodescriptors** **0**|**1**|**auto**:: Microdescriptors are a smaller version of the information that Tor needs in order to build its circuits. Using microdescriptors makes Tor clients download less directory information, thus saving bandwidth. Directory caches need to fetch regular descriptors and microdescriptors, so this option doesn’t save any bandwidth for them. If this option is set to "auto" (recommended) then it is on for all clients that do not set FetchUselessDescriptors. (Default: auto)
If you read this example it reads as if FetchUselessDescriptiors is defaulted to auto (It's actually defaulted to zero) when it actually means to show that UseMicrodescriptors defaults to auto.
I think it would be clearer if the default was clearly seperated from the description body, maybe as a subheader for each option.
**Trac**:
**Username**: RyTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9580Tor should accept combined pluggable transport names2020-06-27T14:04:00ZGeorge KadianakisTor should accept combined pluggable transport namesThe plan for legacy/trac#7167 is to have flashproxy understand pluggable transporst like "websocket|obfs2", that is the combination of websocket and obfs2.
The good thing about our plan for legacy/trac#7167 is that it requires no real m...The plan for legacy/trac#7167 is to have flashproxy understand pluggable transporst like "websocket|obfs2", that is the combination of websocket and obfs2.
The good thing about our plan for legacy/trac#7167 is that it requires no real modifications to little-t-tor. However, in little-t-tor we do some checks on the transport names (in torrc, etc.) and ensure that they are C-identifiers -- but "websocket|obfs2" is not a C-identifier.
We should relax those checks so that they don't choke when we give them "websocket|obfs2".https://gitlab.torproject.org/tpo/core/tor/-/issues/9503Mechanism to provoke an unscheduled heartbeat.2020-06-27T14:04:02ZNick MathewsonMechanism to provoke an unscheduled heartbeat.On tor-talk, Lars Noodén suggests that we should have some way to get a heartbeat message when none is scheduled. Seems like a fine idea to me! All of the good signals seem to be taken though. (HUP, USR1, USR2). We could add it to H...On tor-talk, Lars Noodén suggests that we should have some way to get a heartbeat message when none is scheduled. Seems like a fine idea to me! All of the good signals seem to be taken though. (HUP, USR1, USR2). We could add it to HUP, but that wouldn't let you get *just* the heartbeat, given all the other stuff that HUP does.
We could add a controller-level signal, but that's not quite so convenient.
Once we're done bikeshedding the interface, the implementation should be simple.rl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/9494Remove gratuitous newlines from log messages?2022-06-17T17:34:26ZgrarpampRemove gratuitous newlines from log messages?These log entries (debug, domains) are either
- missing facility
t [notice] Tor v0.2.3.25 (git-r) running on o.
t [notice] Tor can't help you if you use it wrong! Learn how to
t [notice] Read configuration file "/.../torrc".
t [notice...These log entries (debug, domains) are either
- missing facility
t [notice] Tor v0.2.3.25 (git-r) running on o.
t [notice] Tor can't help you if you use it wrong! Learn how to
t [notice] Read configuration file "/.../torrc".
t [notice] Initialized libevent version 2.0.21-stable using method
t [notice] Opening Socks listener on 127.0.0.1:9051
t [notice] Opening Control listener on 127.0.0.1:9050
t [warn] Fixing permissions on directory /.../tor
- missing time, level and facility, and probably need one-lined
0 create
64 created
6494 relay
(644 relayed)
(6494 delivered)
50 destroyhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9390Warn if you're being a public relay but have too-low file descriptor limit2022-10-11T23:40:44ZRoger DingledineWarn if you're being a public relay but have too-low file descriptor limitInspired by discussion on legacy/trac#3030: if we're a public relay, we should check if ulimit -n is too low (under 8192 I'm thinking, based on debian's init script), and warn (and recommend using a package) if so.
This is to help peopl...Inspired by discussion on legacy/trac#3030: if we're a public relay, we should check if ulimit -n is too low (under 8192 I'm thinking, based on debian's init script), and warn (and recommend using a package) if so.
This is to help people who run Tor from tarball and don't realize all the fixes you have to do manually to do it right.https://gitlab.torproject.org/tpo/core/tor/-/issues/9271Portions of dir-spec unimplemented2020-06-27T14:04:09ZDamian JohnsonPortions of dir-spec unimplementedAs observed by Karsten [in ticket #3038](https://trac.torproject.org/projects/tor/ticket/3038#comment:4) the `/tor/micro/all[.z]` and `/tor/status-vote/(current|next)/consensus-index[.z]` dirport methods presently are not implemented.
I...As observed by Karsten [in ticket #3038](https://trac.torproject.org/projects/tor/ticket/3038#comment:4) the `/tor/micro/all[.z]` and `/tor/status-vote/(current|next)/consensus-index[.z]` dirport methods presently are not implemented.
I'm a little surprised that we don't have a tracking ticket for their implementation. Considering that Karsten discovered these were missing over a year ago I think it's safe to assume we should drop them [from the spec](https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l2503). No information is better than information for something that's unlikely to ever exist. :)
[ note: I only checked that '/tor/micro/all' is presently unimplemented, I didn't double check the other ]Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9265test_pt_parsing doesn't check managed_proxy_t contents2020-06-27T14:04:09ZNick Mathewsontest_pt_parsing doesn't check managed_proxy_t contentsHave a look at test_pt_parsing(). It looks to see whether parse_*() succeed or fail... but it doesn't actually check that they store the right results in managed_proxy_t! That's not what a unit test should do.Have a look at test_pt_parsing(). It looks to see whether parse_*() succeed or fail... but it doesn't actually check that they store the right results in managed_proxy_t! That's not what a unit test should do.Tor: 0.2.5.x-final