The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-15T13:41:34Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30992circpadding machines have shutdown sync issues (with intro circ NACKs and oth...2021-07-15T13:41:34ZGeorge Kadianakiscircpadding machines have shutdown sync issues (with intro circ NACKs and other cases)When client-side intro circuits get NACKed they re-extend to a different intro point using the same circuit.
This seems to mess up the circsetup machines and we get "padding came from wrong hop" log warns.When client-side intro circuits get NACKed they re-extend to a different intro point using the same circuit.
This seems to mess up the circsetup machines and we get "padding came from wrong hop" log warns.Tor: 0.4.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30991Auto-tabify makefiles? complain about mistabbed makefiles?2020-10-22T15:51:44ZNick MathewsonAuto-tabify makefiles? complain about mistabbed makefiles?We have a bunch of lists in our makefile.am and include.am files where we intend to use tabs, but sometimes use spaces by mistake. We should have tooling to keep these consistent. We could either have check-local look for mis-tabbed fi...We have a bunch of lists in our makefile.am and include.am files where we intend to use tabs, but sometimes use spaces by mistake. We should have tooling to keep these consistent. We could either have check-local look for mis-tabbed files of this type, or have autostyle automatically fix them for us.Tor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/30990checkSpace.pl: clean up our list of types2020-07-29T04:13:57ZNick MathewsoncheckSpace.pl: clean up our list of typescheckSpace.pl has a list of types that are returned from function pointers, and uses it so that we don't complain about code like this:
```
bool (*eq)(const void *a, const void *b);
```
(Without recognizing that bool is a type, practr...checkSpace.pl has a list of types that are returned from function pointers, and uses it so that we don't complain about code like this:
```
bool (*eq)(const void *a, const void *b);
```
(Without recognizing that bool is a type, practracker would think that we were calling a function named "bool", and complain that we had a space after a function call.)
In their review for legacy/trac#30864, catalyst notes that the current code in checkSpace.pl for this is unweildy, and suggests that we use a list instead. I concur.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30987[PATCH] Add support for seccomp on powerpc642022-06-16T15:26:29ZTrac[PATCH] Add support for seccomp on powerpc64Attached is a small patch to enable support for building tor with seccomp on the ppc64 and ppc64le architectures.
**Trac**:
**Username**: shawnanastasioAttached is a small patch to enable support for building tor with seccomp on the ppc64 and ppc64le architectures.
**Trac**:
**Username**: shawnanastasiohttps://gitlab.torproject.org/tpo/core/tor/-/issues/30984Make a key-value line abstraction to output control replies2020-06-27T13:49:55ZTaylor YuMake a key-value line abstraction to output control repliesA few controller commands still use `connection_buf_add()` or similar low-level functions after constructing a list of reply lines. Almost all of these are key-value pairs. Create a new abstraction to output these, including by automatic...A few controller commands still use `connection_buf_add()` or similar low-level functions after constructing a list of reply lines. Almost all of these are key-value pairs. Create a new abstraction to output these, including by automatically including the correct separator character between the numeric code and the rest of the line.Tor: 0.4.3.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30983http-header Leak2020-06-27T13:49:55Zcypherpunkshttp-header LeakThe http-header is leaked once another software but Torbrowser is used (e.g. a messenger, a FTP-program, subversion...).
The http-header anonymization thus should be implemented in Tor, not in Torbrowser.The http-header is leaked once another software but Torbrowser is used (e.g. a messenger, a FTP-program, subversion...).
The http-header anonymization thus should be implemented in Tor, not in Torbrowser.https://gitlab.torproject.org/tpo/core/tor/-/issues/30979pre-push hook runs practracker unconditionally2020-06-27T13:49:55ZNick Mathewsonpre-push hook runs practracker unconditionallyOur pre-push hook script runs practracker whenever it exists. But we only want to run practracker on branches that are targeted for master.
I think perhaps we should change it to try making check-local? Or perhaps it could check for ...Our pre-push hook script runs practracker whenever it exists. But we only want to run practracker on branches that are targeted for master.
I think perhaps we should change it to try making check-local? Or perhaps it could check for the existence of some other file that we could use to indicate whether we want practracker to run.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30968Refactor unit test asserts so they log context2021-09-16T14:23:38ZteorRefactor unit test asserts so they log contextIn legacy/trac#30721, I created some complex macros to preserve line numbers when the unit tests fail.
We could refactor these macros into functions, if the tiny test assertions supported context.
catalyst suggests allowing file and li...In legacy/trac#30721, I created some complex macros to preserve line numbers when the unit tests fail.
We could refactor these macros into functions, if the tiny test assertions supported context.
catalyst suggests allowing file and line numbers (and functions?):
> I think I see that the problem is buried in the `TT_DECLARE()` macro in `tinytest_macros.h`. I think it's possible to work around it, but it might be nontrivial. (Rough sketch: redefine `TT_DECLARE()` in helper functions to read file and line info from function parameters, and make file and line numbers explicit parameters to helper functions.)
I suggest allowing a format string, which could also print the data that we're testing. (For the tor_addr_port_lookup() tests, the best context is the address string.)https://gitlab.torproject.org/tpo/core/tor/-/issues/30967Make shellcheck ignore user-created directories, and run it during pre-commit2020-06-27T13:49:55ZteorMake shellcheck ignore user-created directories, and run it during pre-commitAt the moment, we shellcheck all the directories inside the tor directory, even user directories like .git, user-specified build directories, and directories that are added during tests.
This change will conflict with legacy/trac#30963,...At the moment, we shellcheck all the directories inside the tor directory, even user directories like .git, user-specified build directories, and directories that are added during tests.
This change will conflict with legacy/trac#30963, so it should be based on that branch.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30964Fix shellcheck warning about unused variable in test_rebind.sh2020-06-27T13:49:55ZNick MathewsonFix shellcheck warning about unused variable in test_rebind.sh```
In ./src/test/test_rebind.sh line 15:
exitcode=0
^------^ SC2034: exitcode appears unused. Verify use (or export if used externally).
```
I say "no backport" since this is harmless.```
In ./src/test/test_rebind.sh line 15:
exitcode=0
^------^ SC2034: exitcode appears unused. Verify use (or export if used externally).
```
I say "no backport" since this is harmless.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30963Shellcheck tests should exclude src/rust/registry2020-06-27T13:49:56ZNick MathewsonShellcheck tests should exclude src/rust/registryThere are shell scripts that can get downloaded into src/rust/registry, but they are not in our control: we should tell shellcheck not to look at them.There are shell scripts that can get downloaded into src/rust/registry, but they are not in our control: we should tell shellcheck not to look at them.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30959Add comments about the chunk format in extrainfo_dump_to_string()2020-06-27T13:49:56ZteorAdd comments about the chunk format in extrainfo_dump_to_string()I want to add some extra comments about legacy/trac#30958, after we merge legacy/trac#30956.
So I opened this ticket for the pull request and merge.I want to add some extra comments about legacy/trac#30958, after we merge legacy/trac#30956.
So I opened this ticket for the pull request and merge.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30958Stop removing the ed25519 signature when the extra-info file is too big2020-06-27T13:49:56ZteorStop removing the ed25519 signature when the extra-info file is too bigIn legacy/trac#30956, I discovered that the ed25519 signature extra-info line is
split across two chunks.
If the extra-info file gets too big, tor removes one chunk at a time. So each chunk needs to be a complete line.
Edit: but in thi...In legacy/trac#30956, I discovered that the ed25519 signature extra-info line is
split across two chunks.
If the extra-info file gets too big, tor removes one chunk at a time. So each chunk needs to be a complete line.
Edit: but in this case, we should just stop removing the signatureTor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30956Publish bridge ServerTransportPlugin lines, even when ExtraInfoStatistics are...2020-06-27T13:49:56ZteorPublish bridge ServerTransportPlugin lines, even when ExtraInfoStatistics are offIn legacy/trac#29018, we disabled all extrainfo contents when ExtraInfoStatistics is off.
But we need to publish the ServerTransportPlugin lines for bridges, even when their statistics are off.
See https://trac.torproject.org/projects/...In legacy/trac#29018, we disabled all extrainfo contents when ExtraInfoStatistics is off.
But we need to publish the ServerTransportPlugin lines for bridges, even when their statistics are off.
See https://trac.torproject.org/projects/tor/ticket/30441#comment:13 for details.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30955Update the fallback entry in the man page2021-07-22T16:19:44ZteorUpdate the fallback entry in the man page"FallbackDir ipv4address:port"
"FallbackDir ipv4address:dirport"
"DirAuthority [nickname] [flags] ipv4address:port"
"DirAuthority [nickname] [flags] ipv4address:dirport"
And similarly for orport.
"The provided port value is a dirport;..."FallbackDir ipv4address:port"
"FallbackDir ipv4address:dirport"
"DirAuthority [nickname] [flags] ipv4address:port"
"DirAuthority [nickname] [flags] ipv4address:dirport"
And similarly for orport.
"The provided port value is a dirport; clients ignore this in favor of the specified "orport=" value."
"Clients always use the orport. Relays prefer the dirport, but will use the orport in some circumstances."
Add something to the FallbackDir entry talking about how the DirPort is used by the checking script?Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30954Address torrc option is ignored if set second time for the IPv6 address2020-06-27T13:49:56Zs7rAddress torrc option is ignored if set second time for the IPv6 addressCurrently if we specify `Address` 2 times in the same torrc, once for IPv4 address and once for IPv6 address, it will just ignore the second entry as like it would be for the same IP family:
```
[warn] Option 'Address' used more than on...Currently if we specify `Address` 2 times in the same torrc, once for IPv4 address and once for IPv6 address, it will just ignore the second entry as like it would be for the same IP family:
```
[warn] Option 'Address' used more than once; all but the last value will be ignored.
```
This behavior is perfect for cases where operators specify more addresses from the same family (like IPv4 for example) in the same torrc. I am marking this Low priority because it's here only to remind us about it when IPv6 autodetection will be implemented.
I know currently does not do IPv6 address detection so I am guessing this is why it currently does not care to learn about an IPv6 address from `Address` torrc setting, and only from `ORPort` to build just descriptors and be optimistic about getting the ReachableIPv6 flag, but when this changes it should be possible to specify `Address` 2 times in torrc, once for IPv4 and once for IPv6, the same as for `OutboundBindAddress | OutboundBindAddressOR | OutboundBindAddressExit`.Tor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/30953ServerTransportListenAddr is ignored when stated second time for the IPv6 add...2020-06-27T13:49:57Zs7rServerTransportListenAddr is ignored when stated second time for the IPv6 addressCurrently is possible to run a dual stacked IPv4 + IPv6 bridge.
`ORPort` can be set 2 times in torrc, once for IPv4 and once for IPv6 - it will open ports on both address families and listen for connections.
However, `ServerTransportLi...Currently is possible to run a dual stacked IPv4 + IPv6 bridge.
`ORPort` can be set 2 times in torrc, once for IPv4 and once for IPv6 - it will open ports on both address families and listen for connections.
However, `ServerTransportListenAddr` will only work for IPv4 and be ignored if set second time in the same torrc for the IPv6 family (no obfs4 port open on the IPv6 address).
Log file does not even mention it, it only confirms the IPv4 one:
[notice] Registered server transport 'obfs4' at '<xxx>:port'Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30950shellcheck: SC2034 in test_rebind.sh2020-06-27T13:49:57Zrl1987shellcheck: SC2034 in test_rebind.sh```
In ./src/test/test_rebind.sh line 15:
exitcode=0
^-- SC2034: exitcode appears unused. Verify it or export it.
```
https://travis-ci.org/rl1987/tor/jobs/549320620```
In ./src/test/test_rebind.sh line 15:
exitcode=0
^-- SC2034: exitcode appears unused. Verify it or export it.
```
https://travis-ci.org/rl1987/tor/jobs/549320620Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30949Add the source= line to the dir list spec2020-06-27T13:49:57ZteorAdd the source= line to the dir list specIn legacy/trac#30947, we added a source line to the fallback file header.
Now we need to update the spec.In legacy/trac#30947, we added a source line to the fallback file header.
Now we need to update the spec.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30942[warn] Unexpected INTRODUCE_ACK on circuit 3944288021.2021-06-23T17:24:14ZRoger Dingledine[warn] Unexpected INTRODUCE_ACK on circuit 3944288021.Running
```
Jun 19 01:26:41.987 [notice] Tor 0.4.2.0-alpha-dev (git-438b7eec856b0cac) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1c, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
```
Looking at my debug-level logs, here are s...Running
```
Jun 19 01:26:41.987 [notice] Tor 0.4.2.0-alpha-dev (git-438b7eec856b0cac) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1c, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
```
Looking at my debug-level logs, here are some lines that look relevant:
```
Jun 20 14:42:15.423 [info] rend_client_introduction_acked(): Received ack. Telling rend circ...
Jun 20 14:42:15.423 [debug] circuit_change_purpose(): changing purpose of origin circ 87 from "Hidden service client: Pending rendezvous point" (10) to "Hidden service client: Pending rendezvous point (ack received)" (11)
Jun 20 14:42:15.423 [debug] circuit_change_purpose(): changing purpose of origin circ 88 from "Hidden service client: Waiting for ack from intro point" (7) to "Hidden service client: Received ack from intro point" (8)
Jun 20 14:42:15.423 [debug] circuit_get_by_circid_channel_impl(): circuit_get_by_circid_channel_impl() returning circuit 0x562673bfdc90 for circ_id 2983373670, channel ID 29 (0x562674553c80)
Jun 20 14:42:15.423 [info] circuit_mark_for_close_(): Circuit 2983373670 (id: 88) marked for close at src/feature/rend/rendclient.c:418 (orig reason: 9, new reason: 0)
Jun 20 14:42:15.423 [info] rend_client_close_other_intros(): Closing introduction circuit 90 that we built in parallel (Purpose 7).
Jun 20 14:42:15.423 [debug] circuit_get_by_circid_channel_impl(): circuit_get_by_circid_channel_impl() returning circuit 0x562673c1d930 for circ_id 3944288021, channel ID 29 (0x562674553c80)
Jun 20 14:42:15.423 [info] circpad_marked_circuit_for_padding(): Circuit 90 is not marked for close because of a pending padding machine.
Jun 20 14:42:15.423 [debug] circuit_change_purpose(): changing purpose of origin circ 90 from "Hidden service client: Waiting for ack from intro point" (7) to "Circuit kept open for padding" (15)
[...]
Jun 20 14:42:15.470 [debug] connection_or_process_cells_from_inbuf(): 13: starting, inbuf_datalen 514 (0 pending in tls object).
Jun 20 14:42:15.470 [debug] channel_process_cell(): Processing incoming cell_t 0x7ffc169e5030 for channel 0x562674553c80 (global ID 29)
Jun 20 14:42:15.470 [debug] circuit_get_by_circid_channel_impl(): circuit_get_by_circid_channel_impl() returning circuit 0x562673c1d930 for circ_id 3944288021, channel ID 29 (0x562674553c80)
Jun 20 14:42:15.470 [debug] circuit_receive_relay_cell(): Sending to origin.
Jun 20 14:42:15.470 [debug] connection_edge_process_relay_cell(): Now seen 205318 relay cells here (command 40, stream 0).
Jun 20 14:42:15.470 [warn] Unexpected INTRODUCE_ACK on circuit 3944288021.
Jun 20 14:42:15.470 [debug] circuit_get_by_circid_channel_impl(): circuit_get_by_circid_channel_impl() returning circuit 0x562673c1d930 for circ_id 3944288021, channel ID 29 (0x562674553c80)
Jun 20 14:42:15.470 [info] pathbias_should_count(): Circuit 90 is not being counted by pathbias because it was ignored in the past. Purpose is Circuit kept open for padding, path state is new
Jun 20 14:42:15.471 [info] circuit_mark_for_close_(): Circuit 3944288021 (id: 90) marked for close at src/feature/hs/hs_client.c:1770 (orig reason: 1, new reason: 0)
```
I.e. it looks like we built two parallel intro circuits, one of them worked, so we closed the other, but we didn't actually close it, we put it into an "open for padding" state, and then the intro ack arrived on it after a while, which surprised us.Tor: 0.4.2.x-final