Discussion:
[tor-dev] Enhancement for Tor 0.3.4.x
David Goulet
2018-02-12 19:32:41 UTC
Permalink
Hello everone!

As an effort to better organize our 0.3.4.x release for which the merge window
opens in 3 days (Feb 15th, 2018), we need to identify the enhancement(s) that
we want so we can better prioritize the development during the merge window
timeframe (3 months).

Each feature should have its ticket marked for 0.3.4 milestone and with an
Owner set so we know who is "leading" that effort. It doesn't have to be the
person who code the whole thing but should be a good point of contact to start
with (and it can change over time as well).

It is possible that an enhancement can have more than one ticket so in this
case, please make a "parent" ticket that explains the whole thing and child
tickets assigned to it.

The network team just had its weekly meeting and if I recall correctly, these
enhancement should be planned for 0.3.4 (please the people who works on this,
can you tell us the tickets and make sure they are up to date?)

- Privcount (prop#280)
- large CREATE cells (prop#249)

If you plan to do a set of patches for a feature or enhancement, please do
submit it on this thread and make sure a proper ticket exists with an Owner.

Also, if you just want something in 0.3.4 as enhancement but might not work on
it, it is also OK to propose it (ticket and all) but please lets try as much
as possible to keep that thread focused on doable work with tickets and not
just a "dump all my tor wishes" :). For this, open a ticket :).

