Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:12:54Zhttps://gitlab.torproject.org/legacy/trac/-/issues/17242prop224: Implement client support2020-06-13T15:12:54ZDavid Gouletdgoulet@torproject.orgprop224: Implement client supportThis ticket is the parent one for anything related to client implementation for proposal 224.
As we break down functionalities and needed features, we'll add more child tickets.This ticket is the parent one for anything related to client implementation for proposal 224.
As we break down functionalities and needed features, we'll add more child tickets.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17241prop224: Implement relay side support2020-06-13T15:03:22ZDavid Gouletdgoulet@torproject.orgprop224: Implement relay side supportImplement the support for RP and IP that is new cell format and ntor handshake. This would be support of 224 only on the relay side for communication between nodes.Implement the support for RP and IP that is new cell format and ntor handshake. This would be support of 224 only on the relay side for communication between nodes.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/17238prop224: Implement HSDir support2020-06-13T15:03:52ZDavid Gouletdgoulet@torproject.orgprop224: Implement HSDir supportThis is part of the grand proposal 224. The task here is to implement the new descriptor format, HSDir caching for store/lookup and make sure relay can serve them. Note that this ticket does NOT require the client and service to support ...This is part of the grand proposal 224. The task here is to implement the new descriptor format, HSDir caching for store/lookup and make sure relay can serve them. Note that this ticket does NOT require the client and service to support the new descriptor format. This is only on the relay side.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16949Make Chutney Easier to Use & More Functional, Write Guide2020-06-13T13:29:27ZteorMake Chutney Easier to Use & More Functional, Write GuideI (teor) am writing a guide to using chuntney.
As part of that, I'm making chuntey easier to use, mainly through a series of tweaks that simplify usage and improve test coverage.
See https://trac.torproject.org/projects/tor/wiki/doc/Tor...I (teor) am writing a guide to using chuntney.
As part of that, I'm making chuntey easier to use, mainly through a series of tweaks that simplify usage and improve test coverage.
See https://trac.torproject.org/projects/tor/wiki/doc/TorChutneyGuide and the child tickets for more details.https://gitlab.torproject.org/legacy/trac/-/issues/16764Simplify Tor's control flow graph to the extent we can.2020-06-13T15:32:14ZNick MathewsonSimplify Tor's control flow graph to the extent we can.For background, see http://archives.seul.org/tor/dev/Mar-2015/msg00197.html .
As of this writing, the largest strongly-connected component in Tor's callgraph has 407 functions in it. Nobody can actually understand a program that's so c...For background, see http://archives.seul.org/tor/dev/Mar-2015/msg00197.html .
As of this writing, the largest strongly-connected component in Tor's callgraph has 407 functions in it. Nobody can actually understand a program that's so complex. Let's simplify it!
(This is a parent ticket.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15056Support ed25519 identities for circuit extension2020-06-13T15:04:05ZNick MathewsonSupport ed25519 identities for circuit extensionOnce #12498 is merged and #15055 is done, we can use ed25519 in circuit extension as documented in proposal 220.Once #12498 is merged and #15055 is done, we can use ed25519 in circuit extension as documented in proposal 220.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15055Implement ed25519 link handshake2020-06-13T15:05:30ZNick MathewsonImplement ed25519 link handshakeIn #12498 , we implement a new identity key type. Now it's time to use it in a proper handshake as documented in proposal 220.In #12498 , we implement a new identity key type. Now it's time to use it in a proper handshake as documented in proposal 220.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/14683Document medium-scale design of key Tor abstractions2020-06-13T14:42:27ZNick MathewsonDocument medium-scale design of key Tor abstractionsIn between the specs and the doxygen documentation, there isn't much to explain _why_ our subsystems work that way, how they fit together, and so on.
Some areas we should really elaborate are:
* circuits
* cmux
* circuitpathbias
...In between the specs and the doxygen documentation, there isn't much to explain _why_ our subsystems work that way, how they fit together, and so on.
Some areas we should really elaborate are:
* circuits
* cmux
* circuitpathbias
* entrynodes
* channels
* the main event loop/connection abstraction
We should probably try to make it a practice to _always_ document new things, and to fill in documentation for older things as we can. Whatever has changed most recently is probably going to be freshest on our minds, so let's start there.
I'm putting this in 0.2.??? as non-blocker, but we should try to get more stuff documented whenever the opportunity exists.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/13339Prop140: Complete Consensus diffs / Merge GSoC project2020-06-13T14:39:24ZmvdanProp140: Complete Consensus diffs / Merge GSoC projectGoogle Summer of Code finished over a month ago, and during this time I've been tidying up my code a bit and reading it for the merge. You will find it on github:
https://github.com/mvdan/tor
This ticket is for the sole purpose of foll...Google Summer of Code finished over a month ago, and during this time I've been tidying up my code a bit and reading it for the merge. You will find it on github:
https://github.com/mvdan/tor
This ticket is for the sole purpose of following the merge process and its progress. But as always I'm on IRC and mail if you want to contact me directly.
I just rebased against master this morning. Nick and Sebastian have been reviewing my code over the summer, but of course more sets of eyes are needed.
The test coverage for the diff generation and application is fine (see test_consdiff.c), but there aren't any tests for the stuff I wrote to wire it into serving and fetching consensus diffs. Not really sure how to go about that, can't really promise I'd have the time to dive into it.
And regarding commit messages and changelog entries, I pretty much went with my instinct. Chances are they can be improved - the commit messages for future reference and the changelog entries for future release changelogs - so criticism is welcome.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/12424Implement improved hidden service protocol (prop224)2020-06-13T15:07:37ZNick MathewsonImplement improved hidden service protocol (prop224)This is a parent ticket for implementing proposal 224-rend-spec-ng.txtThis is a parent ticket for implementing proposal 224-rend-spec-ng.txtTor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/7829Support all kinds of DNS over Tor2020-06-13T14:26:08ZproperSupport all kinds of DNS over TorPlease allow to request any kind of DNS over Tor through exit nodes.
DNSSEC, clear thing.
MX records example use case: Mixmaster over Tor.Please allow to request any kind of DNS over Tor through exit nodes.
DNSSEC, clear thing.
MX records example use case: Mixmaster over Tor.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7755circuit_t::timestamp_dirty should be cleaned up2020-06-13T14:25:45ZRobert Ransomcircuit_t::timestamp_dirty should be cleaned up`circuit_t::timestamp_dirty` is used in multiple bizarre ways, which should be reverse-engineered, documented, and cleaned up (probably by replacing it with multiple fields, each with a name which reflects its actual meaning and/or purpo...`circuit_t::timestamp_dirty` is used in multiple bizarre ways, which should be reverse-engineered, documented, and cleaned up (probably by replacing it with multiple fields, each with a name which reflects its actual meaning and/or purpose). See also the #7157 review discussion.
Also, is there a good reason for it to be in `circuit_t`, not `origin_circuit_t`? (Any use of it on `or_circuit_t`s (or even on service-side rendezvous `origin_circuit_t`s) would have different semantics.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7357Collect more statistics to better understand simulations2020-06-13T14:24:43ZRob JansenCollect more statistics to better understand simulationsOur simulations often lead to observations that indicate a lack of understanding of the results. This is because the information currently gathered is very high level: client download times and relay load.
We should start collecting mo...Our simulations often lead to observations that indicate a lack of understanding of the results. This is because the information currently gathered is very high level: client download times and relay load.
We should start collecting more information inside Tor that will allow a more complete analysis of a simulation to be able to say things about congestion, bottlenecks, and which nodes are responsible for certain behaviors. This should improve our ability to reason about future design changes and how they affect Tor's various statistical properties.
This standardize stats across simulations/real experiments/tor metrics.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7027Defend against Website Traffic Fingerprinting2020-06-13T14:23:19ZMike PerryDefend against Website Traffic FingerprintingWe should defend against Website Traffic Fingerprinting. I hear it's like a serious attack that is super dangerous because of its "devastating accuracy" of around 80% in closed-world research scenarios. I also hear that IDS/IPS systems a...We should defend against Website Traffic Fingerprinting. I hear it's like a serious attack that is super dangerous because of its "devastating accuracy" of around 80% in closed-world research scenarios. I also hear that IDS/IPS systems are the new new hotness, and soon we'll all be defended by 99.9% accurate IPS firewalls that will keep us safe from hackers forever. Look everybody, the 1990s are back in style again. Let's all move to Portland and retire.
But hey, there's no reason why we shouldn't work to improve the situation. Turns out there's a few bonus reasons to work on this problem... Who knew?
See child tickets for possible approaches, as well as things we've already tried.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6837More fine-grained modular decomposition2020-06-13T14:22:44ZNick MathewsonMore fine-grained modular decompositionWe should chop up our huger C files into smaller ones, based on actual module boundaries.
This will make it harder for us to merge pending branches that touch that code, but those are at a low ebb right now, so it's a good time.
The to...We should chop up our huger C files into smaller ones, based on actual module boundaries.
This will make it harder for us to merge pending branches that touch that code, but those are at a low ebb right now, so it's a good time.
The top 10 offenders in our current codebase are:
```
4614 src/or/rendservice.c
4839 src/or/channel.c
5200 src/or/connection.c
5386 src/or/or.h
5648 src/common/util.c
5666 src/or/directory.c
5688 src/or/routerparse.c
5771 src/or/routerlist.c
7223 src/or/control.c
8006 src/or/config.c
```
(updated May 2017)Tor: unspecified