Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:21Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34078Fix compilation warnings with clang 10.0.02020-06-13T15:53:21ZNick MathewsonFix compilation warnings with clang 10.0.0Fedora 32 includes Clang 10.0.0, which is a bit more strict about switch-statement fall-through annotations, and about converting enums to bools. This causes us to hit compilation warnings on all supported Tor versions.
(See also #3407...Fedora 32 includes Clang 10.0.0, which is a bit more strict about switch-statement fall-through annotations, and about converting enums to bools. This causes us to hit compilation warnings on all supported Tor versions.
(See also #34077 for the GCC version of this)Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33619Resolve TROVE-2020-0042020-06-13T15:52:14ZNick MathewsonResolve TROVE-2020-004This is a remotely triggerable memory leak on relays and clients, found by tobias pulls.
The issue is that when circpad_setup_machine_on_circ() is reached with an inconsistent internal configuration, it fails to free an object that is r...This is a remotely triggerable memory leak on relays and clients, found by tobias pulls.
The issue is that when circpad_setup_machine_on_circ() is reached with an inconsistent internal configuration, it fails to free an object that is replaced. It logs a bug warning, but that isn't enough.
Tobias Pulls found that this code was actually reachable, though, and results in a memory leak.Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33226Prop 311: 5. Declare Support for Subprotocol Version "Relay=3"2020-07-02T19:46:44ZteorProp 311: 5. Declare Support for Subprotocol Version "Relay=3"This ticket depends on relay IPv6 extends in #33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this proposal.
See p...This ticket depends on relay IPv6 extends in #33220.
We reserve Tor subprotocol "Relay=3" for tor versions where:
* relays may perform IPv6 extends, and
* bridges might not perform IPv6 extends,
as described in this proposal.
See proposal 311, section 5:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n601Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33159Write a proposal for monitoring IPv62020-06-13T15:50:42ZteorWrite a proposal for monitoring IPv6For sponsor 55, I need to write a proposal that covers these objectives:
* O1.4 - Measure the number of Tor relays that support IPv6 reachability checks (#33051)
* O1.5 - Measure the number of connections, and consumed bandwidth, using I...For sponsor 55, I need to write a proposal that covers these objectives:
* O1.4 - Measure the number of Tor relays that support IPv6 reachability checks (#33051)
* O1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 and IPv6 (#33052)
My current thinking is that:
* tor should log the number and consensus weight of relays that support IPv6 reachability checks, because we will need those numbers during testing
* these numbers are available in the consensus
Here's what the proposal requires:
* calculate relay IPv6 reachability numbers a few times during the project (we may as well use the tor logs)
* collect IPv6 connection and bandwidth statistics on tor relays
* calculate the IPv6 connection and bandwidth amounts a few times during the project
Here are some other useful things we might do:
* split the collected IPv6 statistics by client/relay
* calculate the guard-but-not-exit relays that support IPv6 client connections
* log IPv6 statistics in tor's heartbeat logs (we can't use these logs for our project reports, because they only show the local relay's statistics)
* calculate IPv6 reachability relay count and consensus weight on consensus-health
* add a pseudo-flag for relay IPv6 reachability support in Relay Search
* add metrics graphs that shows our progress on
* IPv6 reachability
* client IPv6 support on relays
* IPv6 connections and bandwidth
We definitely won't have time to do all of these optional things, so we should priorise, once the essential work is done.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33029dir-auth: Dir auths should resume sending 503's but never to relays or other ...2020-11-13T13:39:33ZDavid Gouletdgoulet@torproject.orgdir-auth: Dir auths should resume sending 503's but never to relays or other dir authsThis is a child ticket from #33018.
The idea here is that even if we hit the global write limit (bw), we should not return 503 code but rather answer another directory authority.
Dirauth _must_ be able to talk to each other at all time...This is a child ticket from #33018.
The idea here is that even if we hit the global write limit (bw), we should not return 503 code but rather answer another directory authority.
Dirauth _must_ be able to talk to each other at all time regardless of the bandwidth state.
Setting 043 milestone because this should be considered a bug and could even be considered for backport since dirauth are suffering from this at the moment.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32764Solve code issues that block running clang-format on our code.2020-06-13T15:49:10ZNick MathewsonSolve code issues that block running clang-format on our code.There are some aspects of our code that confuse clang-format, or produce bad output. In nearly all cases, this is a sign of bad code.There are some aspects of our code that confuse clang-format, or produce bad output. In nearly all cases, this is a sign of bad code.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32708manpage: alphabetize General Options2020-06-13T15:49:01ZTaylor Yumanpage: alphabetize General OptionsThis ticket is for Swati's alphabetizing change in #4310. Making this a child ticket so we can create other child tickets for working on alphabetizing the other sections.This ticket is for Swati's alphabetizing change in #4310. Making this a child ticket so we can create other child tickets for working on alphabetizing the other sections.Tor: 0.4.3.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/32366doxygen: use directory hierarchy, and start documenting directories2020-06-13T15:47:46ZNick Mathewsondoxygen: use directory hierarchy, and start documenting directoriesInitial work here in branch `doxygen_org`, PR at https://github.com/torproject/tor/pull/1492 .Initial work here in branch `doxygen_org`, PR at https://github.com/torproject/tor/pull/1492 .Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32209write description of config subsystem architecture2020-06-13T15:47:13ZTaylor Yuwrite description of config subsystem architectureTor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32206write high-level outline of target modular tor architecture2020-06-13T15:47:12ZTaylor Yuwrite high-level outline of target modular tor architectureTor: 0.4.3.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/32020hsv3: Client do not report failing circuit back into HS subsystem2020-06-13T15:47:43ZDavid Gouletdgoulet@torproject.orghsv3: Client do not report failing circuit back into HS subsystemThis is a subtask of the bigger larger problem in #25882.
A v2 client does report intro point failures within `circuit_about_to_free()` but not v3.
Actually, any HS circuit client side is not looked at. The `hs_circ_cleanup()` was inte...This is a subtask of the bigger larger problem in #25882.
A v2 client does report intro point failures within `circuit_about_to_free()` but not v3.
Actually, any HS circuit client side is not looked at. The `hs_circ_cleanup()` was intended for this as the entry point in the HS subsystem but only the service uses it.
Intro circuit failure needs to be noted in the failure cache (`hs_cache_client_intro_state_note()`).
Rendezvous circuit need to be also somehow handled. If the RP circuit keeps closing on us, we might want to stop trying maybe?
Same goes for HSDir circuit, if they close, client needs to be notified and launch a refetch.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31634Check .may_include order and tor subsystem init order are compatible2020-06-13T15:51:24ZteorCheck .may_include order and tor subsystem init order are compatibleIn #31615, we discovered that our module init order doesn't match their dependency order.
Let's use practracker and tor to make sure that doesn't happen again. We'll probably need a new make check target, because we'll need a compiled ...In #31615, we discovered that our module init order doesn't match their dependency order.
Let's use practracker and tor to make sure that doesn't happen again. We'll probably need a new make check target, because we'll need a compiled tor and practracker output. See #31615 for details.
Gaba, this is Sponsor 31-can, because it helps us catch refactoring bugs when we create new modules.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31176Teach practracker about .may_include files2020-06-13T15:43:37ZNick MathewsonTeach practracker about .may_include filesWe would like to introduce a second category of .may_include rules: those that should only apply on an advisory basis. We would treat violations of these rules as a best practices violation rather than an error. It would allow us to st...We would like to introduce a second category of .may_include rules: those that should only apply on an advisory basis. We would treat violations of these rules as a best practices violation rather than an error. It would allow us to start ratcheting down the number of layering violations.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30914Move struct manipulation code out of confparse.c2020-06-13T15:44:35ZNick MathewsonMove struct manipulation code out of confparse.cAfter I finish the variable-manipulation code in #30864, it's time to work on moving the struct-manipulation code out of confparse.cAfter I finish the variable-manipulation code in #30864, it's time to work on moving the struct-manipulation code out of confparse.cTor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30893Refactor and improve test coverage in confparse.c2020-06-13T15:42:37ZNick MathewsonRefactor and improve test coverage in confparse.cconfparse.c is at around 81% coverage, which is not too bad, but since we're refactoring it, we should probably improve its coverage.
As we do so, I'd like to remove unused configuration types, and rename the dubiously so called "UINT",...confparse.c is at around 81% coverage, which is not too bad, but since we're refactoring it, we should probably improve its coverage.
As we do so, I'd like to remove unused configuration types, and rename the dubiously so called "UINT", which is really an `int` restricted to nonnegative values.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30649Every few hours, relays [warn] Received circuit padding stop command for unkn...2020-06-13T15:41:53ZteorEvery few hours, relays [warn] Received circuit padding stop command for unknown machine.toralf says on #tor-relays:
```
I got 5x within last 36 ours with 0.4.1.1-alpha: [warn] Received circuit padding stop command for unknown machine. -shall I ignore that?
```
I'm marking this as 041-must, because we will get lots ...toralf says on #tor-relays:
```
I got 5x within last 36 ours with 0.4.1.1-alpha: [warn] Received circuit padding stop command for unknown machine. -shall I ignore that?
```
I'm marking this as 041-must, because we will get lots of bug reports from relay operators if we release a stable with this warning. At the very least, we must downgrade it to a protocol error.Tor: 0.4.0.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/30519Deterministic coverage on 0.4.12020-06-13T15:41:32ZNick MathewsonDeterministic coverage on 0.4.1I'd like us to have useful coverage diffs again.I'd like us to have useful coverage diffs again.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30459Let chutney tell Tor whether a network is supported2020-06-13T15:42:20ZNick MathewsonLet chutney tell Tor whether a network is supportedWe should do this anyway to simplify Tor's test-networks-all logic, but it will be helpful in order to have PT tests that can check whether the right PTs are installed.We should do this anyway to simplify Tor's test-networks-all logic, but it will be helpful in order to have PT tests that can check whether the right PTs are installed.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29894Initial split-up on control.c2020-06-13T15:39:48ZNick MathewsonInitial split-up on control.cAs a first step to refactoring control.c, let's split it up.As a first step to refactoring control.c, let's split it up.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29891Minor fixes from observed behaviour in the public network2020-06-13T16:15:48ZjugaMinor fixes from observed behaviour in the public networkIncluding them all in a ticket since they're quite small.Including them all in a ticket since they're quite small.sbws: 1.1.x-finaljugajuga