Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:51:45Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33414Split router.c, and disable it (mostly) when building without relay support.2020-06-13T15:51:45ZNick MathewsonSplit router.c, and disable it (mostly) when building without relay support.The last _big_ piece of code in feature/relay that we want to turn off when --disable-module-relay is set is `router.c`.The last _big_ piece of code in feature/relay that we want to turn off when --disable-module-relay is set is `router.c`.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33389Disable routerkeys.c and part of connection_or.c when building without relay ...2020-06-13T15:51:38ZNick MathewsonDisable routerkeys.c and part of connection_or.c when building without relay mode.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33370Don't build selftest.c when relay mode is disabled2020-06-13T15:51:34ZNick MathewsonDon't build selftest.c when relay mode is disabledTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33368Don't compile ext_orport.c when relay mode is disabled.2020-06-13T15:51:33ZNick MathewsonDon't compile ext_orport.c when relay mode is disabled.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33366Disable dns.c when relay mode is disabled2020-06-13T15:51:32ZNick MathewsonDisable dns.c when relay mode is disabledTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32907Remove or_options_t dependencies from module config headers2020-06-13T15:49:50ZteorRemove or_options_t dependencies from module config headersThe following inline header functions depend on some members of or_options_t, which is a dependency we don't need:
* options_validate_dirauth_mode()
* options_validate_server_transport()
* options_validate_relay_mode()
And the dependency...The following inline header functions depend on some members of or_options_t, which is a dependency we don't need:
* options_validate_dirauth_mode()
* options_validate_server_transport()
* options_validate_relay_mode()
And the dependency only exists when the relay or dirauth modules are disabled.
Instead, we could put these functions in stub C files, which are only compiled when relay/dirauth mode is disabled.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32888Log address config info when tor starts up2020-06-13T15:49:47ZteorLog address config info when tor starts upWe're going to be modifying tor's address detection and reachability code for an upcoming sponsor. To help us debug, we should log the following info when tor starts up:
IPv4:
* the `Address` torrc option
* and whether it is an IP add...We're going to be modifying tor's address detection and reachability code for an upcoming sponsor. To help us debug, we should log the following info when tor starts up:
IPv4:
* the `Address` torrc option
* and whether it is an IP address, or a DNS name
* the local hostname
* and whether it is an IP address, or a DNS name
* the local network interface addresses
See `resolve_my_address()` for details.
IPv6:
* the IPv6 address of the first IPv6 `ORPort` torrc option
See `router_build_fresh_descriptor()` and `router_get_advertised_ipv6_or_ap()` (in #32588) for details.
When (or if) we use them as part of address detection, we should also log the following info:
IPv4 and IPv6:
* the `Address` torrc option
* and whether it is an IP address, or a DNS name
* the IPv4 and IPv6 addresses of the first `ORPort` torrc option of each address family
* the local hostname
* and whether it is an IP address, or a DNS name
* the local network interface addresses
Notes:
* We'll need a proposal to decide if `ORPort` or hostname should come first
* We'll probably want a summary at notice level, and then detailed logs at info level
* If all these methods fail, relays use `X-Your-Address-Is:` headers from directory authorities. They are out of scope, because they are not available at startup.
* Similarly, we won't print address reachability self-testing info, because it's not available at startup.
* We may want to print similar log messages (including `X-Your-Address-Is:` and reachability info) as part of tor's regular heartbeat messages. But that deserves a separate ticket.
I don't think we'll use (or log):
* the addresses of any `DirPort` torrc options
* the addresses of multiple `ORPort` torrc optionsTor: unspecifiedcchttps://gitlab.torproject.org/legacy/trac/-/issues/32880V3 handshaking state change doesn't use "connection_or_change_state()"2020-06-13T15:49:44ZoparaV3 handshaking state change doesn't use "connection_or_change_state()"When an OR connection [acting as a server changes to state](https://github.com/torproject/tor/blob/8c23ac4ae713f7cce7cd7541d2ae635c50c7c062/src/core/or/channeltls.c#L1419) `OR_CONN_STATE_OR_HANDSHAKING_V3`, it does so by setting `conn->b...When an OR connection [acting as a server changes to state](https://github.com/torproject/tor/blob/8c23ac4ae713f7cce7cd7541d2ae635c50c7c062/src/core/or/channeltls.c#L1419) `OR_CONN_STATE_OR_HANDSHAKING_V3`, it does so by setting `conn->base_.state` directly and not using `connection_or_change_state()`, so afaict this state change is never passed to pubsub or to the channel object.
On the other hand, when changing to that same state [when acting as a client](https://github.com/torproject/tor/blob/8c23ac4ae713f7cce7cd7541d2ae635c50c7c062/src/core/or/connection_or.c#L2150), it does use `connection_or_change_state()` as expected.
This seems to me to be a bug, but maybe there was a good reason for doing it this way. Also it seems no one has complained about it since the code was added, so having it changed doesn't seem to be important. But documenting here anyways since someone may want to take a look at it at some point.Tor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32850Channel padding timeout scheduled xxx ms in the past.2020-06-13T15:49:38ZTracChannel padding timeout scheduled xxx ms in the past.```
07:13:16 [NOTICE] Channel padding timeout scheduled 146141ms in the past.
```
I get them since months already on different relays. Minimum since 0.4.0.5. Maybe earlier.
Probably related to #22212#comment:48
Most of the time its on...```
07:13:16 [NOTICE] Channel padding timeout scheduled 146141ms in the past.
```
I get them since months already on different relays. Minimum since 0.4.0.5. Maybe earlier.
Probably related to #22212#comment:48
Most of the time its only one message. Sometimes a few messages in a row at the same second like you can see it in #22212#comment:49 too.
**Trac**:
**Username**: computer_freakTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32814Possibly, move V3AuthUseLegacyKey into dirauth module2020-06-13T15:49:26ZNick MathewsonPossibly, move V3AuthUseLegacyKey into dirauth moduleThis option is also used in router.c, where maybe it should not be.This option is also used in router.c, where maybe it should not be.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32813Move V3BandwidthsFile into feature/dirauth module2020-06-13T15:49:26ZNick MathewsonMove V3BandwidthsFile into feature/dirauth moduleThis change will take some code movement, because the option is also used in dircache.c.This change will take some code movement, because the option is also used in dircache.c.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32812Move authority-mode options into dirauth module2020-06-13T15:49:26ZNick MathewsonMove authority-mode options into dirauth moduleThese are "v3authoritativedirectory" and "bridgeauthoritativedir".
Also we should be away that lots of the code indirectly asks "are we an authority": that should probably be something that we reconsider or redesign. We don't _want_ m...These are "v3authoritativedirectory" and "bridgeauthoritativedir".
Also we should be away that lots of the code indirectly asks "are we an authority": that should probably be something that we reconsider or redesign. We don't _want_ most modules invoking the authority module.
This might also mean that authmode.c belongs in src/core? There could be a better solution here.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32810Move timing-related authority options into dirauth module2020-06-13T15:49:25ZNick MathewsonMove timing-related authority options into dirauth moduleWe should concentrate all of the options related to vote timing into the dirauth module.
Some of these will turn out to belong in voting_schedule.c: we'll need to be careful.
The ones I know of are:
* TestingV3AuthInitialDistDelay
...We should concentrate all of the options related to vote timing into the dirauth module.
Some of these will turn out to belong in voting_schedule.c: we'll need to be careful.
The ones I know of are:
* TestingV3AuthInitialDistDelay
* TestingV3AuthInitialVoteDelay
* TestingV3AuthInitialVotingInterval
* TestingV3AuthVotingStartOffset
* V3AuthDistDelay
* V3AuthNIntervalsValid
* V3AuthVoteDelay
* V3AuthVotingIntervalTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32809Move AuthDir* policy entries into feature/dirauth2020-06-13T15:49:25ZNick MathewsonMove AuthDir* policy entries into feature/dirauthRight now, there are several dirauth-related configuration options that are handled in policies.c. We should move them into dirauth.Right now, there are several dirauth-related configuration options that are handled in policies.c. We should move them into dirauth.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32798Compile every header by itself as part of "make check"2020-06-13T15:49:21ZteorCompile every header by itself as part of "make check"In #32764, we need to make sure that some headers include their dependencies (or remove those dependencies), so that clang-format can re-order headers.
We should compile every header by itself, to check that it lists all its dependencie...In #32764, we need to make sure that some headers include their dependencies (or remove those dependencies), so that clang-format can re-order headers.
We should compile every header by itself, to check that it lists all its dependencies. Some headers contain conditional code, so we also need to compile with and without:
* HAVE_MODULE_* (already in CI, as long as we use the defined from configure)
* *{INTERNAL,PRIVATE,EXPOSE}* (not sure how to do this in CI, I guess we could script it using grep)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32784Find and remove upward dependencies in our codebase2020-06-13T15:49:16ZNick MathewsonFind and remove upward dependencies in our codebaseThis is a placeholder parent ticket for finding particular places in our code where a lower-level module uses a higher-level module. We should open sub-tickets for particular items.
This ticket is meant to be one of our roadmapped item...This is a placeholder parent ticket for finding particular places in our code where a lower-level module uses a higher-level module. We should open sub-tickets for particular items.
This ticket is meant to be one of our roadmapped items between now and our March meeting.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32655Try finding unused includes by compiling without each include2020-06-13T15:48:46ZteorTry finding unused includes by compiling without each includeIn #32522, we deleted some includes and PRIVATE defines, because they were duplicate (or the defines were never actually checked in the headers).
But we could go further, using this algorithm:
1. Make sure all the files are sorted
2. Fi...In #32522, we deleted some includes and PRIVATE defines, because they were duplicate (or the defines were never actually checked in the headers).
But we could go further, using this algorithm:
1. Make sure all the files are sorted
2. Find all the includes (and maybe PRIVATE defines)
3. Delete the first include
4. Try compiling
5. If the include is required to compile, revert
6. Try again from step 3, with the next include
We'd need to skip conditional includes, and check the results in CI before merging.
I'll wait until #32522 is reviewed, and also see if we want this task on our roadmap.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32611Use J= to parallelise coccinelle2020-06-13T15:48:35ZteorUse J= to parallelise coccinelleIf we feed coccinelle all our files at the same time, and use the J=N variable, we can parallelise the (slow) parsing checks.
This isn't usually a big deal for the commit hook or makefile, because the commit hook only checks changed fil...If we feed coccinelle all our files at the same time, and use the J=N variable, we can parallelise the (slow) parsing checks.
This isn't usually a big deal for the commit hook or makefile, because the commit hook only checks changed files, and the Makefile already runs "make check" in parallel.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32610Add macro spacing checks to "make check-spaces"2020-06-13T15:48:35ZteorAdd macro spacing checks to "make check-spaces"Let's check macro spacing like we check other keyword spacing.
And let's check for `else {`.Let's check macro spacing like we check other keyword spacing.
And let's check for `else {`.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32604Add HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directive2020-06-13T15:48:33ZTracAdd HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directiveAdd HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directive to export rendezvous point information and instance ID along with circuit ID
**Trac**:
**Username**: moonsikparkAdd HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directive to export rendezvous point information and instance ID along with circuit ID
**Trac**:
**Username**: moonsikparkTor: unspecified