The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-09-01T22:30:17Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41184[Crash] Changing wallpaper on android 12 closes browser2022-09-01T22:30:17Zdoalupnetwork[Crash] Changing wallpaper on android 12 closes browserOperating System: Lineageos 19.1 (Android 12L)
Tor browser version: 11.5
Tor Browser Security Level: Independent (Any)
Step by step of how to the reproduce the issue:
1. Open brwowser
2. Connect to tor
3. Open any website
4. Go home ...Operating System: Lineageos 19.1 (Android 12L)
Tor browser version: 11.5
Tor Browser Security Level: Independent (Any)
Step by step of how to the reproduce the issue:
1. Open brwowser
2. Connect to tor
3. Open any website
4. Go home and change the wallpaper
5. (on my device, I have to lock and unlock the device for material you to change the device theme)
6. Once the device theme is changed, open the browser again
7. You can see the browser is now at the starting position (asking you to connect to tor network), same behaviour as pressing the close button
I can't reproduce this on mozilla firefox for android or any of its forks, seems to be a tor browser only bug
I've also tested on a OneUi 2.5 (android 10) device, doesn't crash there
Edit: while testing to reproduce the bug on my other(android 10) device, I found that changing device theme between dark and light also closes the browser (same behaviour), this also happens on my android 12L devicehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41065navigator.storage "best effort" + "persistent" leak partitionSize/totalSpace ...2023-11-20T16:02:58ZThorinnavigator.storage "best effort" + "persistent" leak partitionSize/totalSpace entropyEdit: upstream [1781277](https://bugzilla.mozilla.org/show_bug.cgi?id=1781277)
AFAICT, in FF96 or lower, storage quota was always `2,147,483,648`. Note PB windows and normal windows are always the same. Also note, I'm not interested in ...Edit: upstream [1781277](https://bugzilla.mozilla.org/show_bug.cgi?id=1781277)
AFAICT, in FF96 or lower, storage quota was always `2,147,483,648`. Note PB windows and normal windows are always the same. Also note, I'm not interested in slight variations due to storage usage, we can cancel that noise out.
In FF97 (I'll see if I can find the bugzilla) it seems to have become dependent on disk space (and/or disk size), which adds some entropy. Here are my notes
```
// 2147483648 : FF57-96 Windows (and TB ESRs) / Android / Win 10 VM FF60-96
// FF97+ : note opusforlife, bashonly are user names who submitted data (so I can track it)
10737418240 : numerous windows + linux users with lots of disk size, Android Fabrizio 100gb spare from 128gb
5778733465 : Android10 opusforlife 12gb spare from 64gb (Mull)
5641604300 : Android Fabrizio 49gb spare from 64gb
5512729395 : Android9 Thorin 44gb spare from 64gb
5301081292 : Android bashonly 40gb spare from 64gb
5256596684 : Win 10 VM 33gb spare from 52gb
2934867968 : Debian XCFE 2glops 650gb spare from 1TB
1521166745 : Ubuntu VM Fabrizio with 15GB of storage
1177328025 : Android aleyvo 1.5gb spare from 16gb
// other: who cares if they match
// brave: 2147483648 (same in incognito and Tor window)
// opera: 310418104 normal
// opera: 521917312 private
// chrome: 1200238045593 normal
// chrome: 33076376370 normal android
// chrome: 485041940 incognito
// chrome: 204974075 incognito android
```
So TB102+ will reflect this - so far I have 3 results. You can test [here](https://arkenfox.github.io/TZP/tests/engine.html), just scroll down to the bottom, just above the `ERRORS` section, or alternatively, just run this in the browser console, and then expand the promise
```js
console.log(navigator.storage.estimate())
```
So what would be nice to know is how deep this rabbit hole goes... and to look at the code changes in FF97+, which will probably tell us the answer. Once we know how bad it is, we can propose RFP handle it upstream
@richard `Fingerprinting` label please .. also alone feel free to report their quota + OS + free disk size if applicable
---
EDIT
- FF97 [1735713](https://bugzilla.mozilla.org/show_bug.cgi?id=1735713) Revamp temporary storage limits
- FF97 [1593646](https://bugzilla.mozilla.org/show_bug.cgi?id=1593646) StorageManager.estimate is misleading when...
digging into it now: https://bugzilla.mozilla.org/show_bug.cgi?id=1735713#c0
> Our temporary storage limits are still based on free disk space which is now in a conflict with the storage spec. We should base our temporary storage limits on total dSponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41062Assume internet is online when connected to Tor2022-11-30T18:21:48ZcypherpunksAssume internet is online when connected to TorIn Connection settings, where Internet and Tor statuses are shown, Tor might be displayed as connected while Internet as unknown. That's weird - it implies working Inet.In Connection settings, where Internet and Tor statuses are shown, Tor might be displayed as connected while Internet as unknown. That's weird - it implies working Inet.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41056Tor Browser generates huge memory (RAM) usage when watching videos2022-11-08T20:33:41ZSamdneyTor Browser generates huge memory (RAM) usage when watching videos### Summary
Tor browser generates huge RAM usage. Noticed this issue, because since the newest update my system frozen because of total usage of available memory (RAM + swap = 64GB). After investigation it turned out that tor browser gen...### Summary
Tor browser generates huge RAM usage. Noticed this issue, because since the newest update my system frozen because of total usage of available memory (RAM + swap = 64GB). After investigation it turned out that tor browser generates this, when watching YouTube videos. With each new video started in a tab it uses 5 - 12 GB on the top! to the already used memory, which is a totally different behaviour to previous versions of tor browser (because of other applications, sometimes, I keep an eye on memory usage ;). Just with closing the tab, the memory get free and available again.
### Steps to reproduce:
1. Starting YouTube in a browser tab, and watching memory (RAM and swap) usage. You will see a bunch of GB getting used.
2. After finishing the video, start an additional video, within the same tab, and the memory will grow by an additional bunch of GB.
3. When closing the tab, the memory will be free again.
Edit: I just noticed that not all videos raises the memory, or in some cases the raising memory not directly starts with starting the video, instead just after some minutes it suddendly raises the memory by several GB within a minute.
### What is the current bug behavior?
Heavily growing memory usage.
### What is the expected behavior?
Only slowly growing. In the past, I have never experienced a usage of more than 50% of my available memory of 64GB, even after I had tor browser and a lot of videos running for a lot of days or even weeks.
=> That's a very critical bug, since it can lead fastly to a freezing system for people with small memory.
### Environment
Arch linux - Up to date.
Tor browser dowloaded years ago from torproject website.
This bug is related to the newest tor browser release from 14. July 2022: Tor Browser 11.5
### Relevant logs and/or screenshots
Couldn't find any relevant information.Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/40020Not found error2022-07-25T03:24:47ZPulkit ChandelNot found errorFileNotFoundError: [Errno 2] No such file or directory: '/home/eict/chutney/net/nodes.1657278323/006r/torrc'
</pre>
Why am I Getting this error. The file 006r was never made when I executed tor chutney command, then why is it looking for...FileNotFoundError: [Errno 2] No such file or directory: '/home/eict/chutney/net/nodes.1657278323/006r/torrc'
</pre>
Why am I Getting this error. The file 006r was never made when I executed tor chutney command, then why is it looking for it.And how to solve ithttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41046java.lang.NullPointerException in org.mozilla.fenix.home.HomeFragment.adjustH...2022-10-06T01:10:11Zrichardjava.lang.NullPointerException in org.mozilla.fenix.home.HomeFragment.adjustHomeFragmentViewThis is our biggest crash bucket at the moment in 11.0.15
stacktrace:
```
java.lang.NullPointerException:
at org.mozilla.fenix.home.HomeFragment.adjustHomeFragmentView (HomeFragment.kt:1)
at org.mozilla.fenix.home.HomeFragment$onC...This is our biggest crash bucket at the moment in 11.0.15
stacktrace:
```
java.lang.NullPointerException:
at org.mozilla.fenix.home.HomeFragment.adjustHomeFragmentView (HomeFragment.kt:1)
at org.mozilla.fenix.home.HomeFragment$onCreateView$1.invoke (HomeFragment.kt:5)
at org.mozilla.fenix.home.CurrentMode.onTorConnected (Mode.kt:1)
at org.mozilla.fenix.tor.TorController.onTorConnected (TorController.kt:4)
at org.mozilla.fenix.tor.TorController$persistentBroadcastReceiver$1.onReceive (TorController.kt:26)
at androidx.localbroadcastmanager.content.LocalBroadcastManager$1.handleMessage (LocalBroadcastManager.java:15)
at android.os.Handler.dispatchMessage (Handler.java:106)
at android.os.Looper.loopOnce (Looper.java:226)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8663)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:567)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
```https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41045Phantom update notification in Tor Browser Alpha2022-11-30T15:26:53ZninaPhantom update notification in Tor Browser Alpha<!--
* Use this issue template for reporting a new bug.
-->
### Summary
After opening TB Alpha the browser informed about the existing update. However, failed to update automatically. So I deleted existing TB Alpha an re-installed from ...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
After opening TB Alpha the browser informed about the existing update. However, failed to update automatically. So I deleted existing TB Alpha an re-installed from the TP web site. However, I started browser anew I got an update reminder again. Then I checked for updates in Settings. And it said the browser was up to date. The update notification dissipated
But after I restart the update notification showed up again. And it did not disappeared after checking for updates.
I restarted again and got the red screen. Then I restarted again and got new update notification
### Steps to reproduce:
**How one can reproduce the issue - this is very important.**
1. Open TB Alpha
### Environment
MacOS Monterey
TB Alpha 11.5a13
### Relevant logs and/or screenshots
![Screenshot_2022-07-06_at_11.48.10](/uploads/22295fbbcb7521a4c60026b0b6c21e5a/Screenshot_2022-07-06_at_11.48.10.png)
![Screenshot_2022-07-06_at_11.38.20](/uploads/572e815c141108d2e7f04b85b1031039/Screenshot_2022-07-06_at_11.38.20.png)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41042some dynamic images display poorly without access to HTML5 canvas image data2023-01-05T17:48:36ZJeremy Benthamsome dynamic images display poorly without access to HTML5 canvas image data<!--
* Use this issue template for reporting a new bug.
-->
### Summary
Certain dynamic images for which HTML5 canvas image data are requested do not render correctly without explicitly agreeing to share HTML5 canvas image data. For ex...<!--
* Use this issue template for reporting a new bug.
-->
### Summary
Certain dynamic images for which HTML5 canvas image data are requested do not render correctly without explicitly agreeing to share HTML5 canvas image data. For example, maps provided by `mapbox.com` seem to have this problem by default, even though there is no indication of a problem when attempting to load these images using ordinary Firefox. Loading [a page that embeds a resource from `mapbox.com`](https://www.wunderground.com/wundermap) in Tor Browser yields an image that looks like this:
![mapbox-random](/uploads/46f4d583549a98f77a8bbd165843377c/mapbox-random.png)
**EXHIBIT A**
The stripey pattern in Exhibit A appears to result from the random canvas data that Tor Browser is configured to provide by default. The randomisation can be removed, although the resulting images are still broken. When the user sets `privacy.resistFingerprinting.randomDataOnCanvasExtract` to **false**, the result is that white rectangles appear instead of stripey patterns:
![mapbox-norandom](/uploads/c8833599d762985622a99f6f4cbf0554/mapbox-norandom.png)
**EXHIBIT B**
Please note that such sites request HTML5 canvas image data via an icon in the URL bar. If a user opens the dialog and chooses to explicitly **allow** access to HTML5 canvas image data to the site, then Tor Browser will display the embedded content correctly, like this:
![mapbox-dangerous](/uploads/3b151b5b9c7cb86bb20e3b0dcbf0cb00/mapbox-dangerous.png)
**EXHIBIT C**
Note that vanilla Firefox always renders correctly (as in Exhibit C) and does not ask for HTML5 canvas image data. Suggest it is reasonable to conflude that vanilla Firefox allows (dangerous) access to HTML5 canvas image data by default.
**Expected behaviour**
I am not sure why canvas image data are actually necessary to render this image correctly; I would hope that there would be a way to provide something generic to the requesting site, revealing nothing while allowing such images to render correctly.
**Environment**
The behaviour described in this bug report was observed in both Tor Browser 11.0.14 and Tor Browser 11.0.15. The dangerous behaviour in vanilla Firefox was observed in 91.11.0esr (Debian).https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40054Relays get sometimes the overloaded notification bar without timestamp2022-10-17T10:11:13ZGeorg KoppenRelays get sometimes the overloaded notification bar without timestampI saw it last week and just again: sometimes relays get the overloaded notification bar *without* timestamp included:![najdorf_2022-06-13-07-36-00_overload](/uploads/e20dbfe4e4f21a95ef1a4c837b406828/najdorf_2022-06-13-07-36-00_overload.p...I saw it last week and just again: sometimes relays get the overloaded notification bar *without* timestamp included:![najdorf_2022-06-13-07-36-00_overload](/uploads/e20dbfe4e4f21a95ef1a4c837b406828/najdorf_2022-06-13-07-36-00_overload.png)
but they are not shown as overloaded otherwise:
![najdorf_2022-06-13-07-36-00_no_overload](/uploads/81d6b602fdcc947a1910891aa946e82f/najdorf_2022-06-13-07-36-00_no_overload.png)
In fact when that state kicks in it seems that *all* non-overloaded relays get tagged that way. The actually overloaded ones are both shown as overloaded and the notification bar contains a timestamp, too.https://gitlab.torproject.org/tpo/core/tor/-/issues/40624not helpful warning Sudden increase in circuit RTT (1557538 vs 91), likely du...2022-10-24T20:48:03Ztoralfnot helpful warning Sudden increase in circuit RTT (1557538 vs 91), likely due to clock jump.I've two relays running at a same dedicated hardware under a stable hardened Gentoo:
```
$ tor --version
Tor version 0.4.8.0-alpha-dev (git-b733f9d6ace63c71).
Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1o, Zlib 1.2....I've two relays running at a same dedicated hardware under a stable hardened Gentoo:
```
$ tor --version
Tor version 0.4.8.0-alpha-dev (git-b733f9d6ace63c71).
Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1o, Zlib 1.2.12, Liblzma 5.2.5, Libzstd 1.5.2 and Glibc 2.34 as libc.
Tor compiled with GCC version 11.3.0
```
One of them suddenly spewed at 04:12 UTC
```
Sudden increase in circuit RTT (1557538 vs 91), likely due to clock jump.
```
following by
```
Our clock has been stalled for the entire lifetime of a circuit. Performance may be sub-optimal. [164 similar message(s) suppressed in last 360 seconds]
```
every 5 or 6 minutes since that (the time period oscillates between 300 and 360 seconds of that message).
The other relay with same version at the same ip is running flawlessly.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41026Tor Browser doesn't respect user set changes to Colors and Appearance2023-11-02T09:44:41Zchampionquizzerchampionquizzer@torproject.orgTor Browser doesn't respect user set changes to Colors and AppearanceA user has reported to the [forum](https://forum.torproject.net/t/color-settings-in-tor-11-0-14/3609) and also to frontdesk:
> I installed Tor 11.0.14 en(us) version on my Windows 7 Home Premium 64-bit. Because of my bad eyes I use hig...A user has reported to the [forum](https://forum.torproject.net/t/color-settings-in-tor-11-0-14/3609) and also to frontdesk:
> I installed Tor 11.0.14 en(us) version on my Windows 7 Home Premium 64-bit. Because of my bad eyes I use high contrast theme on my computer with yellow text on black background. In Tor browser I immediately went to Settings > Colors and set Text to yellow, Background to black, checked Use system colors and selected Always. The same setting I use successfully in Firefox. But in Tor browser nothing happened.
If there is Use system colors checked or unckecked, if there is selected Always or Never, displayed pages don’t change their backgroud nor text colors. Only menus and Settings tab display their colors according to selected Windows theme (text and background colors). Displayed internet pages ignore any color settings made in Tor browser Settings tab.This is completely different behaviour from original Firefox browser.
What is the problem here?https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41025Requests from local files go over catch-all circuit2023-04-07T13:06:31ZcypherpunksRequests from local files go over catch-all circuitIf I open local file linking or fetching something remote in Tor Browser, the circuit display window displays "--unknown" as destination and requests presumably go over catch-all circuit.If I open local file linking or fetching something remote in Tor Browser, the circuit display window displays "--unknown" as destination and requests presumably go over catch-all circuit.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41019When using system tor, the about:tor page tells me it is not connected, but i...2022-11-30T16:33:46ZemmapeelWhen using system tor, the about:tor page tells me it is not connected, but it is!### Summary
When using my system tor, the first page was saying it was not connected, but it was!
That made me lose some time.
### Steps to reproduce:
1. Start Tails
2. Download last Tor Browser from https://www.torproject.org/downloa...### Summary
When using my system tor, the first page was saying it was not connected, but it was!
That made me lose some time.
### Steps to reproduce:
1. Start Tails
2. Download last Tor Browser from https://www.torproject.org/download/
3. Edit the start-tor-browser file as indicated, adding the tor ports available on the torrc file
4. Start with the command line
### What is the current bug behavior?
Tor Browser opens about:tor with red background and tells me that it is not connected.
But if I open another window, I am connected!
### What is the expected behavior?
Tor Browser should not tell me it is not connected. I kept trying different solutions before I decided to open another tab, because I believed on that message but it was not true.
### Environment
Using Tails 5.1 with Tor Browser tor-browser-linux64-11.0.13_en-US.tar.xz downloaded from https://www.torproject.org/download/
### Relevant logs and/or screenshots
![Captura_de_pantalla_de_2022-06-07_16-27-05](/uploads/3758b5df7befb882871a0eb0df80c478/Captura_de_pantalla_de_2022-06-07_16-27-05.png)Sponsor 131 - Phase 5 - Ongoing Maintenancehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40616MiddleNodes does not work2022-06-01T12:53:24ZGitRowinMiddleNodes does not work### Summary
When using the MiddleNodes option, Tor hangs forever during bootstrapping, regardless of what middle relay is picked.
### Steps to reproduce:
1. Add `MiddleNodes <any fingerprint>` to torrc
2. Start Tor
### What is the cu...### Summary
When using the MiddleNodes option, Tor hangs forever during bootstrapping, regardless of what middle relay is picked.
### Steps to reproduce:
1. Add `MiddleNodes <any fingerprint>` to torrc
2. Start Tor
### What is the current bug behavior?
Tor hangs forever during bootstrapping:
```
May 27 17:54:24.000 [notice] Bootstrapped 0% (starting): Starting
May 27 17:54:24.000 [notice] Starting with guard context "default"
May 27 17:54:25.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
May 27 17:54:25.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
May 27 17:54:26.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
May 27 17:54:27.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
May 27 17:54:27.000 [notice] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
May 27 17:54:27.000 [notice] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
May 27 17:54:27.000 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
May 27 17:54:27.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
May 27 17:54:28.000 [notice] Bootstrapped 40% (loading_keys): Loading authority key certs
May 27 17:54:28.000 [notice] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
May 27 17:54:28.000 [notice] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors
May 27 17:54:28.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/1, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)
May 27 17:54:28.000 [notice] Bootstrapped 50% (loading_descriptors): Loading relay descriptors
May 27 17:54:29.000 [notice] The current consensus contains exit nodes. Tor can build exit and internal paths.
```
### What is the expected behavior?
Tor should start up and create circuits using only the selected middle relay.
### Environment
Tor version 0.4.5.10 installed using apt on Debian GNU/Linux 11 (bullseye).Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/481Use of `nf_conntimeout_clients` seems incorrect2023-06-13T17:43:00ZNick MathewsonUse of `nf_conntimeout_clients` seems incorrectInspecting C Tor and `padding-spec`, it appears that we're setting `unused_client_circ_timeout_while_learning_cbt` incorrectly. Right now it's set to `nf_conntimeout_clients`, which isn't supposed to be used for that.Inspecting C Tor and `padding-spec`, it appears that we're setting `unused_client_circ_timeout_while_learning_cbt` incorrectly. Right now it's set to `nf_conntimeout_clients`, which isn't supposed to be used for that.Arti 1.0.0: Ready for production useNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40970Internet error may never be shown when bootstrapping never stops2023-11-06T22:14:44ZPier Angelo VendrameInternet error may never be shown when bootstrapping never stopsFor #40891, we have added a "You're offline" panel.
However, it may not be shown in some cases in which it should.
Currently, its logic is waiting for the bootstrap to fail, and only then showing that error if we could not reach Moat.
...For #40891, we have added a "You're offline" panel.
However, it may not be shown in some cases in which it should.
Currently, its logic is waiting for the bootstrap to fail, and only then showing that error if we could not reach Moat.
The reason is that we do not want bootstraps to fail when the anti-censorship mechanisms provided by the user would work, but Moat is inaccessible.
(This includes also domain fronting suddenly not working, or the Moat hoster deciding to cut us off, or whatever).
However, in some cases the bootstrap never stops, so it never fails, and Tor Browser remains stuck on it forever.
I have managed to get in this situation by connecting my computer to a LAN without Internet access (e.g., just connect the PC to an Ethernet switch without anything else plugged to, or connect it to a wireless access point without Internet access).
An idea is starting a timeout after the Internet was detected as offline (e.g., 30s or 1 minute), and if the progress is still below 10% (or some other threshold) when the timeout ends, we cancel the bootstrap and show the offline test.
The timeout could also start when the bootstrap begins, rather than starting when the offline tests fails.https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40028Why bridges offline for a few days get first_seen reset to 1970-01-012022-09-28T07:04:34ZHiroWhy bridges offline for a few days get first_seen reset to 1970-01-01We kept this bridge out of bridge statuses for 24 hours https://metrics.torproject.org/rs.html#details/2D8C27AA9C2FEC3EC468D7ABE9C3EDCA3C86610A and the first_seen date has been reset to the epoch. We should find out why this is happening...We kept this bridge out of bridge statuses for 24 hours https://metrics.torproject.org/rs.html#details/2D8C27AA9C2FEC3EC468D7ABE9C3EDCA3C86610A and the first_seen date has been reset to the epoch. We should find out why this is happening for bridges only.HiroHirohttps://gitlab.torproject.org/tpo/core/tor/-/issues/40611IPv4-mapped IPV6 addresses fail badly2022-10-24T20:31:53ZJim NewsomeIPv4-mapped IPV6 addresses fail badlyOriginally discovered when debugging signal-cli via torsocks: https://gitlab.torproject.org/tpo/core/torsocks/-/issues/40009#note_2803952
I can now reproduce without torsocks:
The following command, connecting to facebook's ipv6 addres...Originally discovered when debugging signal-cli via torsocks: https://gitlab.torproject.org/tpo/core/torsocks/-/issues/40009#note_2803952
I can now reproduce without torsocks:
The following command, connecting to facebook's ipv6 address via tor, works as expected:
```
$ curl -k -L --preproxy socks5://localhost:9050 https://[2a03:2880:f134:83:face:b00c:0:25de]
```
Without tor, we can also connect to facebook's ipv4 address via ipv6, using a [IPv4-mapped IPv6 address](https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses):
```
$ curl -k -L --preproxy https://[::ffff:31.13.93.35]
```
However if we try to do that using tor, the connection attempt hangs in curl. In the tor log we see it repeatedly trying and failing to build a path:
```
$ curl -k -L --preproxy socks5://localhost:9050 https://[::ffff:31.13.93.35]
```
With tor running as:
```
tor --SocksPort "ip6-localhost:9050 IPv6Traffic" --SocksPort "localhost:9050 IPv6Traffic" --Log "debug" --SafeLogging 0 --ClientUseIPv6 1
```
We get lines like:
```
May 17 15:38:04.000 [info] connection_ap_process_end_not_open(): Address '[::ffff:31.13.93.35]' refused due to 'exit policy failed'. Considering retrying.
May 17 15:38:04.000 [debug] addr_policy_append_reject_addr(): Adding a reject ExitPolicy 'reject ::ffff:31.13.93.35:*'
```
Full tor log: [tor-v6-mapped.log.gz](/uploads/9f9a571aad386aa79a14682c16ac1231/tor-v6-mapped.log.gz)Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/80is moat distributing bridges marked as blocked in russia?2024-03-07T18:10:20Zmeskiomeskio@torproject.orgis moat distributing bridges marked as blocked in russia?Someone has reported that moat/bridgedb is distributing bridges marked as blocked in russia (e.g. https://metrics.torproject.org/rs.html#details/1807BF9A521468998385F179DDBF928D2482A62C).Someone has reported that moat/bridgedb is distributing bridges marked as blocked in russia (e.g. https://metrics.torproject.org/rs.html#details/1807BF9A521468998385F179DDBF928D2482A62C).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40669Win10x64 - tor.exe not starting anymore at all when using GeoIPFile or GeoIPv...2022-08-30T20:18:51ZtpgrrWin10x64 - tor.exe not starting anymore at all when using GeoIPFile or GeoIPv6FileIn an (AFAIK) unchanged Tor installation¹ (torbrowser-install-win64-11.0.6_en-US.exe) tor.exe ceases to start since 2022/04/28.
Last successful start: 2022/04/20 (not tried in between), no log file is written whatsoever (despite "Log not...In an (AFAIK) unchanged Tor installation¹ (torbrowser-install-win64-11.0.6_en-US.exe) tor.exe ceases to start since 2022/04/28.
Last successful start: 2022/04/20 (not tried in between), no log file is written whatsoever (despite "Log notice file ..." in torrc) when failing.
Tracing the issue down I reduced torrc to only these 4 lines:
> Log notice file R:\Temp\Tor.log
> DataDirectory C:\Tools\Tor\Data\
> GeoIPFile C:\Tools\Tor\Data\geoip
> GeoIPv6File C:\Tools\Tor\Data\geoip6
I found that _disabling_ GeoIP functionality allows tor.exe to start again.
> #GeoIPFile C:\Tools\Tor\Data\geoip
> #GeoIPv6File C:\Tools\Tor\Data\geoip6
As soon as I enable either one (or both) of the GeoIP DBs tor just crashes without a trace.
Same with Tor extracted from latest version²
System:
Win10x64 Version 10.0.19043.1288, no AV except MS Defender 4.18.2203.5-0
¹ Windows unchanged as well - all updates are manual, no other admins
² extracted from torbrowser-install-win64-11.0.10_de.exe\Browser\TorBrowser\ and [...]\Browser\Data\ (using 7-zip)
P.S. Sorry for odd the line spacing, I may be too dumb for this editor