Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:58:35Zhttps://gitlab.torproject.org/legacy/trac/-/issues/12595Finalize design for improved guard-node behavior2020-06-13T14:58:35ZGeorge KadianakisFinalize design for improved guard-node behaviorBugs like #12466 and #12450 have made it clear that the data structures and methods of the guard nodes code are not very robust. To fix those tickets with the current data structures, we would need even more kludges that would lower the ...Bugs like #12466 and #12450 have made it clear that the data structures and methods of the guard nodes code are not very robust. To fix those tickets with the current data structures, we would need even more kludges that would lower the code quality.
This is a ticket about finding a more elegant approach to keeping entry guards and directory guards.
I'm putting this in 0.2.6 milestone because it's important, but it might get deferred if it's too much work.Tor: 0.3.0.x-finalGeorge KadianakisGeorge Kadianakishttps://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/16792Have a way to mark lines as "unreachable by unit tests"2020-06-13T15:15:02ZNick MathewsonHave a way to mark lines as "unreachable by unit tests"It would be great to have a way to tell the test coverage code "this line won't be reached by tests, so don't worry about it." This would let us have a prayer of reaching 100%.It would be great to have a way to tell the test coverage code "this line won't be reached by tests, so don't worry about it." This would let us have a prayer of reaching 100%.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17158Run an opt-in process for fallback directories2020-06-13T18:13:30ZteorRun an opt-in process for fallback directories
* Draft an email requesting that relay operators opt-in their ID and IP as a fallback directory
* Convince someone @ torproject.org to send the email to tor-relays
* someone @ torproject.org collates responses and adds them to the white...
* Draft an email requesting that relay operators opt-in their ID and IP as a fallback directory
* Convince someone @ torproject.org to send the email to tor-relays
* someone @ torproject.org collates responses and adds them to the whitelist
* Once we have enough whitelist entries, we merge the whitelisted fallback directories into the codeTor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/12538Make all relays automatically be dir caches2020-06-13T18:13:30ZcypherpunksMake all relays automatically be dir cachesDuring the entry guard discussions, we have decided that it's a good idea to make all relays directory servers. We mainly needed the entry guards to be directories, but it seems easier and more elegant to just turn all relays to director...During the entry guard discussions, we have decided that it's a good idea to make all relays directory servers. We mainly needed the entry guards to be directories, but it seems easier and more elegant to just turn all relays to directory servers.
This is easier nowadays than in the past because `BEGIN_DIR` makes it so that directory servers don't need to have a separate DirPort open. (However, maybe relays get the `V2Dir` flag only if they have a DirPort open?)
Also, since all relays have all the directory documents anyway, it doesn't further bloat their disk to become directory servers.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14881incorrect defaults when producing bandwidth-weights line in directory footer2020-07-31T12:42:39ZRob Jansenincorrect defaults when producing bandwidth-weights line in directory footerWhen running Tor in small testing networks, much of the time the bandwidth-weights line does not appear in the directory-footer in the consensus files. The log file shows messages like this:
```
Consensus with empty bandwidth: G=852123 ...When running Tor in small testing networks, much of the time the bandwidth-weights line does not appear in the directory-footer in the consensus files. The log file shows messages like this:
```
Consensus with empty bandwidth: G=852123 M=0 E=0 D=569253 T=1421376
```
The code that counts up these bandwidth values is in `networkstatus_compute_consensus` in `dirvote.c`, specifically around [line 1590 in Tor master as of now](https://gitweb.torproject.org/tor.git/tree/src/or/dirvote.c#n1590).
The code that prints this error is in `networkstatus_compute_bw_weights_v10` in `dirvote.c`.
I believe that it is an error not to produce bandwidth-weights in the event that we have no knowledge of bandwidth for a given position. For example, if D is zero because there are no nodes that serve as exits+guards, shouldn't we just adjust the weights accordingly? We may still have functional guards and functional exits just because we have no node that serves as both.
Since this is for weighting purposes, why are T, D, E, G, and M all initialized to 0 instead of 1? I think the default weight should be 1, meaning all positions are selected equally, and any bandwidth above 1 should be used to increase the weight. Does this sound right?
If that is not desired, then I request that we at least initialize these values to one for testing networks. One patch is attached for each of these options.Tor: 0.3.0.x-finalpastlypastlyhttps://gitlab.torproject.org/legacy/trac/-/issues/11150Remove client code for connecting to and using 0.2.2 servers2020-07-31T12:53:28ZNick MathewsonRemove client code for connecting to and using 0.2.2 serversWe can finally drop support for the client-side V2 link handshake!We can finally drop support for the client-side V2 link handshake!Tor: 0.2.8.x-finalTvdWTvdWhttps://gitlab.torproject.org/legacy/trac/-/issues/15545Document TOR_PT_EXIT_ON_STDIN_CLOSE in the pt-spec.2021-11-15T18:55:15ZYawning AngelDocument TOR_PT_EXIT_ON_STDIN_CLOSE in the pt-spec.This is the ticket for the documentation side of the `TOR_PT_EXIT_ON_STDIN_CLOSE` and associated behavior that was implemented as part of #15435.
`pt-spec.txt` needs to document that if the env var is set to `1`, then PTs should assume ...This is the ticket for the documentation side of the `TOR_PT_EXIT_ON_STDIN_CLOSE` and associated behavior that was implemented as part of #15435.
`pt-spec.txt` needs to document that if the env var is set to `1`, then PTs should assume that tor will keep stdin open, and to treat stdin being closed as the same as a `SIGTERM` (graceful shutdown immediately).Tor: 0.2.8.x-finalYawning AngelYawning Angel