The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:57:58Zhttps://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/13862No error message when fatally failing to open files in DataDirectory2020-06-27T14:02:09ZTracNo error message when fatally failing to open files in DataDirectoryDue to installing packages from conflicting sources, I ended up with a Tor installation where the tor daemon (with `User toranon`) could access the DataDirectory, but not open the files in it for lack of permissions.
In this situation, ...Due to installing packages from conflicting sources, I ended up with a Tor installation where the tor daemon (with `User toranon`) could access the DataDirectory, but not open the files in it for lack of permissions.
In this situation, tor exits quickly with only the following messages:
```
Nov 30 00:07:12.878 [notice] Tor v0.2.5.10 (git-42b42605f8d8eac2) running on Linux with Libevent 2.0.18-stable, OpenSSL 1.0.1e-fips and Zlib 1.2.7.
Nov 30 00:07:12.878 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Nov 30 00:07:12.878 [notice] Read configuration file "/usr/share/tor/defaults-torrc".
Nov 30 00:07:12.878 [notice] Read configuration file "/etc/tor/torrc".
Nov 30 00:07:12.881 [notice] Opening Socks listener on 127.0.0.1:9050
Nov 30 00:07:12.881 [notice] Opening Control listener on 127.0.0.1:9151
Nov 30 00:07:12.881 [notice] Caching new entry toranon for toranon
Nov 30 00:07:12.881 [notice] Caching new entry toranon for toranon
```
There are no explicit `Log` directives in torrc.
Except for exit status 1, there is no indication to the user that something has gone wrong, and what the problem could be. We should print a helpful error message.
**Trac**:
**Username**: sqrt2Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3349No SIGNAL controller event sent when delayed SIGNAL NEWNYM is handled2020-06-27T14:08:12ZRobert RansomNo SIGNAL controller event sent when delayed SIGNAL NEWNYM is handled```
signal newnym
250 OK
650 SIGNAL NEWNYM
signal newnym
250 OK
```
(I waited for well over 10 seconds; no ‘`650 SIGNAL NEWNYM`’ appeared.)```
signal newnym
250 OK
650 SIGNAL NEWNYM
signal newnym
250 OK
```
(I waited for well over 10 seconds; no ‘`650 SIGNAL NEWNYM`’ appeared.)Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24001node_get_ed25519_id() should check if the microdesc ed25519 id is all zero2020-06-27T13:55:12Zteornode_get_ed25519_id() should check if the microdesc ed25519 id is all zeroCurrently we only do this for the ri ed25519 id.
If that check is already done when we parse microdescs, we should add a comment.Currently we only do this for the ri ed25519 id.
If that check is already done when we parse microdescs, we should add a comment.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11059Nodes' country codes should be "definite" and "possible"2021-06-18T18:21:29ZNick MathewsonNodes' country codes should be "definite" and "possible"It would maybe be a good idea if nodes' country codes could have different statues, like "definitely in CC" or "possibly in CC". For example, if a country is "possibly in CC", then "ExcludeNodes {CC}" should exclude it, but "EntryNodes ...It would maybe be a good idea if nodes' country codes could have different statues, like "definitely in CC" or "possibly in CC". For example, if a country is "possibly in CC", then "ExcludeNodes {CC}" should exclude it, but "EntryNodes {CC}" should not include it.
This would also let us provide the feature that some operators have asked for of being able to specify their country. (I'd say that if you specify that you are in C1, but geoip says you are in C2, then you should count as "maybe in C1" and "maybe in C2" but not as definitely in either.)
See legacy/trac#11054 for another motivating example.
Is this a good idea?https://gitlab.torproject.org/tpo/core/tor/-/issues/3442non-relays shouldn't mark_my_descriptor_dirty2020-06-27T14:08:08ZRoger Dingledinenon-relays shouldn't mark_my_descriptor_dirtyMy Tor client just said
```
Jun 21 01:49:16.968 [info] mark_my_descriptor_dirty(): Decided to publish new relay descriptor: time for new descriptor
```
This statement is false.My Tor client just said
```
Jun 21 01:49:16.968 [info] mark_my_descriptor_dirty(): Decided to publish new relay descriptor: time for new descriptor
```
This statement is false.Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4413Non-triggerable integer overflow in crypto_random_hostname()2020-06-27T14:07:27ZGeorge KadianakisNon-triggerable integer overflow in crypto_random_hostname()```
char *
crypto_random_hostname(int min_rand_len, int max_rand_len, const char *prefix,
const char *suffix)
...
randlen = min_rand_len + crypto_rand_int(max_rand_len - min_rand_len + 1);
...
rand_bytes_len = ...```
char *
crypto_random_hostname(int min_rand_len, int max_rand_len, const char *prefix,
const char *suffix)
...
randlen = min_rand_len + crypto_rand_int(max_rand_len - min_rand_len + 1);
...
rand_bytes_len = ((randlen*5)+7)/8;
if (rand_bytes_len % 5)
rand_bytes_len += 5 - (rand_bytes_len%5);
rand_bytes = tor_malloc(rand_bytes_len);
```
If `randlen` overflows in `rand_bytes_len = ((randlen*5)+7)/8;` we pass a negative value to `tor_malloc()`.
I don't see this happening any time soon, since all the currently used crypto_random_hostname() arguments are very small, but it might be good to fix it for completeness.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28113notify systemd if shutdown will be longer than 30 seconds2022-06-17T18:19:00ZAlex Xunotify systemd if shutdown will be longer than 30 secondscurrently systemd just kills tor if the user sets ShutdownWaitLength more than 30 seconds. we should tell systemd not to kill tor.currently systemd just kills tor if the user sets ShutdownWaitLength more than 30 seconds. we should tell systemd not to kill tor.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40186noto-fonts Git repo is excessively large2022-12-08T15:15:28ZJeremyRandnoto-fonts Git repo is excessively largeThe `noto-fonts` Git repo (cloned as part of the `fonts` project) uses over 6 GiB of storage, even though downloading a `.zip` archive from GitHub of the tree at that commit hash results in an archive that uses less than 40 MiB when deco...The `noto-fonts` Git repo (cloned as part of the `fonts` project) uses over 6 GiB of storage, even though downloading a `.zip` archive from GitHub of the tree at that commit hash results in an archive that uses less than 40 MiB when decompressed. Is there any reason that it's downloaded via Git rather than a standard HTTPS archive download? The excessively large size is a significant barrier to some users with limited storage capacity and/or network bandwidth.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18532Now search.disconnect.me through catchall too2022-07-13T12:49:45ZbugzillaNow search.disconnect.me through catchall too[03-11 17:31:16] Torbutton INFO: tor SOCKS isolation catchall: https://search.disconnect.me/searchTerms/search?ses=Google&location_option=US&source=tor via --unknown--:75
Windows only?[03-11 17:31:16] Torbutton INFO: tor SOCKS isolation catchall: https://search.disconnect.me/searchTerms/search?ses=Google&location_option=US&source=tor via --unknown--:75
Windows only?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/10720NSIS scripts can request Windows to avoid registry writes?2020-06-27T14:42:20ZMike PerryNSIS scripts can request Windows to avoid registry writes?In https://trac.torproject.org/projects/tor/ticket/7842#comment:20, Runa mentioned that NSIS scripts can request to avoid writing to the Windows registry.
We should figure out how to do this and use those settings in the TBB Windows NSI...In https://trac.torproject.org/projects/tor/ticket/7842#comment:20, Runa mentioned that NSIS scripts can request to avoid writing to the Windows registry.
We should figure out how to do this and use those settings in the TBB Windows NSIS scripts (which live at https://github.com/moba/tbb-windows-installer).Erinn ClarkErinn Clarkhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7869ntor-onion-key is padded with an equal sign2021-07-09T17:22:51ZRobert Ransomntor-onion-key is padded with an equal signReplying to [sonu](legacy/trac#7867):
>
```
ntor-onion-key Od2Sj3UXFyDjwESLXk6fhatqW9z/oBL/vAKJ+tbDqUU=
```
The unnecessary “`=`” at the end of that string needs to go away **now**, or every Tor client will have to download a thousand ...Replying to [sonu](legacy/trac#7867):
>
```
ntor-onion-key Od2Sj3UXFyDjwESLXk6fhatqW9z/oBL/vAKJ+tbDqUU=
```
The unnecessary “`=`” at the end of that string needs to go away **now**, or every Tor client will have to download a thousand or so of them every week forever.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/web/manual/-/issues/8obfs3 - Update Pluggable Transports section2021-08-23T16:29:53ZGusobfs3 - Update Pluggable Transports sectionTor Browser don't ship obfs3 as default bridge.
So we should update it in this section:
https://tb-manual.torproject.org/transports/
See: https://trac.torproject.org/projects/tor/ticket/31060Tor Browser don't ship obfs3 as default bridge.
So we should update it in this section:
https://tb-manual.torproject.org/transports/
See: https://trac.torproject.org/projects/tor/ticket/31060https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40465Onion Authentication fails when connecting to a subdomain2022-10-12T23:23:27ZcypherpunksOnion Authentication fails when connecting to a subdomainSpecs (shouldn't be very important other than the version):
Tor Browser 10.0.17
Safer Setting
Linux X11
Steps to reproduce:
1. Obtain a service descriptor for an authenticating onion service.
1. Open Tor Browser or click New Identit...Specs (shouldn't be very important other than the version):
Tor Browser 10.0.17
Safer Setting
Linux X11
Steps to reproduce:
1. Obtain a service descriptor for an authenticating onion service.
1. Open Tor Browser or click New Identity.
1. Check that the key to the onion service has not been saved (about:preferences#privacy -> Onion Services Authentication -> Saved Keys...).
1. Go to `subdomain.[service descriptor].onion`.
1. Enter the correct authentication key.
What happens:
Tor Browser does not accept the key and an error message pops up: Invalid v3 address "subdomain.[service descriptor]"
What should happen:
Tor Browser authenticates normally with the onion service.
Extra notes:
This does not happen if the user has visited `[service descriptor].onion` and successfully authenticated *before* visiting `subdomain.[service descriptor].onion`, all in the same session. The problem might be with the authentication dialog.Sponsor 131 - Phase 5 - Ongoing Maintenancerichardrichardhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16785Only build/use ed25519-donna.2021-06-18T18:15:52ZYawning AngelOnly build/use ed25519-donna.More a long term thing so I don't forget about it, but once we are sure we like `ed25519-donna`, we can/should remove the `ref10` code from builds, along with the paranoid initialization/runtime sanity checking, as well as only using the...More a long term thing so I don't forget about it, but once we are sure we like `ed25519-donna`, we can/should remove the `ref10` code from builds, along with the paranoid initialization/runtime sanity checking, as well as only using the donna Curve25519 keypair generation code.
I'd be ok with keeping the code around as part of the test suite to catch mysterious breakage. Tentatively setting this to `0.2.8.x-final` since I don't think enough people run the alpha build for us to catch discrepancies between the two codebases if any exist.https://gitlab.torproject.org/tpo/core/tor/-/issues/29617OOM manger wipes entire DNS cache2020-06-27T13:50:46ZpullsOOM manger wipes entire DNS cacheIn relay.c, function cell_queues_check_size, the OOM manager attempts to clear one tenth of MaxMemInQueues bytes from the DNS cache by calling dns_cache_handle_oom. The function dns_cache_handle_oom, in dns.c, runs in a loop removing cac...In relay.c, function cell_queues_check_size, the OOM manager attempts to clear one tenth of MaxMemInQueues bytes from the DNS cache by calling dns_cache_handle_oom. The function dns_cache_handle_oom, in dns.c, runs in a loop removing cached entries that are now+n*time_inc old, until at least the requested number of bytes have been freed. The first iteration of the loop has n=0, and likely will not remove enough bytes. The second iteration is way too aggressive, because:
```
time_inc += 3600; /* Increase time_inc by 1 hour. */
```
This is guaranteed to wipe the entire DNS cache, because in dns_clip_ttl the maximum time to cache is MAX_DNS_TTL_AT_EXIT, which is set in dns.h to:
```
/** Lowest value for DNS ttl that a server will give. */
#define MIN_DNS_TTL_AT_EXIT (5*60)
/** Highest value for DNS ttl that a server will give. */
#define MAX_DNS_TTL_AT_EXIT (60*60)
```
One possible and reasonable fix would be to instead increment time_inc by MIN_DNS_TTL_AT_EXIT.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28760Option/* format for ControlPort options needs to be homogeneous2021-06-18T18:29:56ZTracOption/* format for ControlPort options needs to be homogeneousAccording to [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|control-spec.txt]]:
> The OptionPrefix form indicates a number of options beginning with the prefix. So if `config/*` is listed, other options beginning with...According to [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|control-spec.txt]]:
> The OptionPrefix form indicates a number of options beginning with the prefix. So if `config/*` is listed, other options beginning with `config/` will work, but `config/*` itself is not an option.
In Nyx and `tor-prompt` interpreters' `/help`, if the format `Option/*` is used to name a group of options (each of them is still described separately), it must be done for everything. However, e.g., we have many options inside `accounting`, but key `accounting/*` doesn't exist:
```
accounting/bytes - Number of bytes read/written so far in the accounting interval.
accounting/bytes-left - Number of bytes left to write/read so far in the accounting interval.
accounting/enabled - Is accounting currently enabled?
accounting/hibernating - Are we hibernating or awake?
accounting/interval-end - Time when the accounting period ends.
accounting/interval-start - Time when the accounting period starts.
accounting/interval-wake - Time to wake up in this accounting period.
```
Compare it with:
```
config/* - Current configuration values.
config/defaults - List of default values for configuration options. See also config/names
config/names - List of configuration options, types, and documentation.
```
If grouping syntax is used, it should be used everywhere (for all groups) or nowhere. Otherwise, it is confusing, because for many other options the syntax `option/*` implies that something not listed here (in list of options) should be substituted (e.g. fingerprint of a relay, IP address, etc.).
P.S. At first glance it looks like Nyx controller interpreter's bug, but atagar [[https://trac.torproject.org/projects/tor/ticket/28300#comment:5|says]] that it is taken literally from `control-spec.txt`. Initially it was reported in [[comment](https://trac.torproject.org/projects/tor/ticket/28300#comment:6|this)]. Separate ticket was created because of [[suggestion](https://trac.torproject.org/projects/tor/ticket/28676#comment:8|teor's)].
**Trac**:
**Username**: wagonhttps://gitlab.torproject.org/tpo/web/support/-/issues/78Organise APT section in a more meaningful way2020-06-27T13:39:56ZGusOrganise APT section in a more meaningful wayFor each question in [APT](https://support.torproject.org/apt/) section, you will need to add a new value, for example:
```
key: 1
```
See #77For each question in [APT](https://support.torproject.org/apt/) section, you will need to add a new value, for example:
```
key: 1
```
See #77https://gitlab.torproject.org/tpo/web/support/-/issues/77Organise Tor Browser section in a more meaningful way2020-10-16T19:38:02ZGusOrganise Tor Browser section in a more meaningful wayFor each question in [Tor Browser section](https://support.torproject.org/tbb/), you will need to add a new value, for example:
```
key: 1
```
So you need to read all questions, figure out the best order from user perspective, edit the...For each question in [Tor Browser section](https://support.torproject.org/tbb/), you will need to add a new value, for example:
```
key: 1
```
So you need to read all questions, figure out the best order from user perspective, edit the file and add key: number. See another example [here](https://raw.githubusercontent.com/torproject/support/master/content/about/backdoor/contents.lr).
And https://support.torproject.org/tbb/how-to-verify-signature/ should be **key: 1** . :smirk_cat:https://gitlab.torproject.org/tpo/core/tor/-/issues/13315Our SOCKS hostname validation is overly lax.2020-06-27T14:02:24ZYawning AngelOur SOCKS hostname validation is overly lax.This applies to both SOCKS4a and SOCKS5.
What we check (for rejection): `!tor_strisprint(req->address) || strchr(req->address,'\"')`
What the RFC says (RFC 1035 - 2.3.1. Preferred name syntax):
```
<domain> ::= <subdomain> | " "
<subd...This applies to both SOCKS4a and SOCKS5.
What we check (for rejection): `!tor_strisprint(req->address) || strchr(req->address,'\"')`
What the RFC says (RFC 1035 - 2.3.1. Preferred name syntax):
```
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
```
Changing the check to enforce isalnum(), '.' and '-' would cut out a lot more things that are flat out invalid.
The one concern (raised by nickm) is "are there clients that send IPv6 addresses as FQDNs"? This is plausible for SOCKS4a (because it's the only way to get IPv6 support to work), and a sign of broken client that deserves to be laughed at for SOCKS5. Calling `tor_inet_pton()` on the FQDN before filtering will cover this case (and is probably something we should do anyway for SafeSocks).
This may be another legacy/trac#11138 will fix it sort of issue, though the changes are likewise trivial to do.rl1987rl1987