- tor-dev - lists.torproject.org

Regression in Tor 0.4.8.17: Raw assertion failures upon exit
by Fabian Keil 28 Jul '25

28 Jul '25

With Tor 0.4.8.17 running on ElectroBSD 14.3-STABLE I reproducible get assertion failures at exit: #### Jul 28 13:25:32.633 [notice] Tor 0.4.8.17 (git-e41649c9a34f39f1) running on ElectroBSD with Libevent 2.1.12-stable, OpenSSL 3.0.16, Zlib 1.3.1, Liblzma 5.6.3, Libzstd 1.5.7 and BSD 1403502 as libc. [...] Jul 28 13:25:42.140 [notice] {GENERAL} Catching signal TERM, exiting cleanly. Jul 28 13:25:42.141 [debug] {CIRC} pathbias_count_circs_in_states: Found opened circuit 1 in path_state use succeeded Jul 28 13:25:42.141 [debug] {CIRC} pathbias_count_circs_in_states: Found opened circuit 1 in path_state use succeeded Jul 28 13:25:42.141 [debug] {CIRC} pathbias_count_circs_in_states: Found opened circuit 8 in path_state build succeeded Jul 28 13:25:42.141 [debug] {CIRC} pathbias_count_circs_in_states: Found opened circuit 9 in path_state build succeeded Jul 28 13:25:42.143 [debug] {FS} tor_rename: Renaming /var/db/tor/state.tmp to /var/db/tor/state Jul 28 13:25:42.144 [info] {GENERAL} or_state_save: Saved state to "/var/db/tor/state" Jul 28 13:25:42.144 [debug] {GENERAL} threadpool_stop_threads: Signaled worker threads to exit. Waiting for them to exit... Jul 28 13:25:42.144 [debug] {GENERAL} worker_thread_main: Worker thread 1/4 has exited [TID: 35948775929864]. ============================================================ T=Jul 28 13:25:42.144 [debug] {GENERAL} worker_thread_main: Worker thread 2/4 has exited [TID: 35948775927816]. Jul 28 13:25:42.144 [debug] {GENERAL} worker_thread_main: Worker thread 3/4 has exited [TID: 35948775913480]. Jul 28 13:25:42.144 [debug] {GENERAL} worker_thread_main: Worker thread 4/4 has exited [TID: 35948775931912]. ============================================================ T= 1753701942 1753701942 INTERNAL ERROR: Raw assertion failed in Tor 0.4.8.17 (git-e41649c9a34f39f1)INTERNAL ERROR: Raw assertion failed in at Tor 0.4.8.17 (git-e41649c9a34f39f1) at src/lib/lock/compat_mutex_pthreads.csrc/lib/lock/compat_mutex_pthreads.c::7891: : 00 Error unlocking a mutex. Error locking a mutex. 0x54eff23fd96 <dump_stack_symbols_to_error_fds+0x56> at /usr/local/bin/tor 0x54eff240ae8 <tor_raw_assertion_failed_msg_+0x1b8> at /usr/local/bin/tor 0x54eff24aab1 <tor_mutex_release+0x51> at /usr/local/bin/tor 0x54eff244815 <worker_thread_main+0x54efef43165> at /usr/local/bin/tor 0x54eff261d40 <tor_pthread_helper_fn+0x54efef43050> at /usr/local/bin/tor 0x54eff23fd96 <dump_stack_symbols_to_error_fds+0x56> at /usr/local/bin/tor 0x54eff240ae8 <tor_raw_assertion_failed_msg_+0x1b8> at /usr/local/bin/tor 0x54eff24aa31 <tor_mutex_acquire+0x51> at /usr/local/bin/tor 0x54eff244103 <threadpool_free_+0x93> at /usr/local/bin/tor 0x54eff15c900 <cpuworker_free_all+0x20> at /usr/local/bin/tor 0x54eff1e4f7e <tor_free_all+0x2e> at /usr/local/bin/tor 0x54eff081141 <tor_run_main+0x551> at /usr/local/bin/tor 0x54eff07f6c1 <tor_main+0x51> at /usr/local/bin/tor 0x54eff07f3a9 <main+0x19> at /usr/local/bin/tor 0x5572769ae64 <__libc_start1+0x124> at /lib/libc.so.7 Abort trap #### It looks like the problem was introduced in ee9b3c127c180. Reverting that commit works around the issue. Fabian

