tor-dev January 2019

tor-dev@lists.torproject.org

21 participants
22 discussions

Release: obfs4proxy-0.0.8
by Yawning Angel 20 Jan '19

20 Jan '19

Hello all, I just tagged obfs4proxy-0.0.8. This includes a few minor bugfixes in an official tagged release, and changes the primary upstream repo to one hosted on gitlab. Moving forward issues and patch merge requests should be filed on the gitlab issue tracker. While I will attempt to examine other existing locations for such things, response may (will) be delayed. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.8… https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.8… Changes in version 0.0.8 - 2019-01-20: - Bug 24793: Send the correct authorization HTTP header for basic auth. - (meek_lite) Explicitly set Content-Length to zero when there is no data to send. - Added optional support for building as a Go 1.11 module. Patch by mvdan. - Change the canonical upstream repo location to gitlab. Regards, -- Yawning Angel

1 0

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

18 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 18 Jan '19

18 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 10 Jan '19

10 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev January 2019