[tor-project] Notes from network team meeting, 22 Jan 2018
nickm at freehaven.net
Thu Jan 25 16:51:23 UTC 2018
Meeting logs are available at
Pad copied below:
Network team meeting pad, 22 January 2018
Andre-Louis paused. "The less we mention names perhaps the better."
--- Rafael Sabatini, _Scaramouche_
Welcome to our meeting! Mondays at 1800 UTC on #tor-meeting on OFTC.
(This channel is logged while meetings are in progress.)
Want to participate? Awesome! Here's what to do:
1. If you have updates, enter them below, under your name.
2. If you see anything you want to talk about in your updates, put
them in boldface!
3. Show up to the IRC meeting and say hi!
Note the meeting location: #tor-meeting on OFTC!
Meeting notes from last week:
* are on the tor-project list, send on 17 January 2017
( https://lists.torproject.org/ was down when I checked)
- Tor 0.3.2.9 came out on 10 January 2018
- Soon it will be It is now time to triage 0.3.3.x tickets.
Please make yourself the owner of tickets in that milestone that you
- The meeting time is now 1800 UTC.
- Let's have some proposal discussions. Isis kicked off the process here:
- We are planning a single-day pre-planned highly-focused hackfest
before the Rome Tor meeting
- teor: pre-Rome hackfest venue is confirmed
- komlo: Should there be a Rust update/planning session? What
should we prepare/do beforehand to help this be
- On the roadmap spreadsheet: Please take February tasks. (If
somebody else has already taken something you want, please talk to
them and/or add yourself too.)
- review-group-29 is open, there are 2 tickets left in needs_review:
- review-group-30 is open, there is 1 ticket left in needs_review:
- We still need head count in the team rotation:
- 0.3.3 freeze today! Please work on bugs in 0.3.3 as they come
up, so we can release it on time!
- teor: Do we still want a hackfest in May?
I need to book flights in the next week or two.
I have made a pad so we can pick dates:
- teor: do we want to implement Tor2web overload defences at
HSDirs and Intro Points?
They can be off by default. But if the load gets worse, we will
want them deployed on
most of the network before we activate them.
[dgoulet] I've asked the same question on comment:17 on if we should
have them all and
backported or only RP and merge the other ones later.
- Last week:
- Implemented the Tor part of (experimental) PrivCount onion
service descriptor fetches
- Keeping my relays operating and supporting relay operators
- Did not get time to review or revise code, but did review
- Damian started on ORPort support for Stem, using Endosome as
Stem now speaks link-layer Tor cells (the link layer is the
lowest layer, the
higher layers are circuits and streams).
- This week:
- Implement and test experimental PrivCount onion service stats
(This is the last experimental PrivCount feature)
- Make a trac user page that lists the tickets I'm working on
- Get the test network running new IPv6 consensus code
- Maybe I will get time to review or revise tickets this week
- It's a short week for me, because Australia has a holiday on
the date of the
colonisation of Sydney
- Last week:
* Worked towards stable releases
* Reviewed and merged lots of things for 0.3.3, including
vanguards experiment branch
* Fixed scan-build
* Worked more on getting Tor to be happy restarting in-process
- This week:
* Release 0.3.3.1-alpha
* FEATURE FREEZE BEGINS. (The anti-DoS work has permission to
break the freeze.)
* Talk with Isis about TLS1.3 work
* Merge more things
* Continue experiments on killing off ancient clients.
* Fix as many bugs in 0.3.3 as possible.
* Work on restart-in-process work
* Book all travel to Rome
- Last week:
* My time has been again devoted to DoS mitigation. The ticket is #24902.
On Sunday, I've finalized code for the 3 defenses mentionned in the
ticket and put the 0.2.9 branch under review.
* Starting addressing the review with many fixup commits.
* I've opened couple of tickets: #24952 and #24914
* Reviewed and worked on #24895 to have it backported cleanly.
* Rome booking is done for me!
- This week:
* Very high priority for me is #24902 to be merged in 033 as a beta test
run and at the same time finalize the 029 branch as we fix things.
* If the above can be achieved, I can go back to a more regular work
schedule of reviewing tickets, patches and continuing my tor tasks.
* Many things have been delayed on my parts and pushed to 034 so I want to
go over tickets and mark them accordingly as well as the roadmap.
* Profile 032 fast relays to hunt down any high CPU usage that tor-relays@
has been reporting lately (might not only be caused by the DoS).
* If time permits, finalizing #24554 which addresses couple important
things that needs to be fixed in the scheduler mainly #24700, #23579 and
the removal of a lot of memory allocation in the scheduler run.
Meeting logs here:
- Got SystemTap to work via the 'sdt-inteface' (A DTrace compatible
interface to defining probes) such that tracing works on macOS,
FreeBSD, and Linux.
- Got systemtap to work on device, but it was painful, and just
showed the same results as I could reproduce on 32-bit desktop
- Started writing some notes to discuss memory optimization and how
far we are interested to go at the expense of code simplicity.
- Reviewed #24652, #21074
- Bug triage
- Finish memory optimization document.
- Discuss initial memory optimization strategies and begin
- Land systemtap compatible dtrace code.
- Book Rome travel.
from dec 19 - now:
- prevent bridgedb from handing out bridges in the same /16 (or ::/64)
- proposal writing (migration to TLS 1.3)
- revised the large create cell proposal to meet
concerns/ideas raised in discussion meeting
- check in on moat deployment stuff and fix any remaining
- organise proposal meetings
- phone call with ian to discuss ntor changes
- start working on the large create cell implementation
- TLS 1.3 meeting in a couple hours
Last week (2018-W03):
- Travis CI workarounds (#24863)
- looked a bit more at STACK stuff (#24423)
- CoC feedback
- slowly recovering from illness
This week (2018-W04):
- look into making our GitHub presence a bit more real
- Rome travel stuff
- monitor CoC feedback as needed
sponsor4 - I will ask for extension, Matt Finkel and the TB team
are helping me figure out how much more time to ask. Hope to request
sponsor8 - Q$ report time. Deadline is Jan 31st. I will start to
put things together for it this week.
.onion user test - Antonella and I decided to include a test for
India meetup, Antonela executed it and just shared results, we will
share more soon as we digest it.
I will be in seattle Thursday/Friday
- #13837 and #23101 are now merged! Spent some time reviewing and testing
this feature this past week.
- Spent time reviewing and analyzing the DoS mitigation subsystem of david
and roger. Did some review, wrote some unittests, found some bugs.
- Reviewed #24894, #24946
- Had a meeting with a researcher about integrating PIR in HSDirs. Helped him
with code and chutney/shadow. Likely doing another meeting in a week or two.
- Had a meeting with some people who want to implement prop279 on core
Tor. Discussed the proposal, made a small implementation plan and planning
to meet again in a week or two.
- Started hacking on #24896.
- More work on the DoS issue since that's the main priority of the
network right now.
Also finalize #24896.
- I have a bunch of prop224 from my service that I need to start
analyzing and filing.
[dgoulet]: You have log for the non decodable descriptor issue?
- Synch up on prop247 with mike.
- Finishing touches on #13837 and #23101 to get them merged
- Updates to vanguards.py to improve circuit length checks and some
- Wrote fix for a spurious log_warn introduced by #13837 (See #24946)
- vanguards.py improvements, prototypes, README, packaging, etc.
Tried 0.3.2.9 in Shadow. Doesn't work out of the box (no surprise).
There's a few places Tor assumes it is not 1970, 1972, or 1985.
That's not good for Shadow
(shadow starts time at unix timestamp 0 AKA jan 1st 1970)
Coming up: Work will ya'll to see about not making these
assumptions or making Shadow work better.
- log with two nonfatal asserts http://paste.debian.net/hidden/fd2ce05f/
- probably dangerous/broken/stupid patch that makes
hs_get_time_period_num not fail due to it being period number 0 in
- opened #24961
More information about the tor-project