- tor-dev - lists.torproject.org

Reviewer for Bug #27491: Prefer IPv4 or IPv6 based on the number of failures
by Neel Chauhan 17 Jan '19

17 Jan '19

Hi tor-dev@ mailing list, I noticed the assigned reviewer for my bug/patch #27491 (https://trac.torproject.org/projects/tor/ticket/27491 (https://trac.torproject.org/projects/tor/ticket/27491)) mikeperry, has not yet reviewed my bug since he was assigned to my bug/patch back in December. I understand that not able to review bugs during the holiday season (for obvious reasons), but would someone, either mikeperry or another Tor developer be able to review this? I am aware that there is a code freeze for 0.4.0 and this (probably) won't get merged until at least February 15th, but I would really appreciate a reviewer. Thank You, Neel Chauhan === https://www.neelc.org/

2 1

anti-censorship weekly meeting notes
by Gaba 17 Jan '19

17 Jan '19

Hi! We had the weekly meeting today! You can find the logs here: http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-01-17-19.59.html And the contents of the pad: ANTI-CENSORSHIP work meeting pad -------------------------------- Next meeting: Thursday January 24th 8pm UTC Weekly meetings every Thursday 8pm UTC on #tor-meeting at OFTC (channel is logged while meetings are in progress). == Goal of this meeting == Weekly checkin about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship. == Links to Useful documents == Anti-censorship Roadmap: https://storm.torproject.org/shared/KXkqlNP8ouNks_ey5khZKUSbNj9ZoidXmEp80OD… Snowflake Roadmap: https://storm.torproject.org/shared/OdNtwrtRrqklh76l4PfcngBbQFDbjv_jRroj0We… Gettor Roadmap: https://storm.torproject.org/shared/rhsSl_3Pb253HPqoCdFiAdmXQ57NUG_BLvBCxqF… Bridgedb Roadmap: https://storm.torproject.org/shared/O4XpgyW_q6CAtPPO_nd_Qc16Up-jXqdJLG8gXZY… ------------------------------- ---- 17th January 2019 ---- ------------------------------- == Announcements == new hire for anti-censorship team starting at the end of the month == Discussion == Report on roadmap for anti-censorship at Tor Network Team roadmap for s19 snowflake and snowflake blockers for deployment (already in january) gettor review things that may go into the roadmap while in brussels in february bridgesdb other PTs (marionette setup) snowflake webextension Metrics Team roadmap for s19 can collaborate with other teams after March, specifically bridgedb Browser Team roadmap for s19 Snowflake integration into Tor Browser build (#28672, #25483) Marionette once we have a long running bridge - network team dependency #28015 Brainstorm improved ux for orgs that want to give bridges to their people UX Team roadmap for s19 Gettor PRD https://docs.google.com/document/d/18R_tUnqfFkn7d93w0pEbBOLxB62KAWHbUGd5MPK… <--- meet outside weekly anti-censorship meeting to define Snowflake extension : needs a developer to work on this. #28015 Brainstorm improved ux for orgs that want to give bridges to their people Community Team roadmap for s19 Fitting into existing outreach work? possible #28526? Team dependencies Deploy marionette #26920 Bridges #28015 Gettor Anything else? == Actions == Snowflake extensions: needs developer, let's check who/how in the browser team can do it (antonela, pili, gabA) Gettor: meet outside weekly anti-censorship meeting to define scope (antonela, gaba, hiro) == Updates == FORMAT! Name: Working on: - What you worked on last week and what you are planning to work on next week (related to anti-censorship work). Help with: - Something you may need help with. Gaba: Working on: kicking off collaboration work on the roadmap hiring process for anti-censorship team ahf: Working on: - Documenting current Snowflake architecture and identify problems related to scalability and usability (both for developers and users). (#28848) - Documenting basic WebRTC usage to allow other developers to quickly join in on it. (#28048) [<-- wrong ticket number? 28048 is "Metrics: Allow to search for relays per continent"] - Identifying bug where Snowflake proxy becomes unresponsive in a smaller environment. (possibly #25429?) kat5: Working on: - report 2 - private bridge guide for NGOs anto: Working on: - Snowflake Web Extension UI - https://trac.torproject.org/projects/tor/ticket/23888 - Put together a PRD for Gettor, needs more info and review - https://docs.google.com/document/d/18R_tUnqfFkn7d93w0pEbBOLxB62KAWHbUGd5MPK… Help with - snowflake extension: in need of a developer Samdney: Working on: - Will also have a look at the WebExtension ticket #23888 :) - Looking for something where they can help!!! - If you have anything in the direction of "research" or "investigation" in something, then I'm your guy! :) (- I'm working on a research project about censor <-> classical attacker in game theory. That's maybe later, when I have results :), interesting for UX/dev stuff.)

