tor-dev January 2021

tor-dev@lists.torproject.org

10 participants
8 discussions

the consequences of deprecating debian alpha repos with every new major branch
by nusenu 21 Dec '21

21 Dec '21

Hi, tldr: - more outdated relays (that is a claim I'm making and you could easily proof me wrong by recreating the 0.3.3.x alpha repos and ship 0.3.3.7 in them and see how things evolve after a week or so) - more work for the tpo website maintainer - less happy relay operators [3][4] - more work for repo maintainers? (since a new repo needs to be created) When the tor 0.3.4 alpha repos (deb.torproject.org) first appeared on 2018-05-23 I was about to submit a PR for the website to include it in the sources.list generator [1] on tpo but didn't do it because I wanted to wait for a previous PR to be merged first. The outstanding PR got merged eventually (2018-06-28) but I still did not submit a PR to update the repo generator for 0.3.4.x nonetheless and here is why. Recently I was wondering why are there so many relays running tor version 0.3.3.5-rc? (see OrNetStats or Relay Search) (> 3.2% CW fraction) Then I realized that this was the last version the tor-experimental-0.3.3.x-* repos were shipping before they got abandoned due to the new 0.3.4.x-* repos (I can no longer verify it since they got removed by now). Peter made it clear in the past that the current way to have per-major-version debian alpha repos (i.e. tor-experimental-0.3.4.x-jessie) will not change [2]: > If you can't be bothered to change your sources.list once or twice a > year, then you probably should be running stable. but maybe someone else would be willing to invoke a "ln" commands everytime a new new alpha repo is born. tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie once 0.3.5.x repos are created the link would point to tor-alpha-jessie -> tor-experimental-0.3.5.x-jessie It is my opinion that this will help reduce the amount of relays running outdated versions of tor. It will certainly avoid having to update the tpo website, which isn't a big task and could probably be automated but it isn't done currently. "..but that would cause relay operators to jump from i.e. 0.3.3.x to 0.3.4.x alphas (and break setups)!" Yes, and I think that is better than relays stuck on an older version because the former repo no longer exists and operators still can choose the old repos which will not jump to newer major versions. [1] https://www.torproject.org/docs/debian.html.en#ubuntu [2] https://trac.torproject.org/projects/tor/ticket/14997#comment:3 [3] https://lists.torproject.org/pipermail/tor-relays/2018-June/015549.html [4] https://trac.torproject.org/projects/tor/ticket/26474 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

4 7

IANA well-known URI suffix registration for tor-relay-fingerprints file
by nusenu 10 Oct '21

10 Oct '21

Hi, to reduce the risk of certain kinds of attacks I'm aiming to submit a short spec (like [1]) in accordance with RFC8615 https://tools.ietf.org/html/rfc8615#section-3.1 for the registration of of a suffix for the verifyurl from https://github.com/nusenu/ContactInfo-Information-Sharing-Specification#ver… The name I have in mind is: tor-relay-fingerprints The file contains comments (lines starting with #) and relay fingerprints. https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml Let me know if you have any feedback on this and whether you have any opinion on whether you (The Torproject) wants to be the change controller. The only question that came up was: Will there be two types of relay fingerprints in the future (Ed25519)? thanks, nusenu -- https://mastodon.social/@nusenu [1] https://keybase.io/docs/keybase_well_known

5 22

A new idea for email encryption on tor
by Keifer Bly 28 Mar '21

28 Mar '21

Hi there, So I have a new email encryption system which requires that the user has the specific key file generated for a message rather than the password, specifically this software generates a unique key file for a specific message every time a message is created. The user then enters the date and time the message was created. Without the original key file the message can't be opened; https://www.youtube.com/watch?v=R0W7OVdNrOA Here is a video showing the software. I've built it for Windows and Mac OS. I was wondering if this could be implemented in tor. I think it would be an interesting idea for a tor based email system to make the messages unrecoverable after use. OS: Windows, Mac OS What do you think? --Keifer

4 5

Proposal 328: Make Relays Report When They Are Overloaded
by David Goulet 03 Mar '21

03 Mar '21

Greetings, Attached is a proposal from Mike Perry and I. Merge requsest is here: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/22 Cheers! David -- uSxMMaJozH7GAo7qjzhVUm5FDynPYtBfOeZcLS88XeU=

7 12

Relay stalling when creating circuits
by Andreas Kempe 24 Jan '21

24 Jan '21

Hello everyone! For a while now, I've noted that when running a non-exit relay under fairly heavy load that is allowed to be utilised as a client, it has a tendency to stall when trying to create new circuits. If the relay has not been used as a client for a while and has a need to create new circuits, CPU load shoots up to 100 % and the stalls for some amount of time. I've seen stalls of over 1 minute. I've taken two profiling traces of the relay, one during normal operations and during the stalling behaviour. This was done on version 0.4.4.6 and each profile is approximately a 10 second recording. Normal case: >- 84,34% event_base_loop > - 80,19% event_process_active_single_queue > - 42,87% scheduler_evt_callback > - 42,86% kist_scheduler_run > + 20,23% connection_handle_write > + 9,47% update_socket_info_impl > + 5,07% channel_flush_some_cells > + 2,49% smartlist_pqueue_pop > + 2,19% outbuf_table_add > + 1,06% smartlist_pqueue_add > + 28,38% conn_read_callback > - 5,27% periodic_event_dispatch > - 3,32% second_elapsed_callback > + 1,69% run_connection_housekeeping > + 0,98% circuit_build_needed_circs > + 1,73% save_state_callback > + 1,50% conn_write_callback > + 1,02% connection_ap_attach_pending > + 4,02% epoll_dispatch Stalling case: >- 86,27% event_base_loop > - 85,52% event_process_active_single_queue > - 31,78% periodic_event_dispatch > - 30,00% second_elapsed_callback > - 28,84% circuit_build_needed_circs > - 15,35% connection_ap_attach_pending > - 15,34% connection_ap_handshake_attach_circuit > - 15,34% circuit_get_open_circ_or_launch > 10,14% circuit_get_best > - 4,99% circuit_launch_by_extend_info > - 4,88% circuit_establish_circuit > + 2,11% router_choose_random_node > + 2,05% nodelist_add_node_and_family > 0,69% count_acceptable_nodes.isra.0 > + 13,39% circuit_launch_by_extend_info > + 0,80% run_connection_housekeeping > + 1,74% save_state_callback > - 30,76% connection_ap_attach_pending > - connection_ap_handshake_attach_circuit > - 30,74% circuit_get_open_circ_or_launch > - 30,63% circuit_get_best > 1,18% circuit_get_global_list > + 11,50% conn_read_callback > + 10,47% scheduler_evt_callback > - 10,47% scheduler_evt_callback > - kist_scheduler_run > + 6,27% connection_handle_write > + 1,54% channel_flush_some_cells > + 0,98% update_socket_info_impl > + 0,91% smartlist_pqueue_pop > 0,75% epoll_dispatch (The traces above are meant to be indented for legibility, but some mail clients think they know better.) Has anyone seen similar behaviour or have an inkling as to what's going on? I thought it best to ask before diving into the code. Cordially, Andreas Kempe

1 0

DirAuth usage and 503 try again later
by James 20 Jan '21

20 Jan '21

Good day. Is there any chance that torpy (https://github.com/torpyorg/torpy) was triggered this issue https://gitlab.torproject.org/tpo/core/tor/-/issues/33018 ? Some wary facts: - Torpy using old fashion consensus (not mircodesc) - When consensus not present in cache (first time usage) it downloads consensus from random directory authorities only. - Before August 2020 it was using plain HTTP requests to DirAuths. Now it creates "CREATE_FAST" circuits to DirAuths (is that right way by the way?) From other side: - Torpy store consensus on disk (so whenever client restart it must not download full consensus again) - It will try download consensus after time which sets by valid_time field from consensus which more than 1 hour (so it's not so often) - Torpy try get consensus by "diff" feature (so it's minimize traffic) Still may be some of this features not working well in some conditions. Which could cause a lot of consensus downloads in Jan 2020... Or may be you know more info about this situation? Do you have some recommendations for tor client implementation? Can you explain in several paragraphs what behavior of original tor client is? As far as I understand when first time original tor starts it tries download consensus from fallback dirs not from DA? Is this key point? There is one more issue https://gitlab.torproject.org/tpo/core/tor/-/issues/40239 which I'm not understand correctly. Let's imagine it's first run of tor client and that time coincidentally coincided with DA voting. That means client will not be able to download consensus? That is strange decision. Or do you mean clients must download consensus from fallback dirs which never in "voting" process?

4 6

torify/nmap results in SIGABRT
by Peng Yu 15 Jan '21

15 Jan '21

Hi, I see the following error. Is it a bug in torify/torsocks? Thanks. $ torify nmap -p7 google.com ... NSOCK ERROR [88.9380s] nsock_make_socket(): Socket trouble: Operation not permitted Assertion failed: (nse->iod->sd >= 0), function nsock_pool_add_event, file nsock_core.c, line 1273. Abort trap: 6 -- Regards, Peng

2 1

Has Core Tor Development Slowed? Or Are We Moving To Rust/arti?
by Neel Chauhan 09 Jan '21

09 Jan '21

Hi tor-dev@, I hope you all had a great holiday season. I noticed that Core Tor development, especially with the tor daemon, has slowed down significantly since the COVID crisis. Sorry if I have been less active in the Tor community as opposed to the past. I've been more focused on FreeBSD Ports as of now, but I still want to post at least the occasional Tor patch here and there. Core Tor/Tor hasn't seen an update since December 21, even when we are already a week into 2021. Is this related to the layoffs which happened last year? Or is Tor moving to Rust (via arti) and all the development is happening there? I'm guessing both. If it's the latter, I guess I have to start learning Rust sooner rather than later. Well, who am I kidding, I had to learn C# and PowerShell for my job (Disclaimer: I work at Microsoft, not on security or Windows/Azure however). Is there any other reason? Best, Neel Chauhan

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev January 2021