The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-09-13T17:23:57Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20469Expose predicted-ports state over the control port2023-09-13T17:23:57ZRoger DingledineExpose predicted-ports state over the control portWhile debugging legacy/trac#19969 I wanted to ask my Tor whether it had any predicted ports in its internal state. But I think there is no way to ask it? I would like a 'getinfo predicted-ports' or the like.While debugging legacy/trac#19969 I wanted to ask my Tor whether it had any predicted ports in its internal state. But I think there is no way to ask it? I would like a 'getinfo predicted-ports' or the like.https://gitlab.torproject.org/tpo/core/tor/-/issues/20435Update tor man page with AuthDirGuardBWGuarantee of 2 MBytes2021-07-22T16:23:16ZteorUpdate tor man page with AuthDirGuardBWGuarantee of 2 MBytesBugfix on ticket legacy/trac#12690, commit a57c07b in tor-0.2.5.6-alpha.
~~There is no tor-0.2.5.6-alpha in the versions list, see legacy/trac#20434.~~Bugfix on ticket legacy/trac#12690, commit a57c07b in tor-0.2.5.6-alpha.
~~There is no tor-0.2.5.6-alpha in the versions list, see legacy/trac#20434.~~Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20353evutil_ersatz_socketpair: use AF_INET6 if AF_INET bind fails2020-06-27T13:58:03ZNick Mathewsonevutil_ersatz_socketpair: use AF_INET6 if AF_INET bind failsApparently there are systems where you can bind to ::1, but you can't bind to 127.0.0.1. On these systems, evutil_ersatz_socketpair doesn't work right -- it only falls back to IPv6 when it fails to create an AF_INET socket.
I'm calling...Apparently there are systems where you can bind to ::1, but you can't bind to 127.0.0.1. On these systems, evutil_ersatz_socketpair doesn't work right -- it only falls back to IPv6 when it fails to create an AF_INET socket.
I'm calling this a very low priority bug, since evutil_ersatz_socketpair is only used on Windows, and (as far as I know) binding 127.0.0.1 should always work on Windows.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20337Support abstract namespace AF_UNIX sockets.2020-07-27T23:07:39ZYawning AngelSupport abstract namespace AF_UNIX sockets.Linux has a notion of `abstract` AF_UNIX sockets. This should be supported both for the control and socks port, as they are convenient and useful, as long as they are used correctly.
Benefits:
* Easier to bundle. `sun_path` length li...Linux has a notion of `abstract` AF_UNIX sockets. This should be supported both for the control and socks port, as they are convenient and useful, as long as they are used correctly.
Benefits:
* Easier to bundle. `sun_path` length limitations are dumb, being able to use an abstract identifier is simpler.
* No need to mess around with creating a directory, arguing over what permissions the directory and the socket file has.
* The socket goes away when the last reference to the socekt is closed, removing the need to unlink it.
Downsides:
* There is no access control, at all. Primarily relevant for the ControlPort, but that has separate mechanisms for restricting access.
* Not wildly useful for sandboxes, since most sandboxing approaches will unshare/create a new IPC namespace.
* Non-portable.
(0.2.0.3-alpha was the first time we supported AF_UNIX at all)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20270"Descriptor is missing an ntor curve25519 onion key" message too noisy?2020-06-27T13:58:06ZRoger Dingledine"Descriptor is missing an ntor curve25519 onion key" message too noisy?On moria1, I have a lot of these:
```
Oct 01 18:01:05.421 [notice] Descriptor from router $E0671CF9CB593F27CD389CD4DD819BF9448EA834~ordb1 at 37.59.47.27 is missing an ntor curve25519 onion key.
Oct 01 18:01:20.530 [notice] Descriptor fro...On moria1, I have a lot of these:
```
Oct 01 18:01:05.421 [notice] Descriptor from router $E0671CF9CB593F27CD389CD4DD819BF9448EA834~ordb1 at 37.59.47.27 is missing an ntor curve25519 onion key.
Oct 01 18:01:20.530 [notice] Descriptor from router $179B10784BF8955C73313CCB195904AE133E5F53~ordb3 at 37.59.47.27 is missing an ntor curve25519 onion key.
Oct 01 18:03:21.653 [notice] Descriptor from router $993992BBD01E36D3ECF8BA0B802C158961BB257C~orchard at 106.186.18.242 is missing an ntor curve25519 onion key.
Oct 01 18:04:00.856 [notice] Descriptor from router $496FED39C1469567B333C3A418A07D5CF62DCD23~rationalist at 87.106.249.248 is missing an ntor curve25519 onion key.
Oct 01 18:14:14.418 [notice] Descriptor from router $184A39F7F891D46592216643CD74DDE50C6DAA75~FlandersRegional at 89.106.244.21 is missing an ntor curve25519 onion key.
Oct 01 18:15:16.620 [notice] Descriptor from router $1AFA214C8AE557640BD29A0A8D674F92EB20948D~Unnamdddd at 95.78.221.81 is missing an ntor curve25519 onion key.
Oct 01 18:23:29.590 [notice] Descriptor from router $40E632BED95FC71E5B622DBB9E336D89A6D52600~younix at 85.214.63.239 is missing an ntor curve25519 onion key.
```
teor thinks this wasn't really meant to be a notice-level log every time an obsolete relay tries to upload to me.
That said, I think the first two of these relays (ordb1 and ordb3) are actually that alternative nodejs Tor relay implementation, right?
So I think maybe I *do* want to hear about relays that I refused due to lack of an ntor curve onion key, but only the ones that had a satisfactory version string?Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20247seccomp2 crash after closing and opening ipv6 DirPort + OrPort2020-06-27T13:58:07Ztoralfseccomp2 crash after closing and opening ipv6 DirPort + OrPortrun this :
```
/etc/init.d/tor status 2>/dev/null
if [[ $? -eq 0 ]]; then
sed -i -e 's/^DirPort *\[/#DirPort [/' -e 's/^ORPort *\[/#ORPort [/' /etc/tor/torrc
/etc/init.d/tor reload
fi
# renew cert
#
/usr/bin/certbot renew --standalo...run this :
```
/etc/init.d/tor status 2>/dev/null
if [[ $? -eq 0 ]]; then
sed -i -e 's/^DirPort *\[/#DirPort [/' -e 's/^ORPort *\[/#ORPort [/' /etc/tor/torrc
/etc/init.d/tor reload
fi
# renew cert
#
/usr/bin/certbot renew --standalone --non-interactive --text --renew-hook RestartJabber --disable-hook-validation &>$log
# reopen Tor ports
#
sed -i -e 's/^#DirPort *\[/DirPort [/' -e 's/^#ORPort *\[/ORPort [/' /etc/tor/torrc
/etc/init.d/tor status 2>/dev/null
if [[ $? -eq 0 ]]; then
/etc/init.d/tor reload
fi
```
to get this:
```
============================================================ T= 1474911552
(Sandbox) Caught a bad syscall attempt (syscall setsockopt)
/usr/bin/tor(+0x15dbc8)[0x1ac72c9bc8]
/lib64/libc.so.6(setsockopt+0xa)[0x30a1fef1a2a]
/lib64/libc.so.6(setsockopt+0xa)[0x30a1fef1a2a]
/usr/bin/tor(+0xee289)[0x1ac725a289]
/usr/bin/tor(retry_all_listeners+0x322)[0x1ac725bb12]
/usr/bin/tor(set_options+0xa7d)[0x1ac724e58d]
/usr/bin/tor(options_init_from_string+0x32e)[0x1ac725020e]
/usr/bin/tor(options_init_from_torrc+0x1e2)[0x1ac7250562]
/usr/bin/tor(+0x425c9)[0x1ac71ae5c9]
/usr/lib64/libevent-2.1.so.5(+0x2443b)[0x30a20e8043b]
/usr/lib64/libevent-2.1.so.5(event_base_loop+0x56f)[0x30a20e812cf]
/usr/bin/tor(do_main_loop+0x235)[0x1ac71acdd5]
/usr/bin/tor(tor_main+0x1bad)[0x1ac71b04cd]
/usr/bin/tor(main+0x2b)[0x1ac71a83ab]
/lib64/libc.so.6(__libc_start_main+0x114)[0x30a1fe1b734]
/usr/bin/tor(_start+0x29)[0x1ac71a83f9]
```Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20218Fix and refactor and redocument routerstatus_has_changed2020-06-27T13:58:08ZNick MathewsonFix and refactor and redocument routerstatus_has_changedThe routerstatus_has_changed() function is used by controllers to to tell which rs entries are new. But it only looks at a fraction of the fields which might change in a routerstatus. Also, it only checks for semantic changes that tor ...The routerstatus_has_changed() function is used by controllers to to tell which rs entries are new. But it only looks at a fraction of the fields which might change in a routerstatus. Also, it only checks for semantic changes that tor cares about (though this is not documented).Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20168Clarify our #if{n}def by commenting what they are at the #elif/#else/#endif2020-06-27T13:58:10ZDavid Gouletdgoulet@torproject.orgClarify our #if{n}def by commenting what they are at the #elif/#else/#endifOk that's an easy one!
The idea is to improve our comments in the .h/.c files where we have a `#ifdef BLAH` and the corresponding `#endif` is at least a non negligible amount of lines after. Of course that goes without saying to also co...Ok that's an easy one!
The idea is to improve our comments in the .h/.c files where we have a `#ifdef BLAH` and the corresponding `#endif` is at least a non negligible amount of lines after. Of course that goes without saying to also comment the `#ifndef`. Pattern would look like this:
```
#ifdef BLAH
[some non negligible amount of lines]
#elif /* BLAH */
[some other amount of lines]
#endif /* BLAH */
```
According to nickm, the current situation is:
Our headers have 27 #endifs with a comment, and 435 without.
Good example is `or.h`:
```
#ifndef TOR_OR_H
[5000+ lines in between]
#endif /* TOR_OR_H */
```
This file `src/or/shared_random.h` is a good example of what it could look like.Tor: 0.3.2.x-finalcjbcjbhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20164Warn relay operators when we guess an address from several equally valid alte...2020-07-27T22:55:40ZteorWarn relay operators when we guess an address from several equally valid alternativesWhen Tor chooses an address based on local network interface addresses, warn the operator if there were several valid addresses.
legacy/trac#20163 makes sure that we use the OS interface order, which is hopefully:
* stable, and
* in an...When Tor chooses an address based on local network interface addresses, warn the operator if there were several valid addresses.
legacy/trac#20163 makes sure that we use the OS interface order, which is hopefully:
* stable, and
* in an order determined by the operator.
It would be nice to do this if DNS returns several results as well, but I'm not sure if that's even possible. And it probably deserves a separate ticket if it is.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20163Keep the interface address order returned by the OS2020-06-27T13:58:11ZteorKeep the interface address order returned by the OSlegacy/trac#17027 unintentionally reorders interface addresses, by using SMARTLIST_DEL_CURRENT() in get_interface_address6_list() to delete unsuitable addresses, rather than SMARTLIST_DEL_CURRENT_KEEPORDER().
This makes address selectio...legacy/trac#17027 unintentionally reorders interface addresses, by using SMARTLIST_DEL_CURRENT() in get_interface_address6_list() to delete unsuitable addresses, rather than SMARTLIST_DEL_CURRENT_KEEPORDER().
This makes address selection unstable, because it depends on not only the exact order in which the OS returns addresses, but the exact number of unsuitable addresses as well.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20153VirtualAddrNetworkIPv6 man entry should say "[FC00::]/7"2021-07-22T16:23:16ZteorVirtualAddrNetworkIPv6 man entry should say "[FC00::]/7"IPv6 addresses have to have some colons somewhere.IPv6 addresses have to have some colons somewhere.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20152Update DirAuthority man entry for client begindir, no IPv6 DirPort2021-07-22T16:23:16ZteorUpdate DirAuthority man entry for client begindir, no IPv6 DirPortTor's DirAuthority entry says:
Tor will contact the authority at address:port (the DirPort) to
download directory documents. If an IPv6 address is supplied, Tor
will also download directory documents at t...Tor's DirAuthority entry says:
Tor will contact the authority at address:port (the DirPort) to
download directory documents. If an IPv6 address is supplied, Tor
will also download directory documents at the IPv6 address on the
DirPort.
But no Tor instance uses the IPv6 DirPort:
* clients (>= 0.2.8) use the IPv4 ORPort,
* clients (< 0.2.8) and relays use the IPv4 DirPort.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20151Fix parse_virtual_addr_network minimum network size2020-06-27T13:58:11ZteorFix parse_virtual_addr_network minimum network sizeparse_virtual_addr_network does:
```
const int max_bits = ipv6 ? 40 : 16;
```
then:
```
if (bits > max_bits) {
if (msg)
tor_asprintf(msg, "VirtualAddressNetwork%s expects a /%d "
"network or larger",ipv6?...parse_virtual_addr_network does:
```
const int max_bits = ipv6 ? 40 : 16;
```
then:
```
if (bits > max_bits) {
if (msg)
tor_asprintf(msg, "VirtualAddressNetwork%s expects a /%d "
"network or larger",ipv6?"IPv6":"", max_bits);
return -1;
}
```
Firstly, the log message refers to a minimum ("n or larger" makes n a minimum, not a maximum), but the variable is named "max_bits". So we should rename it to min_bits.
Secondly, an IPv6 /40 is terribly restrictive.
For people to use their local IPv6 allocations, we should allow at least a /64.
If the goal is to have a /16 available, we could allow up to 128 - 16 = /112. But IPv6 has more addresses than IPv4, so I suggest that a /104 is a sensible minimum. (If someone wants to map more than `2^24` addresses at once, they can choose a larger network. We could make the minimum /96, but some providers split up /64s into /96s and give them out to end users.)
These limitations should also be documented in the tor man page.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20119Tor should exit if it fails to write its PidFile, under principle of least co...2020-06-27T13:58:12Zyurivict271Tor should exit if it fails to write its PidFile, under principle of least confusion. Also, maybe Tor should create the directory that the PidFile points toRunning with the option: --PidFile /var/run/tor/tor.pid
Directory /var/run/tor is missing. Tor starts without any warnings. It has to either create the directory, or complain that it can't create the pid file.
FreeBSD 10.3Running with the option: --PidFile /var/run/tor/tor.pid
Directory /var/run/tor is missing. Tor starts without any warnings. It has to either create the directory, or complain that it can't create the pid file.
FreeBSD 10.3Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20117Update PathsNeededToBuildCircuits man page entry with actual default2021-07-22T16:23:16ZteorUpdate PathsNeededToBuildCircuits man page entry with actual default"if the directory authorities do not choose a value, Tor will use 0.6.""if the directory authorities do not choose a value, Tor will use 0.6."Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20061When unit testing in Tor2web mode, set the config correctly2020-06-27T13:58:16ZteorWhen unit testing in Tor2web mode, set the config correctlyWhen I compile with --enable-tor2web-mode, then run the unit tests, I get the following error:
```
$ make test
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-am
./src/test/test
Sep 05 15:34:15.560 [err] This copy of Tor was...When I compile with --enable-tor2web-mode, then run the unit tests, I get the following error:
```
$ make test
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-am
./src/test/test
Sep 05 15:34:15.560 [err] This copy of Tor was compiled to run in 'tor2web mode'. It can only be run with the Tor2webMode torrc option enabled.
Sep 05 15:34:15.561 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.2.9.2-alpha-dev )
make: *** [test] Error 1
```
In the unit test harness, we should set options->Tor2webMode when compiled in Tor2web mode.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20048Introduce `smartlist_add_strdup()` function2020-06-27T13:58:17ZGeorge KadianakisIntroduce `smartlist_add_strdup()` functionThere are many places in the code (and the tests) where we do the following pattern:
`smartlist_add(sl, tor_strdup(str))`
Some examples:
```
routerparse.c: smartlist_add(ns->package_lines, tor_strdup(t->args[0])));
ro...There are many places in the code (and the tests) where we do the following pattern:
`smartlist_add(sl, tor_strdup(str))`
Some examples:
```
routerparse.c: smartlist_add(ns->package_lines, tor_strdup(t->args[0])));
routerparse.c: smartlist_add(ns->known_flags, tor_strdup(tok->args[i]));
routerparse.c: smartlist_add(ns->net_params, tor_strdup(tok->args[i]));
routerparse.c: smartlist_add(ns->weight_params, tor_strdup(tok->args[i]));
routerparse.c: smartlist_add(md->family, tor_strdup(tok->args[i]));
routerset.c: smartlist_add(set->country_names, tor_strdup("??"));
routerset.c: smartlist_add(set->list, tor_strdup("{??}"));
routerset.c: smartlist_add(set->country_names, tor_strdup("a1"));
routerset.c: smartlist_add(set->list, tor_strdup("{a1}"));
```
One could imagine a `smartlist_add_strdup()` function that does this for the developer, and can be used in places where this pattern is used repeatedly.
It might simplify logic in a few places, or maybe it will confuse peole who grep for `tor_strdup` searching for allocations.
If people think this is worth doing, let's do it!Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20035Identify client-specific options that work with hidden services2021-07-22T16:23:16ZteorIdentify client-specific options that work with hidden servicesMany of the "client-specific" options in the tor manual page work with Hidden Services.
Others, such as Socks/Trans/NATD/DNSPort, do not.
It would be great to split up the client-only section into those options that truly only work for...Many of the "client-specific" options in the tor manual page work with Hidden Services.
Others, such as Socks/Trans/NATD/DNSPort, do not.
It would be great to split up the client-only section into those options that truly only work for clients, and those that also affect the behaviour of hidden services (and bridge relays, and relays, and authorities).
For example, when a bridge relay builds an anonymous 3-hop path to submit its descriptor, it is likely affected by all the client options that affect node selection. (Unless we specifically disable them for servers.)
And a hidden service's paths are affected by these same options.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20014GETINFO version in torspec is inconsistent with the implementation2021-07-22T16:23:16ZteorGETINFO version in torspec is inconsistent with the implementationThe torspec description of GETINFO version is:
```
"version" -- The version of the server's software, including the name
of the software. (example: "Tor 0.0.9.4")
```
But tor responds:
```
GETINFO version
250-version=0.2.8.6 (...The torspec description of GETINFO version is:
```
"version" -- The version of the server's software, including the name
of the software. (example: "Tor 0.0.9.4")
```
But tor responds:
```
GETINFO version
250-version=0.2.8.6 (git-4d217548e3f05569)
250 OK
```
The "Tor " is missing from the response. We should remove it from the spec.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19979Use OpenSSL 1.1.0 HKDF in Tor when available.2021-09-16T14:33:30ZNick MathewsonUse OpenSSL 1.1.0 HKDF in Tor when available.OpenSSL 1.1.0 now includes HKDF support. We should consider using their implementation instead of ours when it's available.OpenSSL 1.1.0 now includes HKDF support. We should consider using their implementation instead of ours when it's available.Tor: 0.3.5.x-finalrl1987rl1987