The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-06-07T16:39:26Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17661Mac OS: whitelist the font .Helvetica Neue DeskInterface2022-06-07T16:39:26ZMark SmithMac OS: whitelist the font .Helvetica Neue DeskInterfaceIn Mac OS 10.10 (Yosemite), the system font is .Helvetica Neue DeskInterface. But this is not included in font.system.whitelist in TB 5.5a4. Unless doing so will cause fingerprinting concerns, we should add it. I will attach a screenshot...In Mac OS 10.10 (Yosemite), the system font is .Helvetica Neue DeskInterface. But this is not included in font.system.whitelist in TB 5.5a4. Unless doing so will cause fingerprinting concerns, we should add it. I will attach a screenshot that shows that buttons do not look good without it.https://gitlab.torproject.org/tpo/core/tor/-/issues/17660rend-spec says routers get the HSDir flag after 24 hours2020-06-27T14:00:12Zdonncharend-spec says routers get the HSDir flag after 24 hoursThe rend-spec was not updated when the HSDir flag uptime limit was raised to 96 hours.The rend-spec was not updated when the HSDir flag uptime limit was raised to 96 hours.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17659BUG : connection_ap_mark_as_pending_circuit()2021-10-13T19:38:33ZcypherpunksBUG : connection_ap_mark_as_pending_circuit()
```
Nov 23 [...] [warn] connection_ap_mark_as_pending_circuit(): Bug: What?? pending_entry_connections already contains 0x81b488f8! (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x8...
```
Nov 23 [...] [warn] connection_ap_mark_as_pending_circuit(): Bug: What?? pending_entry_connections already contains 0x81b488f8! (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81e10248 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81ab0338 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81a007d8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81b45800 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81e10170 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81b279e8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81d66cb8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81e11558 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x816458a8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x815c11a0 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81d4ddb8 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81563fa0 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x81b45f80 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x8129f718 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x814c7350 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x8158c3b0 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
Nov 23 [...] [warn] connection_ap_attach_pending(): Bug: 0x819f4a48 is no longer in circuit_wait. Why is it on pending_entry_connections? (on Tor 0.2.8.0-alpha-dev 35bfd782eae29646)
```Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17658Check buffer lengths and HMAC return value in crypto.c2020-06-27T14:00:12ZteorCheck buffer lengths and HMAC return value in crypto.cI've made sure that buffer lengths are consistently checked, and that the return value of HMAC is checked in crypto.c.I've made sure that buffer lengths are consistently checked, and that the return value of HMAC is checked in crypto.c.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17656New Tor Install / Network Connection2022-02-03T19:06:44ZTracNew Tor Install / Network ConnectionHi, I am new to Tor. I have attempted to run numerous times but receive the following log.
23/11/2015 00:43:31.300 [NOTICE] Opening Socks listener on 127.0.0.1:9150
23/11/2015 00:43:31.400 [NOTICE] Bootstrapped 5%: Connecting to direct...Hi, I am new to Tor. I have attempted to run numerous times but receive the following log.
23/11/2015 00:43:31.300 [NOTICE] Opening Socks listener on 127.0.0.1:9150
23/11/2015 00:43:31.400 [NOTICE] Bootstrapped 5%: Connecting to directory server
23/11/2015 00:43:31.500 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server
23/11/2015 00:43:34.600 [WARN] Tried connecting to router at 131.188.40.189:443, but identity key was not as expected: wanted F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 but got CAE69EA846B3E3931620C36C5EFF2276F091031A.
23/11/2015 00:43:35.100 [WARN] Tried connecting to router at 199.254.238.52:443, but identity key was not as expected: wanted 74A910646BCEEFBCD2E874FC1DC997430F968145 but got CAE69EA846B3E3931620C36C5EFF2276F091031A.
23/11/2015 00:45:36.300 [WARN] Tried connecting to router at 86.59.21.38:443, but identity key was not as expected: wanted 847B1F850344D7876491A54892F904934E4EB85D but got CAE69EA846B3E3931620C36C5EFF2276F091031A.
23/11/2015 00:47:45.600 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
23/11/2015 00:47:45.600 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
23/11/2015 00:47:45.600 [NOTICE] Closing old Socks listener on 127.0.0.1:9150
23/11/2015 00:47:46.400 [NOTICE] Delaying directory fetches: DisableNetwork is set.
The dialogue bar states that awaiting network connection, however no connection is made.
Any help will be much appreciated. Thanks all.
**Trac**:
**Username**: ep5i105https://gitlab.torproject.org/tpo/core/tor/-/issues/17655Minor comment fixes to Tor master2020-06-27T14:00:13ZteorMinor comment fixes to Tor masterPlease merge my branch comments-20151123 from https://github.com/teor2345/tor.git
It fixes up 3 minor comment typos from different areas of the codebase in 3 separate commits.Please merge my branch comments-20151123 from https://github.com/teor2345/tor.git
It fixes up 3 minor comment typos from different areas of the codebase in 3 separate commits.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/176540.2.8.0-dev crashes soon after boot on Linux2020-06-27T14:00:13ZTrac0.2.8.0-dev crashes soon after boot on LinuxNov 22 13:34:12.000 [notice] This version of Tor (0.2.8.0-alpha-dev) is newer than any recommended version, according to the directory authorities. Recommended versions are: 0.2.4.23,0.2.4.24,0.2.4.25,0.2.4.26,0.2.4.27,0.2.5.8-rc,0.2.5.9...Nov 22 13:34:12.000 [notice] This version of Tor (0.2.8.0-alpha-dev) is newer than any recommended version, according to the directory authorities. Recommended versions are: 0.2.4.23,0.2.4.24,0.2.4.25,0.2.4.26,0.2.4.27,0.2.5.8-rc,0.2.5.9-rc,0.2.5.10,0.2.5.11,0.2.5.12,0.2.6.5-rc,0.2.6.6,0.2.6.7,0.2.6.8,0.2.6.9,0.2.6.10,0.2.7.1-alpha,0.2.7.2-alpha,0.2.7.3-rc,0.2.7.4-rc,0.2.7.5
Nov 22 13:34:15.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Nov 22 13:34:15.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Nov 22 13:34:15.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Nov 22 13:34:16.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Nov 22 13:34:18.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Nov 22 13:34:18.000 [notice] Bootstrapped 100%: Done
Nov 22 13:35:16.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Nov 22 13:35:21.000 [notice] Performing bandwidth self-test...done.
Nov 22 13:36:53.000 [notice] Your DNS provider gave an answer for "5ulaoeeh.invalid", which is not supposed to exist. Apparently they are hijacking DNS failures. Trying to correct for this. We've noticed 2 possibly bad addresses so far.
Nov 22 13:36:53.000 [notice] Your DNS provider has given "198.105.244.24" as an answer for 9 different invalid addresses. Apparently they are hijacking DNS failures. I'll try to correct for this by treating future occurrences of "198.105.244.24" as 'not found'.
Nov 22 14:00:20.000 [err] tor_assertion_failed_(): Bug: src/or/connection_or.c:1483: connection_tls_continue_handshake: Assertion !tor_tls_is_server(conn->tls) failed; aborting. (on Tor 0.2.8.0-alpha-dev cbc1b8a4f75d449a)
Nov 22 14:00:20.000 [err] Bug: Assertion !tor_tls_is_server(conn->tls) failed in connection_tls_continue_handshake at src/or/connection_or.c:1483. Stack trace: (on Tor 0.2.8.0-alpha-dev cbc1b8a4f75d449a)
Nov 22 14:00:20.000 [err] Bug: /usr/bin/tor(log_backtrace+0x46) [0x7f9f20ac5186] (on Tor 0.2.8.0-alpha-dev cbc1b8a4f75d449a)
Nov 22 14:00:20.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0xe4) [0x7f9f20ae3594] (on Tor 0.2.8.0-alpha-dev cbc1b8a4f75d449a)
Nov 22 14:00:20.000 [err] Bug: /usr/bin/tor(connection_tls_continue_handshake+0x38e) [0x7f9f20a412de] (on Tor 0.2.8.0-alpha-dev cbc1b8a4f75d449a)
Nov 22 14:00:20.000 [err] Bug: /usr/bin/tor(+0x21f209) [0x7f9f20a29209] (on Tor 0.2.8.0-alpha-dev cbc1b8a4f75d449a)
Nov 22 14:00:20.000 [err] Bug: /usr/bin/tor(+0xc9c55) [0x7f9f208d3c55] (on Tor 0.2.8.0-alpha-dev cbc1b8a4f75d449a)
Nov 22 14:00:20.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x754) [0x7f9f1cf00f24] (on Tor 0.2.8.0-alpha-dev cbc1b8a4f75d449a)
Nov 22 14:00:20.000 [err] Bug: /usr/bin/tor(do_main_loop+0x32d) [0x7f9f208d520d] (on Tor 0.2.8.0-alpha-dev cbc1b8a4f75d449a)
Nov 22 14:00:20.000 [err] Bug: /usr/bin/tor(tor_main+0x1cb5) [0x7f9f208d9395] (on Tor 0.2.8.0-alpha-dev cbc1b8a4f75d449a)
Nov 22 14:00:20.000 [err] Bug: /usr/bin/tor(main+0x1c) [0x7f9f208cbe4c] (on Tor 0.2.8.0-alpha-dev cbc1b8a4f75d449a)
Nov 22 14:00:20.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f9f1c2f7ec5] (on Tor 0.2.8.0-alpha-dev cbc1b8a4f75d449a)
**Trac**:
**Username**: ciborgueTor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17653Stats on compiler and breakdown of false positives in antivirus programs2020-06-27T14:39:55ZTracStats on compiler and breakdown of false positives in antivirus programsHi Guys
There is a disturbing trend in programs released over the last two years. I would really like your input on the issue.
It seems that gcc and windows compilers both exhibit the same behaviour when compiling certain files. The be...Hi Guys
There is a disturbing trend in programs released over the last two years. I would really like your input on the issue.
It seems that gcc and windows compilers both exhibit the same behaviour when compiling certain files. The behaviour hardly shows up in modern antivirus programs, but rather when running an older antivirus program. There are numerous opens source projects that get flagged as Crypt.Xpack.Gen virus or some other virus. It doesn't matter if it was compiled with gcc or visual studio.
Here is a brief list of projects I have detected Crypt.Xpack.Gen issue with.
* Arduino 1.6.5 and higher - open source
* Tomahawk music player 1.8.0 and higher - open source
* Filezilla > 3.9.0.5 - open source
* Chrome 47 and higher - open source
* Free Download Manager > 3.9.3 - open source
* Claws Mail 3.13 - open source
* gpg4win - open source
* qmmp 0.8.5 and higher - open source
* taudioconverter 0.9.8 and higher - open source
* putty 0.6.6 - open source
* wireshark > 1.11.3 - open source
* git 2.6.2 and higher - open source
* vlc > 2.1.5 - open source
* rufus > 1.2.0 - open source
* torbrowser 5.0.4 - open source
This list is not exhaustive. The gut punch is that tor, gpg4win and claws should not be in this list fullstop.
Now my rationale on this is why tolerate even one false positive? Sure, antivirus vendors can be notified to allow your code, but the problem becomes a major foobar when everyone starts doing this. Monkey see, monkey do. Already with everyone moving to VS2012 and higher the problem becomes more prevalent. But what is more concerning is did gcc follow Redmond's trends or vice versa, because the same dll and lib packing is exhibited in gcc, that when scanned on a windows machine, flags as a virus.
So newer antivirus don't detect a thing, but then is that really a good idea? Sounds like a future backdoor for malicious code that mimicks the structure of a false-positive and can easily slip past your antivirus without you noticing.
Surely we should be progressing and retrogressing in compiler security, and not allowing anything to be compiled with a similar structure to a virus. Allowing that to happen opens the door to a world of false-positives effectively giving people a placebo and telling them to trust you.
I have tested all the above programs, and with every one there is a dramatic turning point where false positives do not exist. Each is reflected by the version number, so there is a way forward, because at one time dll's and libs were not packed in such a nefarious way. The version number all point to the trend starting around 2014 for gcc and visual studio.
What is sad is that torbrowser 504 gets flagged on omni.ja for an HTML/Crypted.Gen
So sure you tell us to trust it, but then every other dev on every other project claims the same thing about their code thereby unleashing a sea of false-positives onto the cyber landscape.
Perhaps tor needs to roll back to an earlier version of gcc and its build tools and then go about bullet proofing that toolchain for future use.
Thank you for your consideration
ping
**Trac**:
**Username**: pinghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17652Make a version of TorBrowser for daily usage2020-06-27T14:39:55ZcypherpunksMake a version of TorBrowser for daily usageIt would be very good to have a version of TorBrowser based on the latest stable Firefox with all the patches from Tor Project (because as we know Mozilla won't pathch some APIs to prevent fingerprinting better) applied, security feature...It would be very good to have a version of TorBrowser based on the latest stable Firefox with all the patches from Tor Project (because as we know Mozilla won't pathch some APIs to prevent fingerprinting better) applied, security features from about:config enabled by default and all the antifeatures from Firefox (hello, pocket, DRM, personalized start page, mandatory extensions signing, searchbar sending info for suggestions even in private mode, etc) removed. This browser should not be intended to be used with Tor, but intended to be used in daily surfing instead of Firefox, and should have different icon and name.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17651Torbrowser crash2020-06-27T14:39:55ZcypherpunksTorbrowser crashwww.nytimes.com/interactive/2015/11/21/world/middleeast/inside-raqqa-capital-of-isis.html
Clicking through the slides of this link is causing the torbrowser to crash/exit.
Privacy settings Low. Browser version 5.0.4. OS Debian 7.9.www.nytimes.com/interactive/2015/11/21/world/middleeast/inside-raqqa-capital-of-isis.html
Clicking through the slides of this link is causing the torbrowser to crash/exit.
Privacy settings Low. Browser version 5.0.4. OS Debian 7.9.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17650Cannot login to Youtube2023-11-14T08:32:44ZTracCannot login to YoutubeSince a couple of weeks I get this message every time I try to sign into youtube. It used to work fine. Commenting never worked.
"Sorry, we could not log you in at this time. Please try again later."
I even tried with security setting...Since a couple of weeks I get this message every time I try to sign into youtube. It used to work fine. Commenting never worked.
"Sorry, we could not log you in at this time. Please try again later."
I even tried with security setting "Low" and all the check boxes unchecked for the optional security settings.
**Trac**:
**Username**: mansdthttps://gitlab.torproject.org/tpo/tpa/team/-/issues/17647webstats.tpo rsync service2020-06-27T14:19:40ZSebastian Hahnwebstats.tpo rsync servicePlease set up an rsync service that takes /srv/webstats.tpo/rsync on wendelboi (or any other location) and serves it up as rsync.Please set up an rsync service that takes /srv/webstats.tpo/rsync on wendelboi (or any other location) and serves it up as rsync.https://gitlab.torproject.org/tpo/core/tor/-/issues/17646Core dump on "gmake test" NetBSD tracking tor_development git tree2020-06-27T14:00:13ZTracCore dump on "gmake test" NetBSD tracking tor_development git treeNov 20 05:35:16.476 [notice] Tor v0.2.8.0-alpha-dev (git-35bfd782eae29646) running on NetBSD with Libevent 2.1.5-beta, OpenSSL 1.1.0-dev and Zlib 1.2.3.
# gmake test
gmake all-am
gmake[1]: Entering directory '/usr/local/src/tor'
gmake[...Nov 20 05:35:16.476 [notice] Tor v0.2.8.0-alpha-dev (git-35bfd782eae29646) running on NetBSD with Libevent 2.1.5-beta, OpenSSL 1.1.0-dev and Zlib 1.2.3.
# gmake test
gmake all-am
gmake[1]: Entering directory '/usr/local/src/tor'
gmake[1]: Leaving directory '/usr/local/src/tor'
./src/test/test
onion_handshake: OK
bad_onion_handshake: OK
onion_queues: OK
ntor_handshake: OK
circuit_timeout: Memory fault (core dumped)
Makefile:7070: recipe for target 'test' failed
gmake: *** [test] Error 139
#
I tried running gdb on tor, but here was output, so not sure what core dumped.
# gdb src/or/tor test.core
GNU gdb (GDB) 7.3.1
Reading symbols from /usr/local/src/tor/src/or/tor...done.
[New process 1]
Core was generated by `test'.
Program terminated with signal 11, Segmentation fault.
#0 0xbbb932b1 in ?? ()
(gdb)
**Trac**:
**Username**: yancmTor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/17643Please create ux mailing list2020-06-27T14:19:40ZJens KubiezielPlease create ux mailing list@mrphs has requested the creation of a new mailing list. Please create ux mailing list with @mrphs as list admin (details see main ticket)@mrphs has requested the creation of a new mailing list. Please create ux mailing list with @mrphs as list admin (details see main ticket)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17641Use NoScript ABE feature to disallow hidden services access to clearnet2020-06-29T12:18:44ZcypherpunksUse NoScript ABE feature to disallow hidden services access to clearnetSome hidden services have some tracking (or non-tracking) scripts from clearnet included, which allows a clearnet party to track HS users. I suggest to use NoScript Application Boundaries Enforcer (https://noscript.net/abe/) to disallow...Some hidden services have some tracking (or non-tracking) scripts from clearnet included, which allows a clearnet party to track HS users. I suggest to use NoScript Application Boundaries Enforcer (https://noscript.net/abe/) to disallow hidden services access to clearnet resources (especially included scripts).
It could look like
Site *.onion
Accept from SELF++
#Anonymize from *.onion
Denyhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17640Handle CREATE/CREATED cell processing gracefully under load.2022-10-11T23:40:45ZYawning AngelHandle CREATE/CREATED cell processing gracefully under load.Two issues tangentially related in that both are for handling CPU worker backlog.
We currently sort of have logic for managing the CREATE processing backlog (see: `have_room_for_onionskin`), but behavior can be improved (I don't think t...Two issues tangentially related in that both are for handling CPU worker backlog.
We currently sort of have logic for managing the CREATE processing backlog (see: `have_room_for_onionskin`), but behavior can be improved (I don't think the aging code actually gets called when we are under extreme backlog since we give up and drop before we age).
With my proposed legacy/trac#13737 branch, we will now additionally have to contend with CREATED backlog. I will probably opt for similar behavior to CREATED processing (opting to destroy the circuit if the backlog grows too large), but am open to hearing ideas for other options.Tor: unspecifiedYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17639provide an option to display the expiry date of a given ed25519 signing key2020-06-27T14:00:14Zcypherpunksprovide an option to display the expiry date of a given ed25519 signing keyCurrently there is no way to see when the signing key is about to expire.
Adding such a feature would be great.Currently there is no way to see when the signing key is about to expire.
Adding such a feature would be great.Tor: 0.3.2.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/17638Make ersatz_socketpair work on IPv6-only systems:2020-06-27T14:00:14ZteorMake ersatz_socketpair work on IPv6-only systems:Some systems don't have IPv4 localhost (some IPv6-only systems):
ersatz_socketpair currently uses AF_INET. If that fails with EPROTONOSUPPORT (or WSAEPROTONOSUPPORT on Windows), let's have it try AF_INET6.
Some systems don't even have I...Some systems don't have IPv4 localhost (some IPv6-only systems):
ersatz_socketpair currently uses AF_INET. If that fails with EPROTONOSUPPORT (or WSAEPROTONOSUPPORT on Windows), let's have it try AF_INET6.
Some systems don't even have IPv6 localhost (some FreeBSD jails). Instead, they have a non-127/8, non-::1 IP address used as the default:
ersatz_socketpair currently uses INADDR_LOOPBACK. On IPv6, it should use ::1 (or a constant or function returning it). If that fails with E(address not found) (or WSAE(address not found) on Windows), that's actually what we want - we don't want to accidentally expose a socketpair on a routable address.
We should also remove the check in the ersatz_socketpair unit test that bails out on EPROTONOSUPPORT.
Patch on a version before 22dba27d8dd5 (23 Nov 2004) / svn:r2943.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/17637NoScript in Tor-Browser allows all third party domains2020-06-27T14:39:56ZTracNoScript in Tor-Browser allows all third party domainsTor-Browser 5.0.4 comes with NoScript installed by default. However, the NoScript is either defective or misconfigured by default. When I allow script execution for the top-level domain, then NoScript automatically allows execution of sc...Tor-Browser 5.0.4 comes with NoScript installed by default. However, the NoScript is either defective or misconfigured by default. When I allow script execution for the top-level domain, then NoScript automatically allows execution of script of all third party domains for this page. This is a huge security risk. The user should be able to decide which additional domains he wants to allow.
**Trac**:
**Username**: ctbuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17636Can a single IPv6 bridge failure stop Tor connecting?2020-07-27T18:18:15ZteorCan a single IPv6 bridge failure stop Tor connecting?ln5's IPv6-only Linux system had 3 bridges, but 2 failed.
Then the tor instance stopped connecting, even though it still had one good bridge.
Does this happen on IPv4?
(Can we reproduce it on IPv6?)
How can we make this more robust?ln5's IPv6-only Linux system had 3 bridges, but 2 failed.
Then the tor instance stopped connecting, even though it still had one good bridge.
Does this happen on IPv4?
(Can we reproduce it on IPv6?)
How can we make this more robust?Tor: unspecified