The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-06-18T18:09:39Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20625When a consensus doesn't have enough signatures, write it (and sigs) to a file2021-06-18T18:09:39ZteorWhen a consensus doesn't have enough signatures, write it (and sigs) to a fileJust like we write 'unparseable-desc' and 'v3-status-votes' to a file, it would be great to write 'unpublished[-flavour]-consensus' to a file, when we log this message:
```
Nov 10 21:00:01.000 [warn] A consensus needs 5 good signatures ...Just like we write 'unparseable-desc' and 'v3-status-votes' to a file, it would be great to write 'unpublished[-flavour]-consensus' to a file, when we log this message:
```
Nov 10 21:00:01.000 [warn] A consensus needs 5 good signatures from recognized authorities for us to accept it. This one has 4 (...). 4 (...) of the authorities we know didn't sign it.
Nov 10 21:00:01.000 [warn] Not enough info to publish pending ns consensus
```
Similarly, when we disagree about signatures, we should write 'unpublished-[-flavour]-signatures', when we log this message:
```
Nov 10 21:27:32.000 [warn] Problem adding detached signatures from <redacted-address-and-port>: Mismatched digest.
```
(Or, even better, write both matching and mismatching signatures to the file.)
One catch:
These new filenames need to be added to the sandbox.https://gitlab.torproject.org/tpo/core/tor/-/issues/20611Relays should log a message when they return a 503 error to a client2020-06-27T13:57:50ZteorRelays should log a message when they return a 503 error to a clientA relay operator is concerned that their relay is returning 503 errors, but there are no corresponding errors in the logs.A relay operator is concerned that their relay is returning 503 errors, but there are no corresponding errors in the logs.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20581warning: 'enc_b64_blob' may be used uninitialized in this function2020-06-27T13:57:52ZTracwarning: 'enc_b64_blob' may be used uninitialized in this functionI'm seeing:
src/or/hs_descriptor.c: In function 'desc_encode_v3':
src/or/hs_descriptor.c:787: warning: 'enc_b64_blob' may be used uninitialized in this function
It looks like any situation where enc_b64_blob doesn't get initial...I'm seeing:
src/or/hs_descriptor.c: In function 'desc_encode_v3':
src/or/hs_descriptor.c:787: warning: 'enc_b64_blob' may be used uninitialized in this function
It looks like any situation where enc_b64_blob doesn't get initialised it also doesn't get used, and clang doesn't complain, so I think this is just OpenBSD's old gcc being silly but could it be initialised to make it happy?
```
diff --git a/src/or/hs_descriptor.c b/src/or/hs_descriptor.c
index 7c5d204..bc72034 100644
--- a/src/or/hs_descriptor.c
+++ b/src/or/hs_descriptor.c
@@ -784,7 +784,7 @@ desc_encode_v3(const hs_descriptor_t *desc, char **encoded_out)
/* Build the encrypted data section. */
{
- char *enc_b64_blob;
+ char *enc_b64_blob = NULL;
if (encode_encrypted_data(desc, &enc_b64_blob) < 0) {
goto err;
}
```
(I didn't want to make a new ticket for this but trac wouldn't let me post it on legacy/trac#18571, sorry)
**Trac**:
**Username**: rubiateTor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20568Move encode_cert() from hs_descriptor.c into torcert.c2021-09-16T14:33:04ZDavid Gouletdgoulet@torproject.orgMove encode_cert() from hs_descriptor.c into torcert.cGive it a better name, maybe improve the code to be a bit more generic and start using it in router.c at minimum.Give it a better name, maybe improve the code to be a bit more generic and start using it in router.c at minimum.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20567hs: Document arguments of rend_data_service_create() and rend_data_client_cre...2020-06-27T13:57:54ZDavid Gouletdgoulet@torproject.orghs: Document arguments of rend_data_service_create() and rend_data_client_create()Title says it all. We need much more details on those important functions. Let's make it happen for 030.Title says it all. We need much more details on those important functions. Let's make it happen for 030.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20509Directory authorities should reject relays with #20499 bug2020-06-27T13:57:57ZRoger DingledineDirectory authorities should reject relays with #20499 bugOnce we resolve legacy/trac#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 bo...Once we resolve legacy/trac#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/tpo/core/tor/-/issues/20492Tor git version is not generated in git worktrees2020-06-27T13:57:58ZteorTor git version is not generated in git worktreesWhen I compile tor on macOS, it doesn't log the git version on startup:
```
Oct 29 01:27:48.261 [notice] Tor 0.3.0.0-alpha-dev running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
```
This happens regardless of ...When I compile tor on macOS, it doesn't log the git version on startup:
```
Oct 29 01:27:48.261 [notice] Tor 0.3.0.0-alpha-dev running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
```
This happens regardless of compiler and architecture:
gcc (MacPorts gcc49 4.9.4_0+universal) 4.9.4 (i386/x86_64)
clang version 3.9.0 (tags/RELEASE_390/final) (x86_64)
$ git --version
git version 2.10.1
But when I compile it on Linux, I see a git commit hash:
```
Oct 28 14:28:15.669 [notice] Tor 0.3.0.0-alpha-dev (git-f3e158edf7d8128d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g and Zlib 1.2.8.
```
Compiler:
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
$ git --version
git version 2.6.3.36.g9a8c740
I'm putting this in 0.3.0 because it makes diagnosing issues much easier if we have the full commit. But feel free to disagree.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20488Nickname registration message is confusing2020-06-27T13:57:58ZteorNickname registration message is confusingtoralf says:
```
wrt to this syslog massage : "You specified a server "zwiebeltoralf" by name, but the directory authorities do not have any key registered for this nickname" - how can I register my nickname ?
```
We should change th...toralf says:
```
wrt to this syslog massage : "You specified a server "zwiebeltoralf" by name, but the directory authorities do not have any key registered for this nickname" - how can I register my nickname ?
```
We should change this message to be clearer, particularly because we don't use the Named/Unnamed flags any more.
We could just say "don't have any relay for this nickname".Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20486HiddenServiceDirectory is created if it doesn't exist2021-07-22T16:22:54ZteorHiddenServiceDirectory is created if it doesn't existSplit off legacy/trac#20484
* Update the man page, which incorrectly says that HiddenServiceDirectory must exist - tor creates the HiddenServiceDirectory if it doesn't existSplit off legacy/trac#20484
* Update the man page, which incorrectly says that HiddenServiceDirectory must exist - tor creates the HiddenServiceDirectory if it doesn't existTor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20474Tor should try harder to choose nodes in small networks2020-06-27T13:57:59ZteorTor should try harder to choose nodes in small networksIn https://trac.torproject.org/projects/tor/ticket/14881#comment:58 , pastly reports that in networks without bandwidth weights, tor says:
> Oct 26 19:56:00.000 [warn] Failed to find node for hop 1 of our path. Discarding this circuit.
...In https://trac.torproject.org/projects/tor/ticket/14881#comment:58 , pastly reports that in networks without bandwidth weights, tor says:
> Oct 26 19:56:00.000 [warn] Failed to find node for hop 1 of our path. Discarding this circuit.
We should fix this at some point by falling back to choosing a random node.Tor: unspecifiedhttps://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-final