The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:49:57Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30935Move variable definition code out of confparse.c, and refactor2020-06-27T13:49:57ZNick MathewsonMove variable definition code out of confparse.c, and refactorTor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30926OnionPerf requests to onion service fail close towards completion with TGEN/R...2022-06-17T18:09:22ZKarsten LoesingOnionPerf requests to onion service fail close towards completion with TGEN/READ errorWe're currently investigating an issue where OnionPerf requests to onion service fail close towards completion with TGEN/READ error. I'm opening this ticket to attach/link the relevant logs. More (useful) information to follow.We're currently investigating an issue where OnionPerf requests to onion service fail close towards completion with TGEN/READ error. I'm opening this ticket to attach/link the relevant logs. More (useful) information to follow.https://gitlab.torproject.org/tpo/core/tor/-/issues/30924hs-v3: Implement proposal 305 - ESTABLISH_INTRO Cell DoS Defense Extension2021-06-23T17:24:14ZDavid Gouletdgoulet@torproject.orghs-v3: Implement proposal 305 - ESTABLISH_INTRO Cell DoS Defense ExtensionTicket for implementing prop305 (see legacy/trac#30790).Ticket for implementing prop305 (see legacy/trac#30790).Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/30921hs-v3: Close intro circuits when cleaning up the client descriptor cache2021-06-23T17:24:14ZDavid Gouletdgoulet@torproject.orghs-v3: Close intro circuits when cleaning up the client descriptor cacheIn legacy/trac#28970, one of the assert indicates that we are missing the `descriptor` object when the intro point circuit opened:
```
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth...In legacy/trac#28970, one of the assert indicates that we are missing the `descriptor` object when the intro point circuit opened:
```
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: Non-fatal assertion !(desc == NULL) failed in setup_intro_circ_auth_key at ../src/or/hs_client.c:624. Stack trace: (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x42) [0x56345cea26e2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb7) [0x56345cebd587] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_circuit_has_opened+0x2ca) [0x56345ce8027a] (on Tor 0.3.4.9 )
```
When a descriptor is removed from the client cache, the intro circuits aren't closed so there is a race where if it happens in the same main loop run that the client has an opened intro circuit for it, then it could lead to that assert.
Regardless of the cause of the assert or not, we should always close pending intro circuits when cleaning up a descriptor since once it opens, the client requires access to the descriptor object to complete the introduction (see `setup_intro_circ_auth_key()`).
Funny thought that we do that when we replace a descriptor from the client cache but not when we purge it...
This is a possible backport contender in order to avoid `BUG()` and failure of reachability client side.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/30920Detect uint64 overflow in config_parse_units()2020-06-27T13:49:58ZNick MathewsonDetect uint64 overflow in config_parse_units()The config_parse_units function uses 64-bit arithmetic, but does not detect 64-bit overflow. This means that values like "20000000 TB", which should be rejected, are instead mis-parsed.
Since this function is only used for configuratio...The config_parse_units function uses 64-bit arithmetic, but does not detect 64-bit overflow. This means that values like "20000000 TB", which should be rejected, are instead mis-parsed.
Since this function is only used for configuration parsing, it's not a huge issue, but it should be simple enough to resolve this.
Found while working on 30893.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30917Add instructions for making a new maint branch to EndOfLifeTor.md, and rename...2020-06-27T13:49:58ZteorAdd instructions for making a new maint branch to EndOfLifeTor.md, and rename the fileWhen we stop supporting a tor release, we follow the instructions in EndOfLifeTor.md.
But we don't have any instructions for a new maint branch or new release series.
Since the instructions are pretty similar, we should put them in EndO...When we stop supporting a tor release, we follow the instructions in EndOfLifeTor.md.
But we don't have any instructions for a new maint branch or new release series.
Since the instructions are pretty similar, we should put them in EndOfLifeTor.md, and then find a better name for that file.
Nick will write up a pad, and then I will put it in the file.
Gaba, I think this could be a Sponsor 31 task, because it is about best practices.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30916assert in dimap_add_entry()2020-07-14T22:24:14ZDavid Gouletdgoulet@torproject.orgassert in dimap_add_entry()From tor-relays@:
https://lists.torproject.org/pipermail/tor-relays/2019-June/017402.html
The stack trace is:
```
Jun 18 13:33:31.000 [notice] Bootstrapped 0%: Starting
Jun 18 13:33:32.000 [notice] Starting with guard context "defau...From tor-relays@:
https://lists.torproject.org/pipermail/tor-relays/2019-June/017402.html
The stack trace is:
```
Jun 18 13:33:31.000 [notice] Bootstrapped 0%: Starting
Jun 18 13:33:32.000 [notice] Starting with guard context "default"
============================================================ T= 1560854012
INTERNAL ERROR: Raw assertion failed at ../src/lib/ctime/di_ops.c:179: !
old_val/usr/bin/tor(dump_stack_symbols_to_error_fds+0x33)[0x55a17b410943]
/usr/bin/tor(tor_raw_assertion_failed_msg_+0x86)[0x55a17b410fd6]
/usr/bin/tor(dimap_add_entry+0xa0)[0x55a17b411ba0]
/usr/bin/tor(construct_ntor_key_map+0x69)[0x55a17b357969]
/usr/bin/tor(server_onion_keys_new+0x4d)[0x55a17b39f4dd]
/usr/bin/tor(+0x66e27)[0x55a17b287e27]
/usr/bin/tor(threadpool_new+0x18b)[0x55a17b3b3f0b]
/usr/bin/tor(cpu_init+0x9d)[0x55a17b28828d]
/usr/bin/tor(run_tor_main_loop+0x136)[0x55a17b27a496]
/usr/bin/tor(tor_run_main+0x1215)[0x55a17b27b935]
/usr/bin/tor(tor_main+0x3a)[0x55a17b278a8a]
/usr/bin/tor(main+0x19)[0x55a17b278609]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7ffb901ba2e1]
/usr/bin/tor(_start+0x2a)[0x55a17b27865a]
Jun 18 13:33:33.000 [notice] Tor 0.3.5.8 opening log file.
```
It appears that tor tried to add the same value in the `di_digest256_map_t` twice.
Logs indicate 0.3.5.8Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30914Move struct manipulation code out of confparse.c2020-06-27T13:49:58ZNick MathewsonMove struct manipulation code out of confparse.cAfter I finish the variable-manipulation code in legacy/trac#30864, it's time to work on moving the struct-manipulation code out of confparse.cAfter I finish the variable-manipulation code in legacy/trac#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/tpo/core/tor/-/issues/30901Add control port trace logging to tor2022-06-16T16:10:04ZteorAdd control port trace logging to torTo diagnose legacy/trac#30235, we need to be able to see what tor is sending and receiving on the control port.
I don't think that tor has any logging code for control port messages: I had a quick look, and there wasn't anything obvious...To diagnose legacy/trac#30235, we need to be able to see what tor is sending and receiving on the control port.
I don't think that tor has any logging code for control port messages: I had a quick look, and there wasn't anything obvious.
Showing each message at info level could be good, but it might also be risky?
Maybe we should safe_string_client() the actual message text.
nickm and catalyst are refactoring the controller code right now, so they might know where I should add the logging statements.https://gitlab.torproject.org/tpo/core/tor/-/issues/30894Memory leak on invalid CSV_INTERVAL value2020-06-27T13:49:58ZNick MathewsonMemory leak on invalid CSV_INTERVAL valueThere is a missing free in the case where we fail to parse the interval from a CSV_INTERVAL field.There is a missing free in the case where we fail to parse the interval from a CSV_INTERVAL field.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30893Refactor and improve test coverage in confparse.c2020-06-27T13:49:59ZNick 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/tpo/core/tor/-/issues/30890Make a useful .gitlab-ci.yml mirroring job2020-07-29T04:09:59ZTaylor YuMake a useful .gitlab-ci.yml mirroring jobThis continues work in legacy/trac#23756 to make a .gitlab-ci.yml job to usefully mirror a repository in a GitLab instance that doesn't support built-in mirroring (e.g., Community Edition).
See, e.g., ticket:23756#comment:4This continues work in legacy/trac#23756 to make a .gitlab-ci.yml job to usefully mirror a repository in a GitLab instance that doesn't support built-in mirroring (e.g., Community Edition).
See, e.g., ticket:23756#comment:4Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30889Eliminate some uses of lower-level control protocol output functions2020-06-27T13:49:59ZTaylor YuEliminate some uses of lower-level control protocol output functionsContinuing the work of legacy/trac#30007, refactor more control.c stuff to stop using lower-level control protocol output functions like `connection_write_str_to_buf()`, `connection_printf_to_buf()`, and `connection_buf_add()`.Continuing the work of legacy/trac#30007, refactor more control.c stuff to stop using lower-level control protocol output functions like `connection_write_str_to_buf()`, `connection_printf_to_buf()`, and `connection_buf_add()`.Tor: 0.4.2.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30875If you start Tor with UseBridges 1, no ClientTransportPlugin, and only obfs4 ...2020-06-27T13:49:59ZRoger DingledineIf you start Tor with UseBridges 1, no ClientTransportPlugin, and only obfs4 bridges, it should failIf you start your Tor client with just this line:
```
usebridges 1
```
it will refuse to start, because you gave it no bridges:
```
Jun 13 00:06:48.337 [warn] Failed to parse/validate config: If you set UseBridges, you must specify at le...If you start your Tor client with just this line:
```
usebridges 1
```
it will refuse to start, because you gave it no bridges:
```
Jun 13 00:06:48.337 [warn] Failed to parse/validate config: If you set UseBridges, you must specify at least one bridge.
Jun 13 00:06:48.337 [err] Reading config failed--see warnings above.
```
But if instead you start it with
```
usebridges 1
bridge obfs4 85.17.30.79:443 FC259A04A328A07FED1413E9FC6526530D9FD87A cert=RutxZlu8BtyP+y0NX7bAVD41+J/qXNhHUrKjFkRSdiBAhIHIQLhKQ2HxESAKZprn/lR3KA iat-mode=0
```
it will start up, trying to treat that bridge as a vanilla bridge:
```
Jun 13 00:10:23.164 [notice] Bootstrapped 0% (starting): Starting
Jun 13 00:10:23.278 [notice] Starting with guard context "bridges"
Jun 13 00:10:23.279 [notice] Delaying directory fetches: No running bridges
Jun 13 00:10:24.153 [notice] Bootstrapped 5% (conn): Connecting to a relay
Jun 13 00:10:24.247 [notice] Bootstrapped 10% (conn_done): Connected to a relay
```
That is, it's trying to connect to an ORPort on 85.17.30.79:443, presumably to fetch a bridge descriptor. Of course that isn't working because that's an obfs4 port.
Should Tor not count bridges for transports it doesn't have a ClientTransportPlugin line for, and if it ends up with no bridges that it knows how to use, refuse that configuration in the same way that it does now for no bridges?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30871circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ....2021-06-23T17:24:14Zs7rcircuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/feature/hs/hs_service.c:3166 (first at ../src/feature/hs/hs_service.c:2385)I experienced this today after normally turning on a machine that was off for physical movement. OS is Debian and Tor is set with systemctl to start on boot, so it's a normal out of the box boring setup. Internet was 100% working on the ...I experienced this today after normally turning on a machine that was off for physical movement. OS is Debian and Tor is set with systemctl to start on boot, so it's a normal out of the box boring setup. Internet was 100% working on the machine while it was booting up, and of course cable and correct network settings properly setup before powered on.
The Tor instance hosts 2 onion services, one v2 and one v3.
```
un 12 11:05:50.000 [notice] Tor 0.4.1.2-alpha-dev opening log file.
Jun 12 11:05:50.086 [notice] Tor 0.4.1.2-alpha-dev running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0j, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.1.2.
Jun 12 11:05:50.086 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 12 11:05:50.086 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Jun 12 11:05:50.086 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jun 12 11:05:50.086 [notice] Read configuration file "/etc/tor/torrc".
Jun 12 11:05:50.089 [notice] Opening Socks listener on 127.0.0.1:9050
Jun 12 11:05:50.089 [notice] Opened Socks listener on 127.0.0.1:9050
Jun 12 11:05:50.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Jun 12 11:05:50.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Jun 12 11:05:50.000 [notice] Bootstrapped 0% (starting): Starting
Jun 12 11:05:50.000 [notice] Starting with guard context "default"
Jun 12 11:05:50.000 [notice] Signaled readiness to systemd
Jun 12 11:05:51.000 [notice] Opening Control listener on /run/tor/control
Jun 12 11:05:51.000 [notice] Opened Control listener on /run/tor/control
Jun 12 11:05:51.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Jun 12 11:05:52.000 [warn] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 1; recommendation warn; host E9423220AAE845EE4B693A7C4235787C05D56280 at 185.117.82.23:9001)
Jun 12 11:05:52.000 [warn] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 2; recommendation warn; host 6B9EA8927AB6E94E216067E65372182343A5AFA2 at 62.210.83.207:8080)
Jun 12 11:05:52.000 [warn] 1 connections have failed:
Jun 12 11:05:52.000 [warn] 1 connections died in state connect()ing with SSL state (No SSL object)
Jun 12 11:05:55.000 [warn] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 3; recommendation warn; host 96CAA917F65BCD62CECD236F67652BFD7C69E52E at 104.37.193.102:443)
Jun 12 11:05:55.000 [warn] 2 connections have failed:
Jun 12 11:05:55.000 [warn] 2 connections died in state connect()ing with SSL state (No SSL object)
Jun 12 11:05:55.000 [warn] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 4; recommendation warn; host 73C62311F5650010A4D32E09F141A0B574EFCAF5 at 51.38.140.87:9001)
Jun 12 11:05:55.000 [warn] 3 connections have failed:
Jun 12 11:05:55.000 [warn] 3 connections died in state connect()ing with SSL state (No SSL object)
Jun 12 11:05:58.000 [warn] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 5; recommendation warn; host 2E23B75B9D9AB7B86D1D5AB1C9B6B30BA0E84E3E at 148.251.51.66:9001)
Jun 12 11:05:58.000 [warn] 4 connections have failed:
Jun 12 11:05:58.000 [warn] 4 connections died in state connect()ing with SSL state (No SSL object)
Jun 12 11:05:58.000 [warn] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 6; recommendation warn; host 7BE683E65D48141321C5ED92F075C55364AC7123 at 193.23.244.244:443)
Jun 12 11:05:58.000 [warn] 5 connections have failed:
Jun 12 11:05:58.000 [warn] 5 connections died in state connect()ing with SSL state (No SSL object)
Jun 12 11:06:01.000 [warn] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 7; recommendation warn; host 268216C455A8322E07733961A29110110958D1BF at 73.211.181.17:9001)
Jun 12 11:06:01.000 [warn] 6 connections have failed:
Jun 12 11:06:01.000 [warn] 6 connections died in state connect()ing with SSL state (No SSL object)
Jun 12 11:06:06.000 [warn] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 8; recommendation warn; host 7EA6EAD6FD83083C538F44038BBFA077587DD755 at 194.109.206.212:443)
Jun 12 11:06:06.000 [warn] 7 connections have failed:
Jun 12 11:06:06.000 [warn] 7 connections died in state connect()ing with SSL state (No SSL object)
Jun 12 11:06:09.000 [warn] Problem bootstrapping. Stuck at 5% (conn): Connecting to a relay. (No route to host; NOROUTE; count 9; recommendation warn; host FD2F9B881AC640100C428DF47DC9A863DC2F2536 at 37.187.17.67:9001)
Jun 12 11:06:09.000 [warn] 8 connections have failed:
Jun 12 11:06:09.000 [warn] 8 connections died in state connect()ing with SSL state (No SSL object)
Jun 12 11:06:13.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Jun 12 11:06:13.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Jun 12 11:06:13.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Jun 12 11:06:13.000 [notice] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
Jun 12 11:06:13.000 [notice] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
Jun 12 11:06:13.000 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
Jun 12 11:06:14.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Jun 12 11:06:15.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Jun 12 11:06:15.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Jun 12 11:06:16.000 [notice] Bootstrapped 100% (done): Done
Jun 12 11:06:21.000 [warn] Hidden service <XXX> exceeded launch limit with 10 intro points in the last 31 seconds. Intro circuit launches are limited to 10 per 300 seconds.
Jun 12 11:06:21.000 [warn] Service configured in "/var/lib/tor/<V2 service was here>":
Jun 12 11:06:21.000 [warn] Intro point 0 at [scrubbed]: circuit is open
Jun 12 11:06:21.000 [warn] Intro point 1 at [scrubbed]: circuit is open
Jun 12 11:06:21.000 [warn] Intro point 2 at [scrubbed]: circuit is waiting to see how other guards perform
Jun 12 11:06:21.000 [warn] Intro point 3 at [scrubbed]: circuit is waiting to see how other guards perform
Jun 12 11:06:21.000 [warn] Intro point 4 at [scrubbed]: circuit is waiting to see how other guards perform
Jun 12 11:11:19.000 [warn] Unknown introduction point auth key on circuit 3339485114 for service [scrubbed]
Jun 12 11:11:19.000 [warn] circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/feature/hs/hs_service.c:3166 (first at ../src/feature/hs/hs_service.c:2385) (on Tor 0.4.1.2-alpha-dev )
Jun 12 11:11:34.000 [warn] Unknown introduction point auth key on circuit 3672980732 for service [scrubbed]
Jun 12 11:11:34.000 [warn] circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/feature/hs/hs_service.c:3166 (first at ../src/feature/hs/hs_service.c:2385) (on Tor 0.4.1.2-alpha-dev )
Jun 12 12:44:47.000 [warn] Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Jun 12 12:44:49.000 [warn] Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Jun 12 12:44:49.000 [notice] Closing stream for '[scrubbed].onion': hidden service is unavailable (try again later).
```
The machine was off for more than 24 hours. It was simply shut down normally while Tor was running previously using sudo poweroff. The consensus it had on disk when it booted wasn't up to date any more of course. Somehow it wanted to connect to the guards first, but could not, even it had nothing blocking it. This is why it reported the bootstrapping problem and NOROUTE, when it Bootstrapped 100% Done, these messages stopped. Either there is something broken in how Tor starts up in some scenarios, either the network interface was not raised by the OS until after Tor service started, and then it was able to bootstrapp? I have tried to ping and traceroute all the IP addresses of the Guards that were printed in the log, and they were all available and reachable to me.
The most concerning message is **circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/feature/hs/hs_service.c:3166 (first at ../src/feature/hs/hs_service.c:2385) (on Tor 0.4.1.2-alpha-dev )** that needs fix.
Also: Unknown introduction point auth key on circuit 3339485114 for service [scrubbed] this is very interesting. I have absolutely no auth set up for neither the v3 neither the v2 hidden service.Tor: 0.4.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/30866Teach config.c to work with options configured in other modules2020-06-27T13:49:59ZNick MathewsonTeach config.c to work with options configured in other modulesThe last part of the groundwork for refactoring config.c will be to teach it about subsystems, so that it can find configuration options that it does not itself own. It needs to find them, parse them, validate them, pass them to the app...The last part of the groundwork for refactoring config.c will be to teach it about subsystems, so that it can find configuration options that it does not itself own. It needs to find them, parse them, validate them, pass them to the appropriate subsystems.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30865Move option-listing, setting, validation code out of confparse.c2020-06-27T13:49:59ZNick MathewsonMove option-listing, setting, validation code out of confparse.cThe code in confparse.c that handles individual options should move to src/lib so that other modules can use it. It should probably sit somewhere beneath src/log in the library graph, so that we can use it to configure everything.The code in confparse.c that handles individual options should move to src/lib so that other modules can use it. It should probably sit somewhere beneath src/log in the library graph, so that we can use it to configure everything.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30864Move variable manipulation code out of confparse.c2020-06-27T13:50:00ZNick MathewsonMove variable manipulation code out of confparse.cThere is some code in confparse.c for messing with arbitrary variables that ought to become general-purpose and go into lib/. This is a first step towards splitting config.c into reasonable pieces.There is some code in confparse.c for messing with arbitrary variables that ought to become general-purpose and go into lib/. This is a first step towards splitting config.c into reasonable pieces.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30860Add a chutney job that runs on macOS, so that IPv6 chutney tests work2020-06-27T13:50:00ZteorAdd a chutney job that runs on macOS, so that IPv6 chutney tests workTravis Linux doesn't support IPv6, so we should add a macOS chutney job to Tor's CI.
If that's too slow, we can:
* add the chutney tests to the end of an existing macOS job
* change the chutney job to macOS
Remember: each build has a l...Travis Linux doesn't support IPv6, so we should add a macOS chutney job to Tor's CI.
If that's too slow, we can:
* add the chutney tests to the end of an existing macOS job
* change the chutney job to macOS
Remember: each build has a limit of 2 concurrent macOS jobs.
We can do this task after legacy/trac#29280 merges.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30859Skip "make test" in Travis stem builds2020-06-27T13:50:00ZteorSkip "make test" in Travis stem buildsOnce legacy/trac#29280 merges, we want to write a separate branch that skips "make test" in stem builds.Once legacy/trac#29280 merges, we want to write a separate branch that skips "make test" in stem builds.Tor: 0.4.2.x-finalNick MathewsonNick Mathewson