The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-06-18T18:25:22Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4386Requesting better "too slow" warning message2021-06-18T18:25:22ZTracRequesting better "too slow" warning messageOver an 18-hour period Tor v0.2.2.34 logged 5 instances of "Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy...Over an 18-hour period Tor v0.2.2.34 logged 5 instances of "Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy." with several hundred more messages suppressed.
Since I've never seen these message before and because I've changed nothing in the 10 days since I updated to v0.2.2.34, I feel pretty confident I can blow off these warnings.
The message, though, give no indication of how far I am from being able to handle the number of pending requests. How would I know what value to configure MaxAdvertisedBandwidth with? How much more restrictive does the exit policy need to be? The problem is that I don't know if it was a single connection that couldn't be accomplished or 10,000 connections. If the former it makes sense to tweak my config; if the latter I can safely dismiss the warnings as resulting from some sort of attempted attack.
So... can we get more info in the "too slow" warning messages?
Thanks.
**Trac**:
**Username**: tmpname0901https://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/1797Restore support for building Tor in non-Unicode Windows installations2020-06-27T14:09:15ZNick MathewsonRestore support for building Tor in non-Unicode Windows installationsWhen we merged WinCE support in 8d31141ccbdbeee9589d04ea99819af7aa35193b, we reportedly broke Win98 (!?) by requiring the Unicode versions of functions that previously had used the ascii variants.
The real fix here is to use the [generi...When we merged WinCE support in 8d31141ccbdbeee9589d04ea99819af7aa35193b, we reportedly broke Win98 (!?) by requiring the Unicode versions of functions that previously had used the ascii variants.
The real fix here is to use the [generic version](http://msdn.microsoft.com/en-us/library/dd317766(v=VS.85).aspx) of each WinAPI function, plus appropriate macros to make it build either with the UNICODE preprocessor macro defined or undefined.
In other words, where previously we said in our Windows code
```
void func(const char *filename) {
HANDLE library = LoadLibrary("filename.dll");
CreateFile(filename, ...)
}
```
and now since 8d31141 we say
```
void func(const char *filename) {
HANDLE library = LoadLibraryW(L"filename.dll");
WCHAR wfilename[MAX_PATH]= {0};
mbstowcs(wfilename,filename,MAX_PATH);
CreateFileW(wfilename, ...)
}
```
we should instead say
```
void func(const char *filename) {
HANDLE library = LoadLibrary(TEXT("filename.dll"));
#ifdef UNICODE
WCHAR tfilename[MAX_PATH]= {0};
mbstowcs(tfilename,filename,MAX_PATH);
#else
const char *tfilename = filename;
#endif
CreateFile(tfilename, ...)
}
```
Thanks to mingw-san for pointing this out on bug legacy/trac#1715.Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/21347Retrying a download breaks URL bar domain isolation2023-08-28T16:05:46ZGeorg KoppenRetrying a download breaks URL bar domain isolationIf a download fails and one tries to restart it via the `about:downloads` page the resumption goes over the catch-all circuit. It would be more intuitive is we could use the circuit previously used (if it is still available).
Reported o...If a download fails and one tries to restart it via the `about:downloads` page the resumption goes over the catch-all circuit. It would be more intuitive is we could use the circuit previously used (if it is still available).
Reported on our blog: https://blog.torproject.org/blog/tor-browser-70a1-released#comment-233304https://gitlab.torproject.org/tpo/core/tor/-/issues/30780Return a distinct was_router_added_t when formatting annotations fails2021-09-16T14:23:38ZteorReturn a distinct was_router_added_t when formatting annotations failsThere's a note in dirserv_add_multiple_descriptors() that this is bad.
But no-one ever fixed it.There's a note in dirserv_add_multiple_descriptors() that this is bad.
But no-one ever fixed it.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8749Return information about the leaking application2021-06-18T18:21:28ZbastikReturn information about the leaking applicationLog from where the leaking request came.
When Tor says (in the Vidalia log):
> Potentially Dangerous Connection! - One of your applications established a connection through Tor to "!IP:PORT" using a protocol that may leak information a...Log from where the leaking request came.
When Tor says (in the Vidalia log):
> Potentially Dangerous Connection! - One of your applications established a connection through Tor to "!IP:PORT" using a protocol that may leak information about your destination. Please ensure you configure your applications to use only SOCKS4a or SOCKS5 with remote hostname resolution.
could Tor tell what port the connection was made from? Maybe the log could include SOCKS details (like username). I don't think it isn't able to identify the application.
Sure it's bad to use random stuff with Tor, but this information makes it easier to sort out applications that leak.https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/46Review UX and suggest improvements for telegram bridge bot2023-03-31T18:51:53ZdonutsReview UX and suggest improvements for telegram bridge botWe have a telegram bridge bot, and it's awesome! However at some point (i.e. when we revisit the bot and potentially integrate it with rdsys in future) UX should review and input into the following:
- The General UX/Design of the bot
- ...We have a telegram bridge bot, and it's awesome! However at some point (i.e. when we revisit the bot and potentially integrate it with rdsys in future) UX should review and input into the following:
- The General UX/Design of the bot
- How to collect user feedback about its use
- How to include (or link to) basic instructions on how to add bridges
- Improving user communication when (re)distributing cached bridges
- Integrating basic help functions/links to support articles
- If we want to localize it, and how this will work from a UI point of viewhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24573rewrite_node_address_for_bridge() should set IPv6 preferences even if there ...2020-06-27T13:54:44Zteorrewrite_node_address_for_bridge() should set IPv6 preferences even if there is no rirewrite_node_address_for_bridge() should always set IPv6 preferences, even if there is only one of ri or rs. And it should always warn about them.
This goes back to commit c213f277cde in 0.2.8.2-alpha and commit 9e9edf71f7d in 0.2.4.5-a...rewrite_node_address_for_bridge() should always set IPv6 preferences, even if there is only one of ri or rs. And it should always warn about them.
This goes back to commit c213f277cde in 0.2.8.2-alpha and commit 9e9edf71f7d in 0.2.4.5-alpha.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24572rewrite_node_address_for_bridge() doesn't set rs IPv6 addresses2020-06-27T13:54:44Zteorrewrite_node_address_for_bridge() doesn't set rs IPv6 addressesrewrite_node_address_for_bridge() should set the IPv6 address in rs, as well as setting the one in ri. We can copy the code from ri.
This goes back to commit 9e9edf71f7d in tor 0.2.4.5-alpha.
This is unlikely to have caused any bugs si...rewrite_node_address_for_bridge() should set the IPv6 address in rs, as well as setting the one in ri. We can copy the code from ri.
This goes back to commit 9e9edf71f7d in tor 0.2.4.5-alpha.
This is unlikely to have caused any bugs since at least 0.2.8, because node_get_*_or_addr() checks the ri before the rs.
But let's fix it anyway, for consistency and better logging.
(Eventually, we will rip out this code when we make ri and rs read-only.)Tor: 0.3.3.x-finalffmanceraffmancerahttps://gitlab.torproject.org/tpo/core/tor/-/issues/30474RFC: Tor should warn about expiring keys much earlier2024-01-25T12:40:39ZtoralfRFC: Tor should warn about expiring keys much earlierCurrently it starts to complain 1 day before and complaints minutely - too late for operators being afk for week(s) or so.
What's about warning once daily around 1 month ago, and hourly when 1 day left before expiration?Currently it starts to complain 1 day before and complaints minutely - too late for operators being afk for week(s) or so.
What's about warning once daily around 1 month ago, and hourly when 1 day left before expiration?https://gitlab.torproject.org/tpo/core/tor/-/issues/11325RFE: Adhere to XDB base directory specification2020-06-27T14:03:15ZTracRFE: Adhere to XDB base directory specificationAs noted by a Fedora user [1], when running Tor as a regular user it creates "$HOME/.tor" instead of "$XDG_CACHE_HOME/.tor", which is advised by the XDG specification [2] for user-specific non-essential (cached) data. Would you consider ...As noted by a Fedora user [1], when running Tor as a regular user it creates "$HOME/.tor" instead of "$XDG_CACHE_HOME/.tor", which is advised by the XDG specification [2] for user-specific non-essential (cached) data. Would you consider adhering to this specification?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=968163
[2] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
**Trac**:
**Username**: jamielinuxTor: unspecifiedhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/18866Rip mozTCPSocket out of Tor Browser2023-01-05T16:06:48ZGeorg KoppenRip mozTCPSocket out of Tor BrowserIn legacy/trac#18863 we disabled the usage of mozTCPSocket per preference. We might want to rip out that code as a defense in depth.In legacy/trac#18863 we disabled the usage of mozTCPSocket per preference. We might want to rip out that code as a defense in depth.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/23263Rip out startup GfxSanityTest entirely2022-11-30T16:50:26ZcypherpunksRip out startup GfxSanityTest entirelyMozilla understood it's a Windows-only "feature" in FF54 https://bugzilla.mozilla.org/show_bug.cgi?id=1339432, but Tor Browser doesn't need that trash.Mozilla understood it's a Windows-only "feature" in FF54 https://bugzilla.mozilla.org/show_bug.cgi?id=1339432, but Tor Browser doesn't need that trash.Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/core/tor/-/issues/20692risky duplicate code in rend_config_services()2020-06-27T13:57:47ZRoger Dingledinerisky duplicate code in rend_config_services()In rend_config_services(), we have a loop over options->RendConfigLines, and one of the things it does is:
```
if (service) { /* register the one we just finished parsing */
if (rend_service_check_private_dir(options, servi...In rend_config_services(), we have a loop over options->RendConfigLines, and one of the things it does is:
```
if (service) { /* register the one we just finished parsing */
if (rend_service_check_private_dir(options, service, 0) < 0) {
rend_service_free(service);
return -1;
}
if (validate_only)
rend_service_free(service);
else
rend_add_service(service);
}
```
Then once the loop is finished, it proceeds to call
```
if (service) {
if (rend_service_check_private_dir(options, service, 0) < 0) {
rend_service_free(service);
return -1;
}
if (validate_only) {
rend_service_free(service);
} else {
rend_add_service(service);
}
}
```
Look familiar? This duplication is going to bite us when somebody changes one part but not the other.
Found while looking at legacy/trac#20638.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5528router->address is redundant with router->addr2020-06-27T14:06:34ZRoger Dingledinerouter->address is redundant with router->addrIt used to be more, but these days address is always an IP address, and I believe it always matches router->addr.
So it's only around to save us the trouble of making a string out of ri->addr when we want one. Maybe that's not worth it ...It used to be more, but these days address is always an IP address, and I believe it always matches router->addr.
So it's only around to save us the trouble of making a string out of ri->addr when we want one. Maybe that's not worth it anymore.
Here are the places where it's set:
In router_parse_entry_from_string():
```
router->address = tor_strdup(tok->args[1]);
if (!tor_inet_aton(router->address, &in)) {
log_warn(LD_DIR,"Router address is not an IP address.");
goto err;
}
router->addr = ntohl(in.s_addr);
```
In rewrite_node_address_for_bridge():
```
ri->addr = tor_addr_to_ipv4h(&bridge->addr);
tor_free(ri->address);
ri->address = tor_dup_ip(ri->addr);
```
In router_rebuild_descriptor():
```
ri->address = tor_dup_ip(addr);
ri->nickname = tor_strdup(options->Nickname);
ri->addr = addr;
```
I think these three might be all the places.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1376router_rebuild_store() uses a needless tmp file2020-06-27T14:09:29ZNick Mathewsonrouter_rebuild_store() uses a needless tmp fileIn router_rebuild_store(), we use write_chunks_to_file() to build cached_descriptors.tmp, and if that is successful, we rename cached_descriptors.tmp to cached_descriptors.
But write_chunks_to_file() *already* uses a tmpfile to make sur...In router_rebuild_store(), we use write_chunks_to_file() to build cached_descriptors.tmp, and if that is successful, we rename cached_descriptors.tmp to cached_descriptors.
But write_chunks_to_file() *already* uses a tmpfile to make sure that it doesn't trash the file it's writing to, so we wind up with the following situation:
router_rebuild_store() calls
write_chunks_to_file(), which does:
open("cached_descriptors.tmp.tmp")
write
rename("cached_descriptors.tmp.tmp","cached_descriptors.tmp")
munmap("cached_descriptors")
rename("cached_descriptors.tmp", "cached_descriptors")
mmap("cached_descriptors")
One imaginable fix would be to have router_rebuild_store() tell write_chunks_to_file to write into cached_descriptors directly, so that it would write into c-d.tmp then rename it to c-d. That won't work so easily, though: on Windows, you're not allowed to replace a mapped file while it's still mapped.
A better fix would be to add a flag to write_chunks_to_file() so that it takes a flag that decides whether to use a tmpfile or not.
Found by grarpamp on or-talk: http://archives.seul.org/or/talk/Mar-2010/msg00173.html
This bug isn't actually hurting anything by doing an extra rename(), so it isn't urgent to fix.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/network-health/metrics/tor-check/-/issues/40016RTL support2023-12-18T08:55:11ZtorranRTL supporthttps://check.torproject.org/ doesn't have a RTL support, which is needed for languages like Arabic, Persian etc to be displayed correctly.https://check.torproject.org/ doesn't have a RTL support, which is needed for languages like Arabic, Persian etc to be displayed correctly.https://gitlab.torproject.org/tpo/core/tor/-/issues/31304Run practracker_tests.py as part of make check2021-09-16T14:23:38ZteorRun practracker_tests.py as part of make checkRunning these tests in CI will help avoid future bugs like:
The practracker_tests.py unit test file called a function by its old
name.
This change does not block legacy/trac#29746, but it should be done in 0.4.2.Running these tests in CI will help avoid future bugs like:
The practracker_tests.py unit test file called a function by its old
name.
This change does not block legacy/trac#29746, but it should be done in 0.4.2.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/22633Running ./start-tor-browser.desktop --detach --log creates two log files2022-08-03T14:52:38ZGeorg KoppenRunning ./start-tor-browser.desktop --detach --log creates two log filesAdding `--detach` explicitely creates two log files one inside the current working directory containing all the logs (which is okay) and an empty one in the parent directory (which is not okay).
This got reported on our blog: https://bl...Adding `--detach` explicitely creates two log files one inside the current working directory containing all the logs (which is okay) and an empty one in the parent directory (which is not okay).
This got reported on our blog: https://blog.torproject.org/comment/269202#comment-269157.https://gitlab.torproject.org/tpo/core/tor/-/issues/19560running tor trying to access its ed25519_signing_secret_key, log message too ...2022-07-08T15:07:58Zweasel (Peter Palfrader)running tor trying to access its ed25519_signing_secret_key, log message too loudI keep my key files away from the running tor instance.
For some reason, tor seems to want to re-open them regularly:
```
Jul 04 08:17:09.000 [warn] Could not open "/var/lib/tor/keys/ed25519_signing_secret_key": Permission denied
```
I...I keep my key files away from the running tor instance.
For some reason, tor seems to want to re-open them regularly:
```
Jul 04 08:17:09.000 [warn] Could not open "/var/lib/tor/keys/ed25519_signing_secret_key": Permission denied
```
It probably shouldn't want that.Nick MathewsonNick Mathewson