Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:38Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34248Declare HSIntro=5 in Tor's rust protover implementation2020-06-13T15:53:38ZteorDeclare HSIntro=5 in Tor's rust protover implementationMy protover tests for #33222 fail in Rust, because Tor's rust protover doesn't declare HSIntro=5.
I'll do a quick fix in #33222, but I want to leave the backport to David.My protover tests for #33222 fail in Rust, because Tor's rust protover doesn't declare HSIntro=5.
I'll do a quick fix in #33222, but I want to leave the backport to David.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32468test/parseconf: Actually detect --dump-config errors2020-06-13T15:48:09Zteortest/parseconf: Actually detect --dump-config errorsWhen we added $FILTER for Windows, we made the pipeline exit successfully, even when tor exits with an error.When we added $FILTER for Windows, we made the pipeline exit successfully, even when tor exits with an error.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32404Add a CFLG_OBSOLETE flag, and handle it at the confvar layer2020-06-13T15:47:59ZteorAdd a CFLG_OBSOLETE flag, and handle it at the confvar layerFollow up to #32295 for 0.4.3.
nickm says:
My suggestion would be to change how OBSOLETE is implemented: it doesn't really make sense as a type. Instead, there should be an "empty" type for fields that can't be read or written, and a C...Follow up to #32295 for 0.4.3.
nickm says:
My suggestion would be to change how OBSOLETE is implemented: it doesn't really make sense as a type. Instead, there should be an "empty" type for fields that can't be read or written, and a CFLG_OBSOLETE flag that causes these warnings. The CFLG_OBSOLETE flag should be handled at the confvar layer, I think.
This is a bug caused by sponsor 31, so it's a must-have.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32402Actually check most shell scripts for errors2020-06-13T15:47:58ZteorActually check most shell scripts for errorsThe find command in checkShellScripts.sh is wrong.The find command in checkShellScripts.sh is wrong.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32295"Skipping obsolete configuration option." doesn't say which one2020-06-13T15:47:30ZRoger Dingledine"Skipping obsolete configuration option." doesn't say which oneIn Tor 0.3.5.x:
```
app/config/confparse.c:
log_warn(LD_CONFIG, "Skipping obsolete configuration option '%s'", c->key);
```
But in 0.4.2.3-alpha:
```
lib/confmgt/type_defs.c:
log_warn(LD_GENERAL, "Skipping obsolete configuration option."...In Tor 0.3.5.x:
```
app/config/confparse.c:
log_warn(LD_CONFIG, "Skipping obsolete configuration option '%s'", c->key);
```
But in 0.4.2.3-alpha:
```
lib/confmgt/type_defs.c:
log_warn(LD_GENERAL, "Skipping obsolete configuration option.");
```
Resulting in log messages like:
```
Oct 25 16:19:28.906 [warn] Skipping obsolete configuration option.
Oct 25 16:19:28.906 [warn] Skipping obsolete configuration option.
```
which are not as helpful as they could be.
The bug went in with commit c60a85d2, which I think first went into 0.4.2.1-alpha.
The new file has a XXXX next to this line:
```
// XXXX move this to a higher level, once such a level exists.
log_warn(LD_GENERAL, "Skipping obsolete configuration option.");
```
but I see that most tickets like #29211 and #30866 are scheduled for 0.4.3.x, and this is an 0.4.2 bug so I am filing a separate ticket.
Bug reported by OFFShare in irc.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31958connection_dir_is_anonymous: Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)-...2020-06-13T15:46:20ZDavid Gouletdgoulet@torproject.orgconnection_dir_is_anonymous: Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)->p_chan == NULL) failedHmm, I just noticed this on one of my test relay:
```
Sep 14 17:35:18.196 [warn] tor_bug_occurred_(): Bug: src/feature/dircommon/directory.c:229: connection_dir_is_anonymous: Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)->p_chan == NU...Hmm, I just noticed this on one of my test relay:
```
Sep 14 17:35:18.196 [warn] tor_bug_occurred_(): Bug: src/feature/dircommon/directory.c:229: connection_dir_is_anonymous: Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)->p_chan == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: Tor 0.4.2.0-alpha-dev (git-796a9b37ea346f41): Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)->p_chan == NULL) failed in connection_dir_is_anonymous at src/feature/dircommon/directory.c:229. Stack trace: (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(log_backtrace_impl+0x46) [0x56174b20aae6] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(tor_bug_occurred_+0x16c) [0x56174b205d9c] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(connection_dir_is_anonymous+0x131) [0x56174b0ef421] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(directory_handle_command+0x1ef) [0x56174b19755f] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(connection_dir_process_inbuf+0x95) [0x56174b0efb85] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(connection_handle_read+0xa0d) [0x56174b064bfd] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(+0x6fe0e) [0x56174b069e0e] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x1e8f8) [0x7f65e17278f8] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x53f) [0x7f65e172833f] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(do_main_loop+0xd9) [0x56174b06b0f9] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(tor_run_main+0x128d) [0x56174b058c8d] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(tor_main+0x3a) [0x56174b0560ca] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(main+0x19) [0x56174b055c59] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f65e09c2b97] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(_start+0x2a) [0x56174b055caa] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
```
This is recent code that reject HSDir single hop connections (#24964). Offending piece of code is:
```
/* Get the previous channel to learn if it is a client or relay link. */
if (BUG(CONST_TO_OR_CIRCUIT(circ)->p_chan == NULL)) {
log_info(LD_DIR, "Rejected HSDir request: no p_chan");
return false;
}
```
Not sure why this can BUG()...Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31838Fix a typo in the practracker usage message2020-06-13T15:45:56ZteorFix a typo in the practracker usage messageI don't think this needs a changes file?I don't think this needs a changes file?Tor: 0.4.2.x-finalteorteor