1 0

New Registration members tor-l10n@lists.torproject.org
by heinminoo969＠proton.me 22 Jul '25

22 Jul '25

tor-l10n(a)lists.torproject.org I am happy to be part of the main development organization. Although I am passionate about every aspect of technology, I am incomplete and need to learn a lot. xein-tor-l10n(a)lists.torproject.org

1 0

Re: New idea
by George Hartley 17 Jul '25

17 Jul '25

Hey again, just to be clear: I am not an official developer, but decided to give my thoughts anyway. If you require advanced security, look into the Vanguards project and it's detections for "abnormal" traffic / cells - it is mostly designed for hidden service operators, however clients can use it too :-) All the best, George On Thursday, July 17th, 2025 at 5:11 AM, Khaled Roomi <khaledroomi2013(a)gmail.com> wrote: > I got it, thank you George! > > > On 17 Jul 2025, at 6:26 AM, George Hartley hartley_george(a)proton.me wrote: > > > > Hey, > > > > Thanks for sharing your idea. > > > > That said, there are a few big issues with your proposal: > > > > 1.) Centralization of trust: Giving a fixed group of “original volunteers” special relay status adds centralized points of trust and failure. Tor has always aimed to avoid that — no single group should be in a position to de-anonymize users. > > > > 2.) The concept still exposes the IP somewhere: Replacing the guard with a “shield” doesn’t really solve the problem — it just moves it. The shield would now see the user’s IP instead of the guard, so we’re back to the same trust issue, just in a different spot. > > > > 3.) "Hard-coded" nodes are risky: If we hard-code a set of shield nodes, they become easy to block or target. And if any of them go down, users could lose access or hidden services could get de-anonymized. > > > > 4.) More latency: Adding an extra hop (shield → guard → middle → exit) makes the whole system slower and more complex, without clear benefits to anonymity. > > > > In a way, using a Snowflake bridge already does this according to my knowledge, as long as it is running as a Firefox plugin (which then proxies traffic to the "guard"). > > > > 5.) Exclusion and scalability: Restricting shield operation to only a small historical group doesn’t scale well and could create unnecessary gatekeeping. It also means we’d be relying on fewer people, which weakens the network. > > > > 6.) As mentioned above with Snowflake, censorship resistance is already handled elsewhere. > > > > Obfuscation for censored users is already addressed through pluggable transports like obfs4, meek, snowflake, etc. These are designed to be dynamic and hard to detect — hardcoded nodes would be a step back. > > > > In short: it’s a well-meaning idea, and the concerns behind it are valid - but the approach would likely introduce more problems than it solves. The current design of Tor reflects a lot of hard lessons about trust, decentralization, and threat modeling that we’ve learned the hard way over the past few years. > > > > Thank you, > > > > - George > > > > On Wednesday, July 16th, 2025 at 11:45 AM, Khaled Roomi via tor-dev tor-dev(a)lists.torproject.org wrote: > > > > > Hi tor, I wanted to contact you about an idea I want to share with you. My idea is making all the original volunteers (who were in the project since the project begun) run a new relay, it’s like some sort of shield. And no one else other than the volunteers can make that shield node. The tor client is hardcoded to connect to one of the shields the volunteer is running, then the shield connects to the guard then middle then exit. It improves anonymity by hiding the IP address of a user from the guard because law enforcement can make relays too. And since the client will only connect to the shields provided from the volunteers there’s no way that law enforcement or any criminal can see someone’s IP. And for people in censored countries volunteers should also run shields that obfuscate network traffic so ISPs wont catch people trying to connect through tor. Tor browser would become slower but more anonymous. And that’s my idea, I hope you guys are safe and goodbye. > > > _______________________________________________ > > > tor-dev mailing list -- tor-dev(a)lists.torproject.org > > > To unsubscribe send an email to tor-dev-leave(a)lists.torproject.org > > > <publickey - hartley_george(a)proton.me - 0xAEE8E00F.asc>