1 0

anti-censorship weekly checkin
by Gaba 17 Jan '19

17 Jan '19

Hi!! We are going to start doing weekly meetings about anti-censorship work at Tor. We still do not have a team specifically to work on anti-censorship (soon we will have it) BUT we have different teams working on snowflake, gettor and soon bridgedb as well Kat writing a report on what works needs to be done. If you are doing any work related to this and/or are interested in this work please join. Weekly meetings will be every Thursday 8pm UTC on #tor-meeting at OFTC (channel is logged while meetings are in progress). Next meeting Thursday January 17th 8pm UTC on #tor-meeting at OFTC cheers, gaba

1 1

txtorcon 19.0.0
by meejah 16 Jan '19

16 Jan '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm happy to announce txtorcon 19.0.0, containing the following changes: * add TorControlProtocol.when_disconnected (will replace .on_disconnect) * add detach= kwarg to Tor.create_onion_service * add purpose= kwarg to TorState.build_circuit You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/19.0.0 https://github.com/meejah/txtorcon/releases/tag/v19.0.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-19.0.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-19.0.0.tar.gz.asc Or via a "version 3" service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 3731b740653e3f551412744f1fcd7fa6f04aa9fa37c90dc6c9152e619886bf3b txtorcon-19.0.0.tar.gz 196b7b5726e3c69a602071295368da9205c0cd1e26aba37536d3b8fb3b08ac9d txtorcon-19.0.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCAAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAlw+vRERHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaacquQgAwJwyhfEhnH2DK9Zqy6pG6oFQzhHUJFgA BehabihiHzJmiUpdVPtZwJ8KkkFbkvkA4AtHy2yF7tP1kCO2k1684IMGtgXOeVC2 hRJpqVqxZlXkOehUmQ87nUTJLYMbVabI5DxIUM9PltvJJj65fIhs0Daq8Kkj5jQT vKgsLo1WNmUJ2JwiO+JYLd3Aet2NIxXl52WA+GyPYFEm5TwHNDL2vCYyT21a8aCB VV4btprjfUd5mb+jFXBvf6cxHrWNFLFMLvoJZruQKVSr0C5AV+7zLWNtanPdSAf6 VxKUpDAZf23iNq4yjDwWgUg8W/pNwO2bZCJB9xQJN7IyRgdd+ubDyQ== =aXJK -----END PGP SIGNATURE-----

1 0

Upcoming Network Team Meetings
by teor 15 Jan '19

15 Jan '19

Hi, The network team has weekly meetings in #tor-meeting on irc.oftc.net. Our next meeting is on Tuesday 22 January at 1800 UTC, because Monday is a US public holiday. We won't have a meeting on 28 January. Most of the team will be at a face-to-face meeting. Our first meeting in February is just after FOSDEM, we'll get back to you with a date. T -- teor ----------------------------------------------------------------------

1 0

Daemon
by marziyeh latifi 10 Jan '19

10 Jan '19

Hello I have some question about daemon: 1-what is the Tor daemon? 2-What is the relationship between oom killer algorithm and daemon? 3-how can I calculate memory usage of deamon by algorithm? I'm looking forward to hearing from you! thanks! Marziyeh

3 2

<unistd.h> in buffers_net.c
by Gisle Vanem 09 Jan '19

09 Jan '19

Some recent change has added a: #include <unistd.h> which fails for MSVC (it doesn't have it). Since I fail to find any way to comment on Trac or Gitweb, I give notice here. Patching into: --- a/src/lib/net/buffers_net.c 2019-01-02 18:57:42 +++ b/src/lib/net/buffers_net.c 2019-01-03 03:16:32 @@ -21,7 +21,10 @@ #endif #include <stdlib.h> + +#ifndef _MSC_VER #include <unistd.h> +#endif #ifdef PARANOIA ---------------- works fine. -- --gv

2 1

Multi-threading throughout
by Todd Hubers 09 Jan '19

09 Jan '19

