Enhancement for Tor 0.3.4.x
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=
On Mon, Feb 12, 2018 at 2:32 PM, David Goulet <dgoulet@torproject.org> wrote:
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
Nick Mathewson <nickm@alum.mit.edu> writes:
[ text/plain ] On Mon, Feb 12, 2018 at 2:32 PM, David Goulet <dgoulet@torproject.org> wrote:
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
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!
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. El 12/02/18 a las 20:32, David Goulet escribió:
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 tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 13 Feb 2018, at 06:32, David Goulet <dgoulet@torproject.org> wrote:
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
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 ------------------------------------------------------------------------
On 12 Feb (14:32:41), David Goulet wrote:
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=
On 20 Feb 2018, at 04:14, David Goulet <dgoulet@torproject.org> wrote:
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.
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
participants (5)
-
David Goulet -
George Kadianakis -
juanjo -
Nick Mathewson -
teor