1 0

New idea
by Khaled Roomi 17 Jul '25

17 Jul '25

Hi tor, I wanted to contact you about an idea I want to share with you. My idea is making all the original volunteers (who were in the project since the project begun) run a new relay, it’s like some sort of shield. And no one else other than the volunteers can make that shield node. The tor client is hardcoded to connect to one of the shields the volunteer is running, then the shield connects to the guard then middle then exit. It improves anonymity by hiding the IP address of a user from the guard because law enforcement can make relays too. And since the client will only connect to the shields provided from the volunteers there’s no way that law enforcement or any criminal can see someone’s IP. And for people in censored countries volunteers should also run shields that obfuscate network traffic so ISPs wont catch people trying to connect through tor. Tor browser would become slower but more anonymous. And that’s my idea, I hope you guys are safe and goodbye.

2 1

ORB - Onion Reply Block
by Stefan Claas 03 Jun '25

03 Jun '25

Hi gentlemen, I would like to introduce you to pluto an smtp relay wich is using ORBs and would like to know your thoughts. https://githib.com/Ch1ffr3punk/pluto I post it here, because on the regular Tor forum it did not yet received any attention, in form of replies. Best regards Stefan

1 1

Proposal 364: CreateOnehop handshake to replace CREATE_FAST
by Nick Mathewson 07 May '25

07 May '25

https://spec.torproject.org/proposals/364-create-onehop.html This proposal describes a successor to CREATE_FAST that permits circuit handshake extensions. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! -- Nick

1 0

Proposal 363: Required/recommended protocols for onion services
by Nick Mathewson 07 May '25

07 May '25

https://spec.torproject.org/proposals/363-required-protovers-and-hs.html This proposal describes an enhancement to how we use subprotocol versioning in the consensus to advertise recommended and required subprotocols for running and connecting to onion services. Please feel free to open tickets on gitlab, or to discuss here. Discussion on the forum is also okay! peace, -- Nick

1 0

Proposal 362: Update onion service proof-of-work control loop
by Wesley Aptekar-Cassels 06 May '25

06 May '25

https://spec.torproject.org/proposals/362-update-pow-control-loop.html This proposal suggests a new algorithm for onion services to use to select the suggested effort value for the proof-of-work algorithm. The existing algorithm has some weaknesses, mostly stemming from the fact that the same request sent at different points in time might have different effects on the new suggested effort. The proposed algorithm is based in a more fundamental analysis of the goals of the control loop. Please feel free to open tickets on GitLab, discuss in the tracking ticket, torspec#329, or discuss here. :w

1 0

Proposal 361: Onion Association SANs in Certificates (OASIC)
by Micah Anderson 06 May '25

06 May '25

https://spec.torproject.org/proposals/361-oasic.html This proposal describes Onion Association standardization, authenticated by TLS certificates. It specifies how this association is encoded in the certificate's Subject Alternative Name (SAN) field, providing meaningful SAN-based Onion Association authentication. This proposal was written by Paul Syverson, I'm announcing it on his behalf. Feel free to open tickets on gitlab, discuss here, or also on the Tor Forum. -- Micah Anderson (he/him) Director of Engineering The Tor Project, Inc. <https://torproject.org>

1 0

Proposal 361: Onion Association SANs in Certificates (OASIC)
by Micah Anderson 06 May '25

06 May '25

https://spec.torproject.org/proposals/361-oasic.html This proposal describes Onion Association standardization, authenticated by TLS certificates. It specifies how this association is encoded in the certificate's Subject Alternative Name (SAN) field, providing meaningful SAN-based Onion Association authentication. This proposal was written by Paul Syverson, I'm announcing it on his behalf. -- Micah Anderson (he/him) Director of Engineering The Tor Project, Inc. <https://torproject.org>

1 0