- tor-dev - lists.torproject.org

Merging "Approved" Arti MRs
by Neel Chauhan 07 Nov '25

07 Nov '25

Hi, As you may or may not know, I have two Arti MRs which are approved but not merged: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3432 https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3439 Could those two MRs please be merged? I hope you have a great day/evening. Best, Neel Chauhan

1 0

New Contributor Interested in Tor Development and Network Security
by TUSHAR KANT 01 Nov '25

01 Nov '25

Hello everyone, I’m *Tushar Kant, a third year undergraduate student at Indian Institute of Technology Jodhpur, India* passionate about *cryptography, network security, and privacy-preserving technologies*. I’ve been deeply interested in understanding how the *Tor network* achieves anonymity through *onion routing* and its large-scale relay-to-relay architecture that forms the backbone of user privacy on the internet. My technical background includes a solid foundation in *cryptography, encryption/decryption, hashing*, and general *network security concepts*. I’m proficient in *C++* and *Python*, with experience in *backend development*, which I plan to leverage in contributing to Tor’s core or related components. I recently joined the Tor Forum, subscribed to the *tor-dev mailing list*, and am exploring the repositories to get familiar with the codebase and contribution workflow. While I aim to contribute consistently to Tor, I am also looking forward to potentially being part of *GSoC 2026* with The Tor Project if the opportunity aligns. I would greatly appreciate any guidance on where to begin or which areas of the project would be most suitable for someone with my skill set. Looking forward to collaborating and learning from this community. Best regards, *Tushar Kant*

1 0

Question about Advertised BW listed on metrics webpage
by am 19 Oct '25

19 Oct '25

Hey there, My VPS is dedicated to running a Tor relay server, so the performance should be good. However, your Relay Search page (metrics.torproject.org) now says the speed is only just "XXX KiB/s"! (X is a number) This should not be true. I ran the `speedtest --secure --server XYZ` on the server in question, and it returns: > Using server A Download: 98.34 Mbit/s Upload: 120.44 Mbit/s > Using server B Download: 88.81 Mbit/s Upload: 104.86 Mbit/s > Using server C Download: 94.34 Mbit/s Upload: 103.05 Mbit/s I also checked the firewall configuration, and it did not limit anything. Are you sure your network measurement server is not overloaded? How about teaming up with speedtest servers to measure real network value? So the questions are: Q1. Where are you measuring this from? Q2. If the Advertised BW is just this low, doesn't my Tor relay won't be used at all?

2 1

Proposal 365, review notes
by Ian Jackson 14 Oct '25

14 Oct '25

Hi. I read the proposal here https://spec.torproject.org/proposals/365-http-connect-ext.html I hate these notes: * Tenses are weird. The whole proposal is written in a weird mix of tenses and sometimes in a weird mood. Writing the specifications in the future tense is confusing and will make moving the text to the main spec (which we should do after approval and as part of implementation) much harder. There should not be statements like "we should". Specifications, even proposals, should be definitive and therefore should be definite. So everything should be written in the present imperative. * "X-Tor-RPC-Target: Arti RPC support" is weird. Firstly, is this being a protocol registry? Secondly, do we not have a notion of critical extensions? We should be using that for something like this. * Proxy-Authorization Don't we need to continue to support http clients where we can't specify custom headers? If so then this spec is a recipe for continuation of the bad protocol where we use the whole of the Proxy-Authorization contents as an unconditional input to isolation. * Optimistic data This has a framing hazard, which could be a vulnerability in some circumstances. I wrote about this in this torspec MR https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/419#note_32… AFAICT that means if that MR merges, this feature will be removed? That would resolve the concern. * "X-Tor-Family-Preference: IP version preferences" What is this for? Is there not an existing way to control this over HTTP? * "X-Tor-Proxy: Indication for Tor proxy protocol support" Why does this need to be separate from the X-Tor-Capabilities ? * Capabilities > Clients SHOULD NOT inspect the contents of this header to determine > whether a given feature is supported or not. Should be MUST NOT. Capability guessing via version strings is completely terrible. I suggest: Clients MAY use this to determine whether some software has a particular bug, but the matching MUST NOT treat any future versions as buggy. So the bug must be fixed before this technique can be used. (This is the rule adopted by the PuTTY team for compatibility with broken ssh servers.) Thanks for your attention, Ian.

2 2

Proposal 357, review notes
by Ian Jackson 24 Sep '25

24 Sep '25

Hi. I read the proposal here https://spec.torproject.org/proposals/357-circ-key-exporters.html I had these notes: * AFAICT "KH" is not defined anywhere. At least, there is no cross-reference for it. Perhaps that aspect of the spec should be tidied up first? Or is KH being introduced here? The proposal is unclear. If it is being introduced, it should be defined. * There should be a registry of customisation strings. (Probably one for the whole of torspec) Thanks, Ian.

2 1

Piloting a new contributor workflow on gitlab.torproject.org
by Micah Anderson 05 Aug '25

05 Aug '25

