Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:51:32Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33361relay: Warn about the lack of ContactInfo and the consequence2020-06-13T15:51:32ZDavid Gouletdgoulet@torproject.orgrelay: Warn about the lack of ContactInfo and the consequenceThe network health team (including bad relays) as been rejecting group of relays more and more that do not have their `ContactInfo` or/and `MyFamily` set (for a group of relays from the same operator).
These are for safety and health pu...The network health team (including bad relays) as been rejecting group of relays more and more that do not have their `ContactInfo` or/and `MyFamily` set (for a group of relays from the same operator).
These are for safety and health purposes of the network. See the relay guidelines for that.
That being said, we should improve the log notice that an operator get when failing to set `ContactInfo` to a warning and adding a sentence that says they might get rejected from the network due to a lack of valid responsive `ContactInfo`.
I would argue that this needs a backport for our maintained versions. Please, let me know if not agreeing with thatTor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33095Don't say "future instances of this warning will be suppressed" when we don't...2020-06-13T15:50:31ZNick MathewsonDon't say "future instances of this warning will be suppressed" when we don't mean it.Some of our definitions of the BUG() macro pass 1 as `once` to tor_bug_occurred_(), causing it to claim that we're only warning once.Some of our definitions of the BUG() macro pass 1 as `once` to tor_bug_occurred_(), causing it to claim that we're only warning once.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33093Use IF_BUG_ONCE in buf_flush_to_tls()2020-06-13T15:50:30ZNick MathewsonUse IF_BUG_ONCE in buf_flush_to_tls()See parent: the BUG() messages in this function caused dgoulet to run out of disk.See parent: the BUG() messages in this function caused dgoulet to run out of disk.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33087closing stdio fds on exit can interfere with LeakSanitizer, etc2020-06-13T15:50:28ZTaylor Yuclosing stdio fds on exit can interfere with LeakSanitizer, etcAt tor exit time, `tor_log_close_sigsafe_err_fds()` winds up closing stderr or stdout if they're being log destinations. This can close stderr before tools like LeakSanitizer can output useful information, e.g., if there's a config sett...At tor exit time, `tor_log_close_sigsafe_err_fds()` winds up closing stderr or stdout if they're being log destinations. This can close stderr before tools like LeakSanitizer can output useful information, e.g., if there's a config setting like `Log notice stderr`. (valgrind doesn't seem to have this problem, maybe because it runs a separate process?)
Is it correct for us to close a default fd like stderr or stdout if we're not running as a daemon? Other tools that do runtime interception might also be affected. If we think we have a good reason to explicitly close these fds, we probably should document how tor's closing of these fds can interfere with debugging tools.
nickm thinks this behavior might be new in 0.4.2 with the signal safety work. I haven't had time to investigate further.Tor: 0.4.2.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/32673'buf_read_from_tls()' can return the wrong error code2020-06-13T15:48:52Zopara'buf_read_from_tls()' can return the wrong error codeThe [function](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/buffers_tls.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n63) `buf_read_from_tls(...)` returns an integer. This integer can either be `<=0` (in which case it correspo...The [function](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/buffers_tls.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n63) `buf_read_from_tls(...)` returns an integer. This integer can either be `<=0` (in which case it corresponds to a `TOR_TLS_` status) or a positive number (in which case it corresponds to the number of bytes read). This return value is [used in](https://gitweb.torproject.org/tor.git/tree/src/core/mainloop/connection.c?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n3749) `connection_buf_read_from_socket()` in a large `switch(result)` statement.
At the beginning of `buf_read_from_tls(...)`, it returns `-1` on the lines:
```
IF_BUG_ONCE(buf->datalen >= INT_MAX)
return -1;
IF_BUG_ONCE(buf->datalen >= INT_MAX - at_most)
return -1;
```
This value of `-1` is the [same as](https://gitweb.torproject.org/tor.git/tree/src/lib/tls/tortls.h?id=64d6914232c5ecba2954e9c7a5f6a6b9b8b5fec6#n48) `TOR_TLS_WANTWRITE`. This causes the switch statement in `connection_buf_read_from_socket()` to interpret the return value as `TOR_TLS_WANTWRITE`, which is not correct for the `buf->datalen >= INT_MAX` bug. I suggest returning `TOR_TLS_ERROR_MISC` instead of `-1`. Note that this would close the connection.
I don't think you'll see incorrect behavior due to this, but it might be a good idea to fix.Tor: 0.4.2.x-finalNick MathewsonNick Mathewson