Big thanks everyone!
David
--
1xYrq8XhE25CKCQqvcX/cqKg04v1HthMMM3PwaRqqdU=
Nick Mathewson
2018-02-13 18:03:50 UTC
Permalink
Post by David Goulet
Hello everone!
As an effort to better organize our 0.3.4.x release for which the merge window
opens in 3 days (Feb 15th, 2018), we need to identify the enhancement(s) that
we want so we can better prioritize the development during the merge window
timeframe (3 months).
Each feature should have its ticket marked for 0.3.4 milestone and with an
Owner set so we know who is "leading" that effort. It doesn't have to be the
person who code the whole thing but should be a good point of contact to start
with (and it can change over time as well).
It is possible that an enhancement can have more than one ticket so in this
case, please make a "parent" ticket that explains the whole thing and child
tickets assigned to it.
The network team just had its weekly meeting and if I recall correctly, these
enhancement should be planned for 0.3.4 (please the people who works on this,
can you tell us the tickets and make sure they are up to date?)
- Privcount (prop#280)
- large CREATE cells (prop#249)
If you plan to do a set of patches for a feature or enhancement, please do
submit it on this thread and make sure a proper ticket exists with an Owner.
My biggest additional wishlist items for 0.3.4 are:

* ZSTD tuning (#24368)
* Fewer wakeups when idle (#14039)

And as a reach:
* Improved TLS 1.3 support

We should also keep in mind that as we accumulate these goals, we
might also need to pare them down if they start to get out of hand.
--
Nick
George Kadianakis
2018-02-19 20:03:53 UTC
Permalink
[ text/plain ]
Post by David Goulet
Hello everone!
As an effort to better organize our 0.3.4.x release for which the merge window
opens in 3 days (Feb 15th, 2018), we need to identify the enhancement(s) that
we want so we can better prioritize the development during the merge window
timeframe (3 months).
Each feature should have its ticket marked for 0.3.4 milestone and with an
Owner set so we know who is "leading" that effort. It doesn't have to be the
person who code the whole thing but should be a good point of contact to start
with (and it can change over time as well).
It is possible that an enhancement can have more than one ticket so in this
case, please make a "parent" ticket that explains the whole thing and child
tickets assigned to it.
The network team just had its weekly meeting and if I recall correctly, these
enhancement should be planned for 0.3.4 (please the people who works on this,
can you tell us the tickets and make sure they are up to date?)
- Privcount (prop#280)
- large CREATE cells (prop#249)
If you plan to do a set of patches for a feature or enhancement, please do
submit it on this thread and make sure a proper ticket exists with an Owner.
* ZSTD tuning (#24368)
* Fewer wakeups when idle (#14039)
* Improved TLS 1.3 support
Hello,

I agree it's a great idea to prioritize features for the next releases
so that we don't go blind!

Question wrt TLS 1.3: Is it lots of work to support TLS 1.3? And what
do we gain by supporting it? Should we prioritize it for this release or
for a subsequent one?

Cheers!

juanjo
2018-02-13 19:44:37 UTC
Permalink
If its just a wishlist I would love to see

1. More multithreading for Tor.

2. new technology against traffic correlation/confirmation attacks by
adding some mixing features like I said long ago:

Relay operators with great RAM set the flag mixing for their relays.
These relays could be used as normal or mixing relays (delaying packets,
mixing them and sending more noise data maybe?). Tor clients will have
to specify if they want to build a normal circuit connection (fast) or a
mixing connection, slow, but more anonymous.

3. a config value for forbidding that all nodes in a circuit be from the
same country (to make traffic analysis harder..., some countries like UK
seems to be using it already).

4. An easy way for people to setup a home relay from their computer? For
Windows users? As more and more users get access to Fiber with symmetric
speed, the slow speed and asymmetric problem is not here anymore. IDK.
Post by David Goulet
Hello everone!
As an effort to better organize our 0.3.4.x release for which the merge window
opens in 3 days (Feb 15th, 2018), we need to identify the enhancement(s) that
we want so we can better prioritize the development during the merge window
timeframe (3 months).
Each feature should have its ticket marked for 0.3.4 milestone and with an
Owner set so we know who is "leading" that effort. It doesn't have to be the
person who code the whole thing but should be a good point of contact to start
with (and it can change over time as well).
It is possible that an enhancement can have more than one ticket so in this
case, please make a "parent" ticket that explains the whole thing and child
tickets assigned to it.
The network team just had its weekly meeting and if I recall correctly, these
enhancement should be planned for 0.3.4 (please the people who works on this,
can you tell us the tickets and make sure they are up to date?)
- Privcount (prop#280)
- large CREATE cells (prop#249)
If you plan to do a set of patches for a feature or enhancement, please do
submit it on this thread and make sure a proper ticket exists with an Owner.
Also, if you just want something in 0.3.4 as enhancement but might not work on
it, it is also OK to propose it (ticket and all) but please lets try as much
as possible to keep that thread focused on doable work with tickets and not
just a "dump all my tor wishes" :). For this, open a ticket :).
Big thanks everyone!
David
_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
teor
2018-02-15 02:22:39 UTC
Permalink
Post by David Goulet
Hello everone!
As an effort to better organize our 0.3.4.x release for which the merge window
opens in 3 days (Feb 15th, 2018), we need to identify the enhancement(s) that
we want so we can better prioritize the development during the merge window
timeframe (3 months).
Each feature should have its ticket marked for 0.3.4 milestone and with an
Owner set so we know who is "leading" that effort. It doesn't have to be the
person who code the whole thing but should be a good point of contact to start
with (and it can change over time as well).
It is possible that an enhancement can have more than one ticket so in this
case, please make a "parent" ticket that explains the whole thing and child
tickets assigned to it.
The network team just had its weekly meeting and if I recall correctly, these
enhancement should be planned for 0.3.4 (please the people who works on this,
can you tell us the tickets and make sure they are up to date?)
- Privcount (prop#280)
Now superseded by prop#288. We expect at least one more proposal for the
PrivCount counter config format.

#22898: Help get privcount standardized and merged

#23147: prop288: Merge privcount-in-tor data collector backend implementation
#25153: Specify how PrivCount in Tor statistics are configured and interpreted

As a stretch, we could implement part of the Tally Reporters (see prop#288).

While I am implementing PrivCount in Rust, I will also fix or replace similar
code in the C statistics implementation:

#25263: Fix the hidden service statistics noise
Post by David Goulet
If you plan to do a set of patches for a feature or enhancement, please do
submit it on this thread and make sure a proper ticket exists with an Owner.
There are a lot of other things I'd like to do in 0.3.4, but I think I
should focus on PrivCount in Tor.

T
--
teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
------------------------------------------------------------------------
David Goulet
2018-02-19 17:14:24 UTC
Permalink
Post by David Goulet
Hello everone!
As an effort to better organize our 0.3.4.x release for which the merge window
opens in 3 days (Feb 15th, 2018), we need to identify the enhancement(s) that
we want so we can better prioritize the development during the merge window
timeframe (3 months).
On my part, I plan to have some scheduler refactoring/changes that requires
quite a bit of changes in the scheduler architecture but overall should
simplify greatly things with Vanilla and KIST (and future schedulers).

- Parent ticket: #23993
All child tickets are fixes that need to happen for this.
- This will touch also our circuit multiplexing and the connection subystem as
well (mostly how the outbuf interacts with the scheduler).

The other part would be IPv6 for HSv3. This includes:

- Unify link specifier API/ABI (#22781)
- Put IPv6 link specifiers in client EXTEND cells (#24451)
- Put IPv6 and unrecognised link specifiers in onion service EXTEND cells
(#24181)
- Put IPv6 link specifier in HS descriptor. (not ticket afaict).

There is a huge amount of IPv6 tickets with different tasks, I'll create a top
level parent "Hidden service v3 IPv6 support" ticket and child many tickets
related to this because right now it is hella confusing so we can consolidate
in one place and track progress there. It should also include single onion.

It will for sure touches other part of Tor that aren't HS specific so
hopefully we can overlap this with useful IPv6 implementation work.

That is it for now, in terms of features, I think this is reasonable to be
completed and merged in the next 3 months for 034 merge window.

Cheers!
David
--
s2OgTxgPSliwm2a67jagCGlxYAy4npmC5/sM0nssJR0=
teor
2018-02-19 19:54:34 UTC
Permalink
Post by David Goulet
- Unify link specifier API/ABI (#22781)
- Put IPv6 link specifiers in client EXTEND cells (#24451)
- Put IPv6 and unrecognised link specifiers in onion service EXTEND cells
(#24181)
- Put IPv6 link specifier in HS descriptor. (not ticket afaict).
There is a huge amount of IPv6 tickets with different tasks, I'll create a top
level parent "Hidden service v3 IPv6 support" ticket and child many tickets
related to this because right now it is hella confusing so we can consolidate
in one place and track progress there. It should also include single onion.
It will for sure touches other part of Tor that aren't HS specific so
hopefully we can overlap this with useful IPv6 implementation work.
I don't know how much time I will have to work on IPv6 in 0.3.4.
But I can prioritise reviewing proposals and code, and revising my existing
code.

Here are some dependencies:

HSv3 IPv6 needs relays to allow IPv6 extends:
#24404 Propose a relay protover that allows IPv6 extends

We also wanted to make relays do IPv6 extends first, to create cover traffic:
#24403 Propose and implement IPv6 ORPort reachability checks on relays

But we can use a consensus parameter instead:
#24868 Check a consensus parameter before activating onion service IPv6 features

T
Loading...