The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:48:01Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33670Fix erroneous spaces in circuitmux_ewma.c2020-06-27T13:48:01ZNeel Chauhanneel@neelc.orgFix erroneous spaces in circuitmux_ewma.cNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33632List ed25519 fingerprints on the command line2021-04-18T13:55:23ZteorList ed25519 fingerprints on the command lineFor RSA keys, tor has `tor --list-fingerprint`.
We could add a feature to tor so it accepts a key type argument:
* `tor --list-fingerprint rsa`
* `tor --list-fingerprint ed25519`
And defaults to RSA (for now).
Related to legacy/trac#30...For RSA keys, tor has `tor --list-fingerprint`.
We could add a feature to tor so it accepts a key type argument:
* `tor --list-fingerprint rsa`
* `tor --list-fingerprint ed25519`
And defaults to RSA (for now).
Related to legacy/trac#30642, which adds an `ed25519-fingerprint` file.https://gitlab.torproject.org/tpo/web/lego/-/issues/7We need robots.txt in all our website2022-07-01T05:22:37ZHiroWe need robots.txt in all our websiteSee: https://trac.torproject.org/projects/tor/ticket/33496See: https://trac.torproject.org/projects/tor/ticket/33496https://gitlab.torproject.org/tpo/core/chutney/-/issues/33609Check that onion services have successfully posted descriptors before verifying2020-07-07T15:12:56ZteorCheck that onion services have successfully posted descriptors before verifyingBefore verifying, chutney checks that:
* each relay descriptor is cached at each node
* each relay is in a consensus, cached at each node
* each relay is in a microdesc consensus, cached at each node
* each bridge descriptor is cached at...Before verifying, chutney checks that:
* each relay descriptor is cached at each node
* each relay is in a consensus, cached at each node
* each relay is in a microdesc consensus, cached at each node
* each bridge descriptor is cached at each bridge client
We have other tickets for checking:
* microdescriptors
* cached bridge descriptors at the bridge authority
* the bridge networkstatus
That just leaves onion services.
Onion services are tricky, because they post to some HSDirs in the network, but not all. And those HSDirs don't cache the onion service descriptors in a file.
So here is one possible design for this feature:
* check each onion service log for a successful descriptor post to at least one HSDir
* check v2 and v3 onion services
* call it an extra 200% "bootstrap" stage (because it's a sender log check, not a receiver cached file check)
* require 200% bootstrap for onion servicesNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/33598chutney does not fail on some SOCKS errors2022-02-07T19:32:13Zteorchutney does not fail on some SOCKS errorsWhen tor can't make a connection, and sends back a SOCKS error, chutney keeps on rapidly sending SOCKS requests. Instead, chutney should fail.
I think we introduced this bug when we started using asyncore.
I have worked around the bug...When tor can't make a connection, and sends back a SOCKS error, chutney keeps on rapidly sending SOCKS requests. Instead, chutney should fail.
I think we introduced this bug when we started using asyncore.
I have worked around the bug using a 5 second asyncore timeout, but we should come up with a permanent fix.
I think nickm might be able to help with this issue, because he wrote that code.https://gitlab.torproject.org/tpo/core/chutney/-/issues/33595Stop waiting for unchecked directory info2020-06-27T13:18:32ZteorStop waiting for unchecked directory infoOnce we've fixed legacy/trac#33428 (microdescs), legacy/trac#33582 (bridges), and legacy/trac#33609 (onion services), we might be able to remove WAIT_FOR_UNCHECKED_DIR_INFO in chutney's TorNet.py.
But we might still need to wait for:
* ...Once we've fixed legacy/trac#33428 (microdescs), legacy/trac#33582 (bridges), and legacy/trac#33609 (onion services), we might be able to remove WAIT_FOR_UNCHECKED_DIR_INFO in chutney's TorNet.py.
But we might still need to wait for:
* internal tor state changes, in response to downloading descriptors.
So we will need to make this change, then test it on Tor 0.3.5 and master.https://gitlab.torproject.org/tpo/core/tor/-/issues/33555Space out the line.key/line.value in test_policy_summary_helper_family_flags()2020-06-27T13:48:05ZNeel Chauhanneel@neelc.orgSpace out the line.key/line.value in test_policy_summary_helper_family_flags()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/33472Document that bwauths should checkout stable versions when installing sbws fr...2020-07-14T16:44:07ZjugaDocument that bwauths should checkout stable versions when installing sbws from giti think that if some bwauths are installing sbws from git, they should checkout a tag or a bugfix branch. We might want to have a bwauth to run a development branch, but it should be only one.i think that if some bwauths are installing sbws from git, they should checkout a tag or a bugfix branch. We might want to have a bwauth to run a development branch, but it should be only one.sbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/tpo/core/tor/-/issues/33463Correct spacing in dns_launch_correctness_checks()2020-06-27T13:48:07ZNeel Chauhanneel@neelc.orgCorrect spacing in dns_launch_correctness_checks()Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33371Build only with required libevent2 libraries2023-09-15T11:40:49ZNick MathewsonBuild only with required libevent2 librariesWe should only need libevent_core and libevent_extra.We should only need libevent_core and libevent_extra.https://gitlab.torproject.org/tpo/core/tor/-/issues/33339Add script to check ordering of options in manpage2021-07-22T16:18:20ZTaylor YuAdd script to check ordering of options in manpageAdd a script to check the ordering of option names within a manpage section.
This will be an initial version that doesn't restrict section names and doesn't recognize pragma comments that mark intentionally out-of-order option names.
l...Add a script to check the ordering of option names within a manpage section.
This will be an initial version that doesn't restrict section names and doesn't recognize pragma comments that mark intentionally out-of-order option names.
legacy/trac#32621 will contain a more fully-functional script suitable for automation.Tor: 0.4.3.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/33298HTTP onion sites do not give a popup warning when submitting form data to non...2023-06-11T04:21:10ZrichardHTTP onion sites do not give a popup warning when submitting form data to non-onion HTTP sitesIn vanilla firefox, HTTPS site with a form that submits to an HTTP site will put up a pop-up box warning the user they are about to send their data unencrypted across the network. Tor Browser follows this behaviour, but it also needs to ...In vanilla firefox, HTTPS site with a form that submits to an HTTP site will put up a pop-up box warning the user they are about to send their data unencrypted across the network. Tor Browser follows this behaviour, but it also needs to do so when submitting data from an HTTP onionsite to a vanilla HTTP site.ma1ma1https://gitlab.torproject.org/tpo/core/tor/-/issues/33275Tor Manual: Alphabetize Remaining Tor Manual2021-07-22T16:18:20ZTracTor Manual: Alphabetize Remaining Tor ManualAlphabetically sort the options in the following sections:
- DENIAL OF SERVICE MITIGATION OPTIONS
- DIRECTORY AUTHORITY SERVER OPTIONS
- HIDDEN SERVICE OPTIONS
- TESTING NETWORK OPTIONS
**Trac**:
**Username**: swatiAlphabetically sort the options in the following sections:
- DENIAL OF SERVICE MITIGATION OPTIONS
- DIRECTORY AUTHORITY SERVER OPTIONS
- HIDDEN SERVICE OPTIONS
- TESTING NETWORK OPTIONS
**Trac**:
**Username**: swatiTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33188Tor Manual: Alphabetize Server and Directory Server Options2021-07-22T16:18:20ZTracTor Manual: Alphabetize Server and Directory Server OptionsAlphabetize options in the Server Options and Directory Server Options
**Trac**:
**Username**: swatiAlphabetize options in the Server Options and Directory Server Options
**Trac**:
**Username**: swatihttps://gitlab.torproject.org/tpo/web/tpo/-/issues/57add mastodon link to https://www.torproject.org/contact/2021-08-23T16:33:41Zemmapeeladd mastodon link to https://www.torproject.org/contact/reported by kushal:
we should update our contact page with the very active mastodon accountreported by kushal:
we should update our contact page with the very active mastodon accounthttps://gitlab.torproject.org/tpo/web/manual/-/issues/25Sidebar doesn't display all the topics2021-12-13T18:28:34ZGusSidebar doesn't display all the topicsYou need to scroll down the page to see "Mobile Tor" itemYou need to scroll down the page to see "Mobile Tor" itemhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33156DoS subsystem should compare IPv6 /642022-10-11T23:41:45ZteorDoS subsystem should compare IPv6 /64s7r writes:
> Our internal DoS defense subsystem should also treat prefixes instead of
> addresses, because right now with a client with a /64 public IPv6 prefix
> assigned to it I could hammer via IPv6 guards without triggering the DoS...s7r writes:
> Our internal DoS defense subsystem should also treat prefixes instead of
> addresses, because right now with a client with a /64 public IPv6 prefix
> assigned to it I could hammer via IPv6 guards without triggering the DoS
> defense.
https://lists.torproject.org/pipermail/tor-dev/2020-February/014144.html
We could make this change by:
* only putting the first /64 of each IPv6 address in the filter list, and
* only checking the first /64 of each new IPv6 connectionhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33124Controller circuits don't pass the SOCKS request address in relay begin cells2021-07-09T17:22:51ZoparaController circuits don't pass the SOCKS request address in relay begin cellsIf a stream is attached to a circuit with purpose `CIRCUIT_PURPOSE_CONTROLLER`, a RELAY_BEGIN cell will be sent with an empty address. This is because of a bug in `connection_ap_handshake_send_begin()`.
```
tor_snprintf(payload,RELAY_PA...If a stream is attached to a circuit with purpose `CIRCUIT_PURPOSE_CONTROLLER`, a RELAY_BEGIN cell will be sent with an empty address. This is because of a bug in `connection_ap_handshake_send_begin()`.
```
tor_snprintf(payload,RELAY_PAYLOAD_SIZE, "%s:%d",
(circ->base_.purpose == CIRCUIT_PURPOSE_C_GENERAL) ?
ap_conn->socks_request->address : "",
ap_conn->socks_request->port);
```
The function seems to assume that if it's not a general purpose circuit, then it is a rendezvous circuit. This was added in [commit 5b6099e8](https://github.com/torproject/tor/commit/5b6099e8#diff-0798d3d17392dc5c15f3f58a5fc6b29aR946-R957).
There is a similar error in a logging statement in `link_apconn_to_circ()` which logs that a controller circuit is to a "hidden service", even if the circuit is actually to an exit.
```
log_info(LD_APP, "Looks like completed circuit to %s %s allow "
"optimistic data for connection to %s",
circ->base_.purpose == CIRCUIT_PURPOSE_C_GENERAL ?
/* node_describe() does the right thing if exitnode is NULL */
safe_str_client(node_describe(exitnode)) :
"hidden service",
apconn->may_use_optimistic_data ? "does" : "doesn't",
safe_str_client(apconn->socks_request->address));
```
And another example is in `connection_ap_expire_beginning()` which logs the warning:
```
[warn] connection_ap_expire_beginning(): Bug: circuit->purpose == CIRCUIT_PURPOSE_C_GENERAL failed. The purpose on the circuit was Circuit made by controller; it was in state open, path_state new. (on Tor 0.4.2.5 )
```
The relay which receives the RELAY_BEGIN cell will then make a dns request for the address "". Libevent will eventually give up after 3 tries (`global_timeout.tv_sec = 5` seconds per try).
```
Feb 01 01:11:41.369 [info] launch_resolve(): Launching eventdns request for ""
Feb 01 01:11:41.369 [info] evdns_log_cb(): eventdns: Resolve requested.
...
Feb 01 01:11:56.378 [info] eventdns: Giving up on request 0x5565c825ac80; tx_count==3
```
Back at the tor client, the streams detach (reason=timeout, remote_reason=none) after some time, then the controller circuits close a few seconds later (a total of 25 seconds after the streams were first attached) with:
```
[info] circuit_mark_for_close_(): Circuit 2262666673 (id: 15) marked for close at src/core/or/circuituse.c:1507 (orig reason: 9, new reason: 0)
```
Finally a SOCKS error code `0x5b` is returned to the application after some long amount of time.
In summary, the main problems are:
(1) Tor has checks for only `CIRCUIT_PURPOSE_C_GENERAL` when it should be checking for other circuit purposes like `CIRCUIT_PURPOSE_CONTROLLER`.
(2) Tor attempts to resolve the address of an empty string.
(3) (Maybe?) It takes a long time before the application is notified that the SOCKS connection was unsuccessful.
Thanks to arma for help debugging this.Neel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33086Support brotli compression for directory requests2022-06-17T19:03:32ZNick MathewsonSupport brotli compression for directory requestsBrotli seems to outperform zstd in compression, and claims performance comparable to deflate. We should investigate using it for directory requests.Brotli seems to outperform zstd in compression, and claims performance comparable to deflate. We should investigate using it for directory requests.rl1987rl1987https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/33009sbws bandwidth scans should require a minimum exit bandwidth2022-02-11T09:53:47Zteorsbws bandwidth scans should require a minimum exit bandwidthWhen sbws is constructing a two-hop measurement circuit to run a test, it tries to pick an exit that has at least twice the consensus weight of the current relay-under-test:
https://github.com/torproject/sbws/blob/master/sbws/core/scanne...When sbws is constructing a two-hop measurement circuit to run a test, it tries to pick an exit that has at least twice the consensus weight of the current relay-under-test:
https://github.com/torproject/sbws/blob/master/sbws/core/scanner.py#L216
So this means that in this case, sbws would have picked any exit that was not a BadExit, has an acceptable ExitPolicy, and has a consensus weight of at least, well, 2. That's not a lot.
As it turns out, something like 10% of exits have under a 600Kbyte/sec advertised bandwidth. So it seems pretty easy from this weight=1 bootstrap scenario to get paired with an exit that will give poor test results.
Perhaps bwauth path selection should also choose a testing pair from exits/relays with a certain absolute minimum of weight or advertised bandwidth?
Reported by Jimmy on tor-relays:
https://lists.torproject.org/pipermail/tor-relays/2020-January/018027.htmlsbws: 1.1.x-finalGeorg KoppenGeorg Koppen