There are early plans to distribute crypto operations across multiple cores [https://trac.torproject.org/projects/tor/ticket/1749] but there might be a better way. (I registered, but I couldn't find a way to annotate the ticket, so I'm emailing for now) The ticket states the reason being to saturate the bandwidth available (by using all the cores as efficiently as possible). I don't understand why a relay needs to have a "main thread". Network traffic arrives as an async operation and can be sent back out asynchronously. So a final strategy shouldn't have a central thread. The main thread might still be needed for startup, runtime adjustment, and system upkeep, but not for the core network-crypto processing; that should never need to touch the main thread. The current proposal speaks about multi-threading crypto operations, let's call that "A) Speed - Speeding up processing of a single cell". Instead, I propose "B) Concurrency - Restructuring so multiple cells can be processed concurrently". A cell of data should arrive via IO-Completion thread on a random CPU core, have crypto transformation applied on the same one core, then be dispatched onward out via the network. This seems to be quite a simple approach where I would think crypto code can remain the same "single-threaded" implementation. Approach [A] will have diminishing returns as the number of cores increases. You can only break up a cell unit of work so much until you're encrypting one byte per cpu core. However, with approach [B], if you have millions of CPU cores (as an extreme) you can be processing millions of cells concurrently. Therefore, I believe approach [B] would be more scalable. What do you think? Regards, -- -- Todd Hubers

2 3

Network team meeting Tuesday at 2300 UTC
by Gaba 04 Jan '19

04 Jan '19

Hi! The first network team meeting of the year is on Tuesday January 8th at 2300 UTC. The meeting will be at #tor-meeting on OFTC. Agenda and updates for weekly meetings this year are in: https://pad.riseup.net/p/tor-netteam-2019.1-keep cheers, gaba

1 0

Upcoming Tor change with application impact: "Dormant Mode"
by Nick Mathewson 04 Jan '19

04 Jan '19

Hello! This email is about a new feature that has some implications here for applications that use Tor. I want to make sure we've thought about and prepared for those implications, since we still have time to tweak this feature. == Overview In 0.4.0.x, Tor will begin supporting a new "dormant" mode in which it does not initiate network activity, and tries to avoid CPU wakeups. This mode is intended to help mobile devices sleep, and to minimize the impact of unused Tor clients on the network, and on the devices that run them. For the implementation history, see: https://trac.torproject.org/projects/tor/ticket/28335 and https://trac.torproject.org/projects/tor/ticket/28624 By default, Tor will become dormant if it is a pure client (not a relay, not an onion service[*]), and if it has received not client activity for 24 hours. (You can change the interval with DormantClientTimeout.) Unlike "DisableNetwork 1", Tor in dormant mode will not close any listener ports, and will become active again as soon as it receives a client connection. But like a "DisableNetwork 1" Tor, a dormant Tor will not build predicted circuits, and will not download directory information -- and therefore, will not bootstrap. Controllers can make Tor become dormant or non-dormant by sending the commands "SIGNAL DORMANT" and "SIGNAL ACTIVE" respectively -- these are now documented in control-spec.txt. Dormant state is persistent: if Tor has been idle for 20 hours, and you stop tor and start it again, and idle for 4 more hours, Tor will become dormant. If you stop tor and start it again, Tor will start in dormant mode. == Documentation Here's the documentation we have so far -- please let me know if you have ideas for clarification: DormantClientTimeout N minutes|hours|days|weeks If Tor spends this much time without any client activity, enter a dormant state where automatic circuits are not built, and directory information is not fetched. Does not affect servers or onion services. Must be at least 10 minutes. (Default: 24 hours) DormantTimeoutDisabledByIdleStreams 0|1 If true, then any open client stream (even one not reading or writing) counts as client activity for the purpose of DormantClientTimeout. If false, then only network activity counts. (Default: 1) DormantOnFirstStartup 0|1 If true, then the first time Tor starts up with a fresh DataDirectory, it starts in dormant mode, and takes no actions until the user has made a request. (This mode is recommended if installing a Tor client for a user who might not actually use it.) If false, Tor bootstraps the first time it is started, whether it sees a user request or not. After the first time Tor starts, it begins in dormant mode if it was dormant before, and not otherwise. (Default: 0) == Compatibility issues I see two issues here: one minor, and one major. Minor issue: some applications periodically make requests to the tor network on their own -- for example, Tor Browser's update requests. These requests prevent Tor from becoming dormant. If this is undesired, we can add some way around this. Major issue: some applications expect that Tor will always bootstrap when it starts, and delay presenting their own UI until Tor is ready. But if Tor starts as dormant, then it will not bootstrap until it receives a request from the client or a "SIGNAL ACTIVE" command from the controller. This could lead to breakage as the application waits for Tor to tell it that it's ready, and Tor waits for somebody to tell it that it's needed. Are all application developers okay with the issues above, and okay with working around them? If not, we may need changes in Tor before 0.4.0.x is released. Let's talk! [*] I'd like to add support for dormant onion services, but that's harder. See https://trac.torproject.org/projects/tor/ticket/28424 . peace, -- Nick

7 10