The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-02-07T19:30:50Zhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/30305Chutney should give better failure info when its Tor has --disable-module-dir...2022-02-07T19:30:50ZNick MathewsonChutney should give better failure info when its Tor has --disable-module-dirauthIf Tor can't be a directory authority, you can't have a private network, so chutney won't work. But chutney doesn't notice, and it tries to run anyway, instead of telling you what the problem is.
This just consumed 20 minutes of my mor...If Tor can't be a directory authority, you can't have a private network, so chutney won't work. But chutney doesn't notice, and it tries to run anyway, instead of telling you what the problem is.
This just consumed 20 minutes of my morning. Maybe we can fix it along with our other plans to give chutney a "will this network work" command.https://gitlab.torproject.org/tpo/core/tor/-/issues/30267Simplify the code logic of launching HS circuits2021-09-16T14:19:58ZGeorge KadianakisSimplify the code logic of launching HS circuitsThe intro/rendezvous parts of `circuit_get_open_circ_or_launch()` are very complicated, and then they call `circuit_get_open_circ_or_launch()` which is also extremely complicated.
A minimal action item for improving the situation here w...The intro/rendezvous parts of `circuit_get_open_circ_or_launch()` are very complicated, and then they call `circuit_get_open_circ_or_launch()` which is also extremely complicated.
A minimal action item for improving the situation here would be to split the HS-parts of `connection_ap_handshake_attach_circuit()` which are already pretty disentangled into their own function. That's pretty easy to do.
The harder part of this would be to see if we can also split the HS parts of `circuit_get_open_circ_or_launch()` in some way.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30209logins.json data is added unencrypted, maybe that's why people have problems ...2023-01-05T16:36:11ZTraclogins.json data is added unencrypted, maybe that's why people have problems with saved login data1)
install TB
disable always private surfing
enable saving login data
open a page with login form, logon and accept saving login data
data is being added to logins.json in unencrypted form
so far all seems right, but you will not be able...1)
install TB
disable always private surfing
enable saving login data
open a page with login form, logon and accept saving login data
data is being added to logins.json in unencrypted form
so far all seems right, but you will not be able to USE the saved logins
2)
go options again, set master pass, apply
add another login (go logon somewhere and save)
data is STILL being added to logins.json in UNENCRYPTED form (and unencrypted is not being encrypted)
STILL not able to use the saved data
3)
copy over old logins.json and key4.db
voila, you can use it...
again try to add a new login to the old data -> same as 1) and 2) applies
implies the mechanism is broken
i can not find a fix
**Trac**:
**Username**: sashamanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30187100% cpu usage in winthreads tor_cond_wait2021-01-19T21:23:07ZTrac100% cpu usage in winthreads tor_cond_waitFor years I run relay using self-compiled win64 version of tor.
Compiler mingw64.
Relay runs well for some time but suddenly starts using 100% cpu all cores.
I traced where it happens. The following loop never ends :
```
do {
DWO...For years I run relay using self-compiled win64 version of tor.
Compiler mingw64.
Relay runs well for some time but suddenly starts using 100% cpu all cores.
I traced where it happens. The following loop never ends :
```
do {
DWORD res;
res = WaitForSingleObject(cond->event, ms);
EnterCriticalSection(&cond->lock);
if (cond->n_to_wake &&
cond->generation != generation_at_start) {
--cond->n_to_wake;
--cond->n_waiting;
result = 0;
waiting = 0;
goto out;
} else if (res != WAIT_OBJECT_0) {
result = (res==WAIT_TIMEOUT) ? 1 : -1;
--cond->n_waiting;
waiting = 0;
goto out;
} else if (ms != INFINITE) {
endTime = GetTickCount();
if (startTime + ms_orig <= endTime) {
result = 1; /* Timeout */
--cond->n_waiting;
waiting = 0;
goto out;
} else {
ms = startTime + ms_orig - endTime;
}
}
/* If we make it here, we are still waiting. */
if (cond->n_to_wake == 0) {
/* There is nobody else who should wake up; reset
* the event. */
ResetEvent(cond->event);
}
out:
LeaveCriticalSection(&cond->lock);
} while (waiting);
```
res = WAIT_OBJECT_0;
ms = INFINITE;
cond->n_to_wake=0x11
cond->generation=0x28
generation_at_start=0x28
it means no path with "goto out" ever execute
more than one thread run this loop and each one eat separate core
Some people I shared binaries with report same problem.
Pls check
**Trac**:
**Username**: bolvanTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/30153Add a command to chutney and test-network.sh that prints the default option v...2022-02-07T19:30:48ZteorAdd a command to chutney and test-network.sh that prints the default option valuesFollow up to legacy/trac#30059.
We should make a chutney command and a test-network.sh command that prints their default option values.
Maybe we could even import the defaults from chutney into test-network.sh.
Then we can update the ...Follow up to legacy/trac#30059.
We should make a chutney command and a test-network.sh command that prints their default option values.
Maybe we could even import the defaults from chutney into test-network.sh.
Then we can update the README to say:
"For the default values of these options, run..."https://gitlab.torproject.org/tpo/core/tor/-/issues/30119cert-spec uses binary encodings but does not specify byte order2021-07-22T16:19:43Zirlcert-spec uses binary encodings but does not specify byte orderFrom looking at the Tor implementation (in a black box way, didn't look at the source code) these seem to be big endian byte order. We should have a note in cert-spec for implementors so they don't have to guess.From looking at the Tor implementation (in a black box way, didn't look at the source code) these seem to be big endian byte order. We should have a note in cert-spec for implementors so they don't have to guess.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30109Document that MapAddress is automatically strict, but does not handle redirects2021-08-23T15:16:06ZteorDocument that MapAddress is automatically strict, but does not handle redirectsWe should document that:
1. StrictNodes does not apply to MapAddress
2. MapAddress ~~falls back to a random exit by default~~ fails rather than falling back to a random exit
Edited to add:
3. If the site does a redirect, MapAddress does...We should document that:
1. StrictNodes does not apply to MapAddress
2. MapAddress ~~falls back to a random exit by default~~ fails rather than falling back to a random exit
Edited to add:
3. If the site does a redirect, MapAddress does not apply to the new siteTor: 0.4.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30045output of "tor --key-expiration sign" should be a time stamp2020-08-04T17:29:41Ztoralfoutput of "tor --key-expiration sign" should be a time stampIt would be helpful for a cron job having sth like
```
let "diff = $(tor --key-expiration sign --format=timestamp) - $(date +%s)"
```
in it.It would be helpful for a cron job having sth like
```
let "diff = $(tor --key-expiration sign --format=timestamp) - $(date +%s)"
```
in it.https://gitlab.torproject.org/tpo/core/tor/-/issues/29979Don't recommend expect() in CodingStandardsRust, because it panics2021-07-22T16:19:43ZteorDon't recommend expect() in CodingStandardsRust, because it panicsSee the pull request from a GitHub contributor:
https://github.com/torproject/tor/pull/883See the pull request from a GitHub contributor:
https://github.com/torproject/tor/pull/883Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/29953Parent ticket for easy tickets that do not change version2021-06-15T14:21:22ZjugaParent ticket for easy tickets that do not change versionChild issues:
- #29952
- #28045
- #29294
- #28589
- #28758
- #28759Child issues:
- #29952
- #28045
- #29294
- #28589
- #28758
- #28759sbws: unspecifiedhttps://gitlab.torproject.org/tpo/community/l10n/-/issues/40016Cannot choose language on mobile2021-03-02T10:33:39ZstephwCannot choose language on mobileThe entire language list is not accessible on mobile.
https://twitter.com/glotzbach/status/1111165746623799296The entire language list is not accessible on mobile.
https://twitter.com/glotzbach/status/1111165746623799296https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/29886NoScript icon is still visible in context menu after the fix for #25658 landed2023-11-27T12:07:07ZGeorg KoppenNoScript icon is still visible in context menu after the fix for #25658 landedA user on the blog noticed that we removed the NoScript toolbar icon but the one in the context menu is still visible. (see: https://blog.torproject.org/comment/280411#comment-280411). Moreover, clicking on it results in an error:
```
Ty...A user on the blog noticed that we removed the NoScript toolbar icon but the one in the context menu is still visible. (see: https://blog.torproject.org/comment/280411#comment-280411). Moreover, clicking on it results in an error:
```
TypeError: this.getPlacementOfWidget(...) is null[Learn More] CustomizableUI.jsm:1638:18
```Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29789practracker.py codec exception in some locales2020-06-27T13:50:39ZTaylor Yupractracker.py codec exception in some localespractracker.py, implemented in legacy/trac#29221, seems to have a locale dependency when python3 is being used. If the locale isn't a UTF-8 locale, UTF-8 characters in sources can result in an exception:
```
$ LANG=en_US.US-ASCII make ...practracker.py, implemented in legacy/trac#29221, seems to have a locale dependency when python3 is being used. If the locale isn't a UTF-8 locale, UTF-8 characters in sources can result in an exception:
```
$ LANG=en_US.US-ASCII make check-best-practices PYTHON=python
python ../scripts/maint/practracker/practracker.py ..
mirkwood:build-norust tlyu$ LANG=en_US.US-ASCII make check-best-practices
python3 ../scripts/maint/practracker/practracker.py ..
Traceback (most recent call last):
File "../scripts/maint/practracker/practracker.py", line 151, in <module>
main()
File "../scripts/maint/practracker/practracker.py", line 134, in main
found_new_issues = consider_all_metrics(files_list)
File "../scripts/maint/practracker/practracker.py", line 89, in consider_all_metrics
found_new_issues |= consider_metrics_for_file(fname, f)
File "../scripts/maint/practracker/practracker.py", line 104, in consider_metrics_for_file
found_new_issues |= consider_file_size(fname, f)
File "../scripts/maint/practracker/practracker.py", line 51, in consider_file_size
file_size = metrics.get_file_len(f)
File "/Users/tlyu/src/tor/scripts/maint/practracker/metrics.py", line 11, in get_file_len
for i, l in enumerate(f):
File "/Users/tlyu/src/brew/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 14: ordinal not in range(128)
make: *** [check-best-practices] Error 1
```
I'm also seeing this on gitlab.com CI, but I don't know offhand what its locale environment variables are.
We might want to use the `encoding=` keyword parameter to `open()`, but I think that would no longer be python2 compatible.Tor: 0.4.1.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29777Rate-limit "Problem bootstrapping" warnings to one every 5 seconds2022-02-07T19:39:00ZteorRate-limit "Problem bootstrapping" warnings to one every 5 secondsLet's put a rate-limit on warnings like this:
```
Jan 29 11:36:27.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 11; recommendation warn; host 322C6E3A973BC10FC36DE3037AD27BC89...Let's put a rate-limit on warnings like this:
```
Jan 29 11:36:27.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 11; recommendation warn; host 322C6E3A973BC10FC36DE3037AD27BC89F14723B at 212.83.154.33:8443)
```https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/29749Remove never used "userquery" code2022-01-28T11:02:56ZjugaRemove never used "userquery" codesbws: 2.0.x-final-oldhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29746Improve Tor best practices tracker2021-09-16T14:24:10ZGeorge KadianakisImprove Tor best practices trackerVarious improvements could be done to the best-practices tracker (practracker legacy/trac#29221). Here are a few from Nick's last review:
https://github.com/torproject/tor/pull/742#discussion_r262564420
https://github.com/torproject/tor...Various improvements could be done to the best-practices tracker (practracker legacy/trac#29221). Here are a few from Nick's last review:
https://github.com/torproject/tor/pull/742#discussion_r262564420
https://github.com/torproject/tor/pull/742#discussion_r262565153
~~https://github.com/torproject/tor/pull/742#discussion_r262566041~~
https://github.com/torproject/tor/pull/742#discussion_r262566501
https://github.com/torproject/tor/pull/742#discussion_r262567882
This could also be a fine starting volunteer project.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/29722Document that authorities are not measured2020-06-27T13:41:18ZjugaDocument that authorities are not measuredsbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/29705Enable Brotli compression for .onion domains2022-12-06T15:27:53ZTracEnable Brotli compression for .onion domainsTor Browser treats .onion as secure domains. Brotli compression is only enabled in Firefox on secure domains, but not for .onion domains.
Internally, Firefox controls these from the following settings:
network.http.accept-encoding
netwo...Tor Browser treats .onion as secure domains. Brotli compression is only enabled in Firefox on secure domains, but not for .onion domains.
Internally, Firefox controls these from the following settings:
network.http.accept-encoding
network.http.accept-encoding.secure
.onion is treated as the first instance (insecure) and only enable gzip and deflate. It should be handled as the second category and thus also enable Brotli compression.
Brotli compression will be beneficial to .onion service performance and reducing the data usage of Tor Browser.
PS: The requirement for Brotli to only be used on secure connections was a political decision by Google who wanted to use their new efficient compression method as a carrot to encourage HTTPS adoption.
**Trac**:
**Username**: expyuzz4wqqyqhjnhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/29630TorBrowser creates empty directory in "/tmp"2022-11-29T15:16:51ZTracTorBrowser creates empty directory in "/tmp"I'm using the latest TBB on Linux.
After I start TorBrowser, the directory is created in temporary direcrory (in my case /tmp)
drwx------ 2 user user 4096 Mar 1 12:34 Temp-41d8a42b-5545-4af5-89c2-be2502af95c7
The directory is empt...I'm using the latest TBB on Linux.
After I start TorBrowser, the directory is created in temporary direcrory (in my case /tmp)
drwx------ 2 user user 4096 Mar 1 12:34 Temp-41d8a42b-5545-4af5-89c2-be2502af95c7
The directory is empty. After I close the TBB, this directory disappears. Not sure if it's OK behavior or not.
**Trac**:
**Username**: AxelFhttps://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 Mathewson