The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-10-10T16:03:27Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41859Font used for IPs in circuit display is illegible2023-10-10T16:03:27ZcypherpunksFont used for IPs in circuit display is illegibleThe font for IPs in the 'Tor Circuit' display is illegible and to small.
The old one ,TBB >12.5, was good!
Can i change it with a parameter, about:config; without changing the browser fingerprint? Display:1080p desktop monitor, OS=Window...The font for IPs in the 'Tor Circuit' display is illegible and to small.
The old one ,TBB >12.5, was good!
Can i change it with a parameter, about:config; without changing the browser fingerprint? Display:1080p desktop monitor, OS=Windows.
p.s.: I havn't had no difficulty finding the circuit display.henryhenryhttps://gitlab.torproject.org/tpo/core/arti/-/issues/925Non-fatal failures to bootstrap don't provide embedding code with any details2023-11-07T12:11:00ZetaNon-fatal failures to bootstrap don't provide embedding code with any detailsAnother weird bootstrapping failure in the wild on Android/onionmasq, this time after uncleanly shutting down an emulator and bringing it back up again:
```
06-26 16:49:11.361 2896 3087 I onionmasq: tor_dirmgr::bootstrap: 2: Looking f...Another weird bootstrapping failure in the wild on Android/onionmasq, this time after uncleanly shutting down an emulator and bringing it back up again:
```
06-26 16:49:11.361 2896 3087 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:11.592 2896 3090 I onionmasq: tor_proto::circuit::streammap: Actually got an end cell on a half-closed stream!
06-26 16:49:13.810 2896 3087 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:13.871 2896 3090 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:13.873 2896 3090 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 1s.
06-26 16:49:14.877 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:49:15.112 2896 3088 D onionmasq: onionmasq_mobile::scaffolding: AndroidScaffolding::protect() for fd 110
06-26 16:49:15.898 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:18.133 2896 3089 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:18.206 2896 3087 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:18.208 2896 3087 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 1.686s.
06-26 16:49:19.903 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:49:20.952 2896 3089 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:23.163 2896 3089 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:23.318 2896 3088 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:23.320 2896 3088 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 4.452s.
06-26 16:49:27.784 2896 3090 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:49:28.870 2896 3090 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:30.992 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:31.031 2896 3089 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:31.031 2896 3089 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 9.12s.
06-26 16:49:40.171 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:49:41.212 2896 3090 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:49:43.037 2896 3090 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:49:43.070 2896 3090 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:49:43.071 2896 3090 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 23.464s.
06-26 16:50:06.541 2896 3087 I onionmasq: tor_dirmgr::bootstrap: 1: Looking for a consensus.
06-26 16:50:07.578 2896 3089 I onionmasq: tor_dirmgr::bootstrap: 2: Looking for a consensus.
06-26 16:50:10.096 2896 3088 I onionmasq: tor_dirmgr::bootstrap: 3: Looking for a consensus.
06-26 16:50:10.142 2896 3088 W onionmasq: tor_dirmgr::bootstrap: Unable to advance downloading staten_attempts=3state=Looking for a consensus.
06-26 16:50:10.143 2896 3088 W onionmasq: tor_dirmgr: Unable to download a usable directory: error: Unable to finish bootstrapping a directory. We will restart in 50.084s.
```
The principal complaint here is, as the error seems to have been nonfatal, there's no way for the calling code (onionmasq) to know what it is; the bootstrapping code simply loops forever without ever actually returning an error. In this case, it was evidently due to the state directory being corrupted after the unclean shutdown somehow, since clearing the cache instantly fixed it (which would be a bug in its own right, if I had any actual details of the problem).
Would it be possible to provide some mechanism to allow embedding code to have more control or insight into the bootstrap retry process? This is really quite a problem in the Tor VPN use case, since this failure just manifests itself to the user as an indefinite failure to make progress (it does at least set the 'stuck' flag, but we really would prefer the actual error object).
(Yes, I know I can configure it to give up after n attempts, etc -- but then the only error received is an overly generic `CantAdvanceState`).Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41857Error message "Your browser is not supported"2023-10-23T14:01:28ZcoldboyError message "Your browser is not supported"<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Your browser is not supported**
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. I opened the tor browser 12.5
2. typed ...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
**Your browser is not supported**
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. I opened the tor browser 12.5
2. typed a url "https://www.mail.com"
3. sign in
4. get the following message:
### What is the current bug behavior?
**Your browser is not supported.
We generally support the following browsers: Google Chrome, the latest version of Safari, Internet Explorer 11 and later, Firefox from version 33, Opera from version 10. To fully utilize the functionalities of your mail.com mailbox, we recommend using the latest version of your browser.
Download Browser for free (http://www.mail.com/tools/)
The mail.com mailbox is also available with limited functionality. (https://lightmailer.mail.com/folderlist?tep=startup&enableCI=true&fcs=true)
**
### What is the expected behavior?
**The above message does not appear.**
### Environment
**Which operating system are you using? Windows 10**
**Which installation method did you use? Distribution package (exe)**
### Relevant logs and/or screenshots
![p](/uploads/6f41e68f1f2a055d6c2eb8ad1359e0d7/p.png)coldboycoldboyhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41856Onion service authorization prompt's key field does not get focus when clicked2023-08-21T18:26:26Zma1Onion service authorization prompt's key field does not get focus when clickedIf you click a different window while the onion service authorization prompt is displayed, there's no way to get its text field back in focus to enter the key without explicitly focusing the parent browser window first.
This can get ext...If you click a different window while the onion service authorization prompt is displayed, there's no way to get its text field back in focus to enter the key without explicitly focusing the parent browser window first.
This can get extremely annoying because the popup stays on top of all other windows, which makes retrieving its parent quite frustrating.
To reproduce,
1. Open http://pierovlcy7baatz7xcaccbf2kanct3hvkhcgedz4cbrmcg2ybmjalxad.onion/ and wait for the authorization prompt
2. Move the focus to a different window
3. Click back onto the prompt (which should be visible because is rendered on top of all the other windows)
4. Try to type into the "Enter your privae key for this onion service" text field
/cc @pierov , @donutsma1ma1https://gitlab.torproject.org/tpo/core/arti/-/issues/919tor-circmgr tests: panicked at 'Cannot drop a runtime in a context where bloc...2023-11-01T13:07:41ZIan Jacksoniwj@torproject.orgtor-circmgr tests: panicked at 'Cannot drop a runtime in a context where blocking is not allowed. ...'While fixing #918 this happened:
```
thread 'tokio-runtime-worker' panicked at 'Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.', /home/rustcar...While fixing #918 this happened:
```
thread 'tokio-runtime-worker' panicked at 'Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.', /home/rustcargo/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/blocking/shutdown.rs:51:21
```
But the tests completed successfully - that is, cargo was happy and the test run (`cargo check --locked --offline -p tor-circmgr --all-targets`) exited status 0.
I reran with `RUST_BACKTRACE=1` which I had foolishly omitted at first, and the problem didn't recur. So it is probably be a race, too.
I'll put this in icebox since it doesn't seem to cause any actual problem?https://gitlab.torproject.org/tpo/core/arti/-/issues/904Error handling and robustness issues with bridges and pluggable transports2023-11-14T16:43:39ZIan Jacksoniwj@torproject.orgError handling and robustness issues with bridges and pluggable transportsThis is a tracking issue for various bug reports and misbehaviours relating to bridges and PTs. The situation needs investigating and perhaps the bridge/PT code needs overhaul.This is a tracking issue for various bug reports and misbehaviours relating to bridges and PTs. The situation needs investigating and perhaps the bridge/PT code needs overhaul.Arti: Feature parity with the C implementationhttps://gitlab.torproject.org/tpo/applications/vpn/-/issues/97Consider adding a "No internet" state2024-03-27T17:28:52Zmicahmicah@torproject.orgConsider adding a "No internet" stateI was in an airport, with fairly restrictive internet. I had connected to the captive portal and logged in, so I could use the free airport wifi, and I wanted to turn on the Tor VPN to obfuscate my traffic. I launched it, pressed the con...I was in an airport, with fairly restrictive internet. I had connected to the captive portal and logged in, so I could use the free airport wifi, and I wanted to turn on the Tor VPN to obfuscate my traffic. I launched it, pressed the connect button, and it showed connected, and data transfer rates started to show.
However, nothing was loading in my browser on my device, so I went to go look at the logs, and I found that onionmasq underneath was complaining about failing to connect to the tor network, it clearly was not actually connected and was retrying, but the UI was showing I was connected and that data was being transferred.
I failed to copy the logs, and I realize that its not trivial to re-produce this, but I thought I should file an issue to get this out there.VPN pre-alpha 07donutsdonutshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41838Tor Browser opens two connection windows after launching the app by clicking ...2023-06-12T14:55:11ZdonutsTor Browser opens two connection windows after launching the app by clicking an external linkTo reproduce:
- Set Tor Browser as your default browser
- Close Tor Browser
- Click an external link (i.e. one from another application)
Tor Browser will then open two seemingly identical "Connect to Tor" windows after launching – one ...To reproduce:
- Set Tor Browser as your default browser
- Close Tor Browser
- Click an external link (i.e. one from another application)
Tor Browser will then open two seemingly identical "Connect to Tor" windows after launching – one pointing at `about:tor`, and one pointing at the external link.
Being presented with two "Connect to Tor" windows is initially confusing. I'd expect to only see one pointing at the external link in this scenario.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41831Some .tor.onion sites are not displaying the underlying V3 onion address in a...2024-03-28T18:02:50ZdonutsSome .tor.onion sites are not displaying the underlying V3 onion address in alphaIn Tor Browser 12.5 we display the corresponding V3 onion address in the circuit display when visiting a SecureDrop instance via its human-readable .tor.onion address. However I've noticed it's not working on certain .tor.onion addresses...In Tor Browser 12.5 we display the corresponding V3 onion address in the circuit display when visiting a SecureDrop instance via its human-readable .tor.onion address. However I've noticed it's not working on certain .tor.onion addresses, e.g.:
- Working as expected: https://nytimes.securedrop.tor.onion/
- Does **not** work: http://abc.au.securedrop.tor.onion/
Could the double subdomain be the cause?
(Given this is a bug with a recently developed 12.5 feature, I'd like to ~Backport the fix **after** 12.5 stable's release if possible please)henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41830Fix rogue line break in the new identity confirmation dialog2023-08-26T04:49:14ZdonutsFix rogue line break in the new identity confirmation dialogHere's what the new identity confirmation dialog currently looks like:
![new-identity-confirmation](/uploads/b815758f2197c64865f79ae01513b5cd/new-identity-confirmation.png)
The following strings should either be rolled together into a ...Here's what the new identity confirmation dialog currently looks like:
![new-identity-confirmation](/uploads/b815758f2197c64865f79ae01513b5cd/new-identity-confirmation.png)
The following strings should either be rolled together into a single sentence, or split into two separate paragraphs.
```
Tor Browser will close all windows and tabs. All website sessions will be lost.
Restart Tor Browser now to reset your identity?
```https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41819Stop providing our brand.dtd after we update the about dialog2023-09-29T06:40:27ZPier Angelo VendrameStop providing our brand.dtd after we update the about dialogIt isn't used anymore upstream: 1662ea09fa2589c689cc4e4189f6853546fd0685.
We still use it on `aboutDialog.dtd`.
We could move it there, but I think it'd be new strings to translate, so not very good, since we want to go away from legac...It isn't used anymore upstream: 1662ea09fa2589c689cc4e4189f6853546fd0685.
We still use it on `aboutDialog.dtd`.
We could move it there, but I think it'd be new strings to translate, so not very good, since we want to go away from legacy formats anyway.https://gitlab.torproject.org/tpo/core/arti/-/issues/878broken pt config can create a broken state, preventing from bootstaping after...2023-11-14T16:43:41Ztrinity-1686abroken pt config can create a broken state, preventing from bootstaping after fixing the issueWhen trying to connect to a broken bridge (in this case, PT kind not registered), arti store something in its state directory, which causes it to not try to run PTs on subsequent restarts.
How to reproduce:
- run the snowflake example (...When trying to connect to a broken bridge (in this case, PT kind not registered), arti store something in its state directory, which causes it to not try to run PTs on subsequent restarts.
How to reproduce:
- run the snowflake example (not yet merged, in !1216), it works
- comment one bridge line, break the other, for instance change the PT kind from `snowflake` to `snowflak`
- run the example, it fails as expected
- restore the file
- run the example, it fails again. Interestingly, no line from `tor_ptmgr` ever get logged.
<details><summary>shell logs</summary>
```sh
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake) [SIGINT]> cargo run --example snowflake --features pt-client
Finished dev [unoptimized + debuginfo] target(s) in 0.23s
Running `/home/trinity/dev/tor/core/arti/target/debug/examples/snowflake`
connecting to Tor...
2023-06-07T21:22:31.966319Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:22:31.971166Z INFO tor_dirmgr: Loaded a good directory from cache.
connecting to example.com...
2023-06-07T21:22:32.263816Z INFO tor_ptmgr: Got a request for transport snowflake, which is not currently running. Launching it.
2023-06-07T21:22:32.264050Z INFO tor_ptmgr::ipc: Launching pluggable transport at /sbin/snowflake-pt-client for [PtTransportName("snowflake")]
2023-06-07T21:22:32.268040Z INFO tor_ptmgr::ipc: Transport 'snowflake' uses method PtClientMethod { kind: V5, endpoint: 127.0.0.1:36513 }
2023-06-07T21:22:32.268074Z INFO tor_ptmgr::ipc: PT binary initialisation done
2023-06-07T21:22:32.268150Z INFO tor_ptmgr: Successfully launched PT for snowflake at PtClientMethod { kind: V5, endpoint: 127.0.0.1:36513 }.
2023-06-07T21:22:32.416115Z INFO tor_ptmgr::ipc: [pt snowflake-pt-client] offer created
2023-06-07T21:22:32.993817Z INFO tor_ptmgr::ipc: [pt snowflake-pt-client] broker rendezvous peer received
2023-06-07T21:22:33.192347Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:22:33.196673Z INFO tor_dirmgr: Directory is complete. attempt=1
2023-06-07T21:22:33.345261Z INFO tor_ptmgr::ipc: [pt snowflake-pt-client] connected
2023-06-07T21:22:34.774159Z INFO tor_guardmgr::guard: We have found that guard [192.x.x.x:80 via snowflake 1z…] is usable.
sending request...
reading response...
HTTP/1.1 200 OK
<redacted for conciseness>
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake)> vim examples/snowflake.rs # comment one bridge, change to pt kind to `snowflak` on the other
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake)> cargo run --example snowflake --features pt-client
Compiling arti-client v0.9.1 (/home/trinity/dev/tor/core/arti/crates/arti-client)
warning: unused variable: `bridge_1`
--> crates/arti-client/examples/snowflake.rs:30:9
|
30 | let bridge_1: BridgeConfigBuilder = BRIDGE1_LINE.parse()?;
| ^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_bridge_1`
|
= note: `#[warn(unused_variables)]` on by default
warning: `arti-client` (example "snowflake") generated 1 warning
Finished dev [unoptimized + debuginfo] target(s) in 1.68s
Running `/home/trinity/dev/tor/core/arti/target/debug/examples/snowflake`
connecting to Tor...
2023-06-07T21:22:44.695698Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:22:44.696135Z WARN tor_circmgr: Problem launching a timeout testing circuit: error: Unable to select a guard relay: No usable guards. Rejected 2/2 as down, then 0/0 as pending, then 0/0 as unsuitable to purpose, then 0/0 with filter.
2023-06-07T21:22:44.700623Z INFO tor_dirmgr: Loaded a good directory from cache.
connecting to example.com...
2023-06-07T21:22:45.927859Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:22:45.932017Z INFO tor_dirmgr: Directory is complete. attempt=1
^C⏎
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake)> vim examples/snowflake.rs # restore the file
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake) [SIGINT]> cargo run --example snowflake --features pt-client
Compiling arti-client v0.9.1 (/home/trinity/dev/tor/core/arti/crates/arti-client)
Finished dev [unoptimized + debuginfo] target(s) in 2.77s
Running `/home/trinity/dev/tor/core/arti/target/debug/examples/snowflake`
connecting to Tor...
2023-06-07T21:23:03.295584Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:23:03.297077Z WARN tor_circmgr: Problem launching a timeout testing circuit: error: Unable to select a guard relay: No usable guards. Rejected 2/2 as down, then 0/0 as pending, then 0/0 as unsuitable to purpose, then 0/0 with filter.
2023-06-07T21:23:03.300749Z INFO tor_dirmgr: Loaded a good directory from cache.
connecting to example.com...
2023-06-07T21:23:04.516865Z INFO tor_dirmgr: Marked consensus usable.
2023-06-07T21:23:04.521279Z INFO tor_dirmgr: Directory is complete. attempt=1
^C⏎
trinity@zenby ~/d/t/c/a/c/arti-client (pt-snowflake) [SIGINT]>
```
</details>
loosely related to #177Arti: Feature parity with the C implementationNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40803Cannot write to ClientOnionAuthDir when Sandbox is enabled2023-06-05T16:46:55ZanonymCannot write to ClientOnionAuthDir when Sandbox is enabled### Summary
When `tor` has the sandbox option enabled it cannot write to the `ClientOnionAuthDir` directory to store onion auth keys, e.g. when checking the "Remember this key" checkbox in Tor Browser when providing the key.
### Steps ...### Summary
When `tor` has the sandbox option enabled it cannot write to the `ClientOnionAuthDir` directory to store onion auth keys, e.g. when checking the "Remember this key" checkbox in Tor Browser when providing the key.
### Steps to reproduce:
1. Configure `tor` with `Sandbox 1`
2. Configure `tor` with `ClientOnionAuthDir /some/writable/directory`
3. Use Tor Browser to access an onion service with onion authentication
4. Check the "Remember this key" checkbox when providing the key
### What is the current bug behavior?
The onion auth prompt in Tor Browser reports "Unable to store creds for ...", and no key is written to the `ClientOnionAuthDir` directory.
### What is the expected behavior?
No errors, and the key should be written to the `ClientOnionAuthDir` directory.
### Environment
- Tor version 0.4.7.13
- Tested both on Debian Sid and inside Tails with `tor` installed via `apt`
### Relevant logs and/or screenshots
```
Jun 02 13:04:02.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /var/lib/tor/keys/n7wwn7f4jirk2yaukobahoane722lnvi7d65emwj4toas7uf5oaomdyd.auth_private.tmp (on Tor 0.4.7.13 )
Jun 02 13:00:25.000 [warn] Couldn't open "/var/lib/tor/keys/n7wwn7f4jirk2yaukobahoane722lnvi7d65emwj4toas7uf5oaomdyd.auth_private.tmp" (/var/lib/tor/keys/n7wwn7f4jirk2yaukobahoane722lnvi7d65emwj4toas7uf5oaomdyd.auth_private) for writing: Operation not permitted
Jun 02 13:00:25.000 [warn] Failed to write client auth creds file for n7wwn7f4jirk2yaukobahoane722lnvi7d65emwj4toas7uf5oaomdyd!
```
### Possible fixes
Update the sandbox rules.Tor: 0.4.9.x-freezehttps://gitlab.torproject.org/tpo/core/arti/-/issues/876MacOS build Cannot connect to Guard2024-03-07T17:40:37ZLowLandMink543MacOS build Cannot connect to Guard### Summary
Building Arti from source on Macbook running MacOS 12.6.7 fails to connects to guard as demonstrated in the log file attached below.
### Steps to reproduce:
1. Using git, pull the latest branch
2. run `cargo build --release...### Summary
Building Arti from source on Macbook running MacOS 12.6.7 fails to connects to guard as demonstrated in the log file attached below.
### Steps to reproduce:
1. Using git, pull the latest branch
2. run `cargo build --release`
3. After the build completes, run `./target/release/arti proxy`
4. After a few seconds, Warnings come up from tor_guardmgr::guard that it cannot connect to guard and it'll try again
### What is the current bug behavior?
Running Arti as a proxy fails to create a circuit do to guard connection failure.
### What is the expected behavior?
Arti connects to Guard node and completes a full circuit to use
### Environment
- Version: Cargo 1.69.0 (2023-04-12)
- Operating system: MacOS 12.6.7
- Install method: Cargo and rust from install bash script
### Relevant logs and/or screenshots:
[arti_debug_macOS_12_6_7.log](/uploads/957f8aa624e78fb5bd2291fd7261d5f5/arti_debug_macOS_12_6_7.log)
[arti_trace_macOS_12_6_7.log](/uploads/07ed66826194ddab2ca0abe8f4268199/arti_trace_macOS_12_6_7.log)
### Possible fixes:
Unknown at this timeArti: Feature parity with the C implementationAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41804The emoji set for bridge-moji includes a snowflake, which may cause confusion2023-07-26T16:02:27ZdonutsThe emoji set for bridge-moji includes a snowflake, which may cause confusionhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41789A lot amount NS_ERROR_NOT_AVAILABLE exception when the Browser Console window...2023-06-09T12:03:02ZcypherpunksA lot amount NS_ERROR_NOT_AVAILABLE exception when the Browser Console window is opening and use the NewIdentity function.A lot amount NS_ERROR_NOT_AVAILABLE exception when the Browser Console window is opening and use the NewIdentity function.
reproduce:
1. First open the Browser Console window(Ctrl+Shift+J)(this step is important, otherwise you just s...A lot amount NS_ERROR_NOT_AVAILABLE exception when the Browser Console window is opening and use the NewIdentity function.
reproduce:
1. First open the Browser Console window(Ctrl+Shift+J)(this step is important, otherwise you just see a very few errors(I don't know whether those very few errors are important or nothing)) and input the 'newidentity' to the filter box.
2. Use the NewIdentity function, you can see a few NS_ERROR_NOT_AVAILABLE errors.
3. Again use the NewIdentity function you can see obvious more NS_ERROR_NOT_AVAILABLE errors.
Environment information:12.0.6 (based on Mozilla Firefox 102.11.0esr) (32-bit) Linux Safest Level.
Error information:
``` [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDocShell.domWindow]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: resource://devtools/server/actors/targets/window-global.js :: get window :: line 422" data: no] window-global.js:422:5 ```https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41787Purple tor buttons use white text in both light and dark theme2023-10-11T21:38:25ZhenryPurple tor buttons use white text in both light and dark themeCurrent both light and dark themes use `#ffffff` white text for the purple tor buttons, like ".onion available". We should use an almost-white text in the light theme, and almost-black text color for the dark theme.
From https://gitlab....Current both light and dark themes use `#ffffff` white text for the purple tor buttons, like ".onion available". We should use an almost-white text in the light theme, and almost-black text color for the dark theme.
From https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41608#note_2895231:
> in the figma mockups the "Connect" button uses almost-white text with a light theme, and almost-black text with a dark theme.
>
> In contrast the ".onion available" urlbar button always uses white text, regardless of theme:
>
> ![onion available button in dark mode](https://gitlab.torproject.org/tpo/applications/tor-browser/uploads/dac4112fc2b8aa6d21c65bb76cda4e25/onion-available-dark-mode.png)
And the reply from @donuts
> The two variants are supposed to use `purple-60` (light theme) and `purple-30` (dark theme) for backgrounds, and the normal label color for foregrounds (e.g. page-color, I think?).
>
> For consistency, maybe we should ignore the dark theme variant for now, and we can open a separate issue to fix this everywhere (i.e. torconnect, onion-location, and this instance).henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41769TTP-02-007 WP1: Missing about: pages in shouldShowTorConnect check (Info)2023-10-19T14:31:53ZrichardTTP-02-007 WP1: Missing about: pages in shouldShowTorConnect check (Info)>>>
## Description:
It was discovered that the `about:welcome`, `about:privatebrowsing`, and `about:home` pages are not redirecting to about:tor when they are accessed by a user who has not connected to Tor yet.
While this behavior does...>>>
## Description:
It was discovered that the `about:welcome`, `about:privatebrowsing`, and `about:home` pages are not redirecting to about:tor when they are accessed by a user who has not connected to Tor yet.
While this behavior does not present any immediate security risk, it can potentially cause confusion or alarm users who may access these pages before being connected to the Tor network. To ensure consistency across all about: pages, it is recommended to deploy relevant changes.
## Affected file:
`browser/base/content/utilityOverlay.js`
## Affected code:
```javascript
if (TorConnect.shouldShowTorConnect) {
if (
url === "about:tor" ||
(url === "about:newtab" &&
Services.prefs.getBoolPref("browser.newtabpage.enabled", false))
) {
url = TorConnect.getRedirectURL(url) ;
}
}
```
In order to reproduce this issue, simply open the Tor Browser, access `about:home` and
note that the page does not perform an automated redirection to `about:tor`.
To mitigate the problem, Cure53 advises including additional checks to validate whether
the URL matches `about:welcome`, `about:privatebrowsing` or about:home. If a match is
found, the page should be redirected to `about:tor`.
>>>henryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41768TTP-02-005 WP1: Redirect to about:blank hides the new Tor Circuit button (Info)2023-10-19T14:33:23ZrichardTTP-02-005 WP1: Redirect to about:blank hides the new Tor Circuit button (Info)>>>
## Description:
It is possible to hide the **Tor Circuit** button from the address bar for a given tab by listening to the `onbeforeunload` event and redirecting the page to `about:blank` when the event is triggered.
If a user attem...>>>
## Description:
It is possible to hide the **Tor Circuit** button from the address bar for a given tab by listening to the `onbeforeunload` event and redirecting the page to `about:blank` when the event is triggered.
If a user attempts to reset their identity by clicking on the **New Tor circuit for this site** option, the navigation can be hijacked by the attacker's script. A blank page will be displayed as a consequence. If the user attempts to navigate back to the previous page using the Back button, the **Tor Circuit** button will not be displayed in the address bar.
Similarly to [TTP-02-002](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41767), this issue was found not to pose any immediate security risk and is included as **Info** only.
## PoC:
```html
<script>
let status;
onbeforeunload = () => {
status = true;
}
let timer = setInterval(() => {
if (status) {
status = false;
clearInterval (timer) ;
location = "about:blank";
}
}, 1);
</script>
```
# Steps to reproduce:
1. Open the Tor Browser and connect to it.
2. Save the PoC above as an HTML file and open it in the browser.
3. Click on the **Tor Circuit** button and then on the **New Tor circuit for this** site option.
4. The page will be redirected to `about:blank`.
5. Click on the **Back** option and observe that the **Tor Circuit button** is hidden for this page.
To mitigate this issue, Cure53 advises applying the same mitigation as specified in the [TTP-02-002](https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41767) ticket. Given these issues seem to be related and they might share the same root cause, it is recommended to consider and address them together.
>>>https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41767TTP-02-002 WP1: Redirect prevents switching to new Tor Circuit (Info)2024-03-12T12:05:59ZrichardTTP-02-002 WP1: Redirect prevents switching to new Tor Circuit (Info)>>>
## Description:
It was discovered that navigation initiated through the new Tor Circuit feature can be hijacked. This can be accomplished by redirecting the current website to a cached page immediately after the Tor Circuit switch st...>>>
## Description:
It was discovered that navigation initiated through the new Tor Circuit feature can be hijacked. This can be accomplished by redirecting the current website to a cached page immediately after the Tor Circuit switch starts. As a result, the attacker-initiated navigation occurs before the Tor Circuit's browser-initiated navigation and, subsequently, the next step is canceled.
An attacker could exploit this vulnerability to prevent users from switching circuits while browsing a malicious webpage. Although this prevents the user from changing their Tor Circuit, it was concluded that this does not pose any immediate security risk, and as such, the severity mark was appropriately set at Info.
## PoC:
```html
<?php header ("cache-control: max-age=604800") ;
header ("Age: 100"); 2>
<html>
<script>
let status = false;
onbeforeunload = () => {
status = true;
}
let timer = setInterval(() => {
if (status) {
status = false;
clearInterval (timer);
location.href = location.href;
}
}, 1);
</script>
</html>
```
## Steps to reproduce:
1. Open the Tor Browser and connect to it.
2. Save the PoC above as a PHP file and serve it through a PHP server.
3. Access the file a few times through the Tor Browser to make sure it gets cached by the browser.
4. Click on the **Tor Circuit** button and then on the** New Tor circuit for this site** option.
5. The page will quickly be reloaded but the Circuit will remain the same.
To mitigate this issue, Cure53 advises forcing the navigation initiated by the new **Tor Circuit** feature to be completed. Cancellation of a user-initiated navigation is ill-advised in this scenario. However, during the testing phase, the team was unable to pinpoint the specific code responsible for this issue. As a result, the mitigation advice provided is currently incomplete.
>>>