Hi all, If you've recently tried to fork a Tor repository into your personal gitlab.torproject.org namespace and received an error, you’re not alone. This is a known limitation of our current GitLab setup. To address this, we are piloting a new contributor workflow designed to make it easier for community contributors like you to propose changes, open merge requests, and collaborate, without needing write access to Tor’s canonical GitLab repositories. We’ve created a shared GitLab group for contributor forks called tor-contributors[0]. This group hosts mirrored forks of selected Tor projects. When you want to contribute, you can request access to the relevant contributor fork, create a branch (e.g., username/fix-x), and open a merge request back to the canonical repository. We’re looking for contributors who are actively working on changes and would like to participate in this pilot by trying out the workflow and providing feedback. If that’s you, please follow the onboarding instructions[1]. To help keep things manageable, we ask that people only request access if they are preparing to open a merge request. If you're just curious or want to follow along, there is no need to request access, we will continue to share updates as the pilot evolves. Thanks, and we look forward to your feedback. Thanks, Micah 0. https://gitlab.torproject.org/tor-contributors/ 1. https://gitlab.torproject.org/tor-contributors/meta -- Micah Anderson (he/him) Director of Engineering The Tor Project, Inc. <https://torproject.org>

1 0

Available implementation and report on quantum-safe fully encrypted protocols
by Marc Himmelberger 04 Aug '25

04 Aug '25

Hi, I have just concluded my Master's Thesis at ETH Zurich titled "Implementing and Evaluating Quantum-Safe Fully Encrypted Protocols" and I believe the content is relevant for this mailing list. My thesis consists mainly of the implementation of the "Drivel" protocol [1]. Two of the authors of [1], Felix Günther (mail(a)felixguenther.info) and Shannon Veitch (shannon.veitch(a)inf.ethz.ch) supervised this thesis and are also available for questions regarding the protocol design in this thread. Drivel is an evolution of obfs4 [2] that: - allows for key encapsulation mechanisms, particularly the ones proposed as part of the NIST standardization [3], - has stronger obfuscation, providing more guarantees than obfs4 in the scenario that censors should get ahold of bridge information such as NodeID and long-term public key, - contains a thin crypto-agility layer, allowing the replacement of cryptographic algorithms as needed, - provides more configuration options to bridge operators regarding performance trade-offs by allowing for runtime-configuration of the cryptographic algorithms, and - allows for post-quantum traditional hybrid instantiations. Note:; my thesis covers the “pure” post-quantum case (i.e., non-hybrid). Due to the crypto agility, hybrids are relatively easy to add by implementing an appropriate PQ/T hybrid combiner, such as OEINC [1]. Additionally, there are proposed changes to Drivel itself, evaluations of the implementation's performance, and some security proofs in the thesis. The main purpose of my proposed changes is to add more flexibility in traffic shaping (minimize “quiet periods” previously discussed on this list [4]) and to optimize performance. The thesis PDF is available under: https://doi.org/10.3929/ethz-b-000746588 The chapters "Implementing Drivel" and "Experimental Evaluation" should be most relevant to this list. I encourage everyone interested in pluggable transports to have a look if this sounds intriguing. The implementation is done as a fork of the lyrebird repository [5] and is available under: https://github.com/marc-himmelberger/lyrebird-drivel The Tor Project is more than welcome to use my work for future changes to lyrebird, although I do believe some changes to drivel and some optimizations to my code may be beneficial for performance reasons before the pluggable transport is used in production. In case of any feedback or questions, do not hesitate to reach out. Best regards, Marc Himmelberger [1] https://eprint.iacr.org/2025/408.pdf [2] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyre… [3] https://csrc.nist.gov/projects/post-quantum-cryptography [4] https://archive.torproject.org/websites/lists.torproject.org/pipermail/tor-… [5] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyre…

2 1

meek-azure to meek rename
by Morgan 04 Aug '25

04 Aug '25

Hi everyone, We are going to be renaming the 'meek-azure' built-in bridge type to 'meek' in Tor Browser Alpha 15.0aX and and some of the surrounding ecosystem in the relatively near future. For background, see this issue: - https://gitlab.torproject.org/tpo/applications/team/-/issues/37 This will affect you *sooner* (i.e. in the coming month or two) if you: - consume pt_config.json: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/blob/mai… - If you populate your own application's built-in bridges from this file you may need to implement settings migration logic, in-app string updates, etc; in the future the 'meek-azure' key on the 'bridges' object will be just 'meek' - use the name 'meek-azure' or reference Azure in your app; the built-in 'meek-azure' bridges don't actually run on Azure anymore so if your app references Azure or Microsoft, you should probably update your copy - See this issue for updating Tor Browser's strings for reference: - https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/44069 This will affect you *later* (i.e. in the coming several months to a year) if you consume: - rdsys censorship circumvention APIs to query bridges by 'builtin' type - the high-level plan is to add meek-azure -> meek shims on the server-side so any legacy clients will still work into the future (though at some point such shims will surely be dropped) - new callers should instead request 'meek' bridges rather than 'meek-azure' - issue is being tracked here: https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/272 One thing to note is that this dose not affect the actual bridge-lines or pluggable-transport client configuration lines which are given to tor. The underlying pluggable-transport is still 'meek_lite', the rename only really affects the user-visible 'meek-azure' name. Please let me know if you've any questions/concerns! best, -morgan

1 0

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