Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:07:01Zhttps://gitlab.torproject.org/legacy/trac/-/issues/21648prop140: Caches generate diffs as appropriate2020-06-13T15:07:01ZNick Mathewsonprop140: Caches generate diffs as appropriateDirectory caches should pre-generate and pre-compress diffs as appropriate. It might be best to do this in a different thread or process. It might be best to pre-generate some and create others on demand.Directory caches should pre-generate and pre-compress diffs as appropriate. It might be best to do this in a different thread or process. It might be best to pre-generate some and create others on demand.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21647Prop140: directory caches cache multiple past diffs or consensuses2020-06-13T15:07:00ZNick MathewsonProp140: directory caches cache multiple past diffs or consensusesTo implement prop140, we need to store history about the consensus documents. This should be fairly simple if we have #21645 to work from.To implement prop140, we need to store history about the consensus documents. This should be fairly simple if we have #21645 to work from.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21646prop140/compression: Refactor "directory request" code2020-06-13T15:06:59ZNick Mathewsonprop140/compression: Refactor "directory request" codeOur current notion of "what is a directory request" includes a bunch of fields that are strewn around directory connections and passed to different functions. It would be nice to instead have a "directory request" type that we created a...Our current notion of "what is a directory request" includes a bunch of fields that are strewn around directory connections and passed to different functions. It would be nice to instead have a "directory request" type that we created and passed around as appropriate. This would make it easier to test our request generation/parsing code.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21645prop140 / compression: Unified directory cache backend2020-06-13T15:06:59ZNick Mathewsonprop140 / compression: Unified directory cache backendWith prop140 and/or ahf's compression proposal, we'll need to cache more documents than previously, to include multiple consensuses, diffs, compressed consensuses, etc. We could do this in an ad-hoc way, but we'll probably be better off...With prop140 and/or ahf's compression proposal, we'll need to cache more documents than previously, to include multiple consensuses, diffs, compressed consensuses, etc. We could do this in an ad-hoc way, but we'll probably be better off with a real abstraction here.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21644Prop140: Fuzz the diff and patch code2020-06-13T15:06:58ZNick MathewsonProp140: Fuzz the diff and patch codeNow that we have fuzzing support, it would be ridiculous to start using diff/patch code without testing it through our fuzzers. So, let's do that.Now that we have fuzzing support, it would be ridiculous to start using diff/patch code without testing it through our fuzzers. So, let's do that.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21643Prop140: Extract, test, revise, and clean the diff code2020-06-13T15:06:58ZNick MathewsonProp140: Extract, test, revise, and clean the diff codeStep one of getting the consensus diff support of prop140 completed is to get the diff and patch code merged. Let's do this separately from the directory code, since that code is hairier, and may need more work.Step one of getting the consensus diff support of prop140 completed is to get the diff and patch code merged. Let's do this separately from the directory code, since that code is hairier, and may need more work.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21641Prop274: Rotate onion keys less frequently2020-06-13T15:06:55ZNick MathewsonProp274: Rotate onion keys less frequentlyLet's implement proposal 274: This proposal will save a fair amount of bandwidth now, and even more once we have consensus diffs.Let's implement proposal 274: This proposal will save a fair amount of bandwidth now, and even more once we have consensus diffs.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21640crash on opening2020-06-13T15:06:55ZTraccrash on opening[Sun Mar 5 10:23:23 2017] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "microdesc_free(): Bug: microdesc_free() called, but md ...[Sun Mar 5 10:23:23 2017] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "microdesc_free(): Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1
"
**Trac**:
**Username**: kilfederTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21622Log a message when a hidden service delays new introduction point circuits2020-06-13T15:06:55ZteorLog a message when a hidden service delays new introduction point circuitsWhen a hidden service stops making new introduction point circuits, it would be useful to log a message saying:
* how many connections it has made so far,
* how long it took it to make those connections,
* what the connection limit is,
*...When a hidden service stops making new introduction point circuits, it would be useful to log a message saying:
* how many connections it has made so far,
* how long it took it to make those connections,
* what the connection limit is,
* in what time that many connections can be made, and
* a list of the current intro point connections.
This is a follow-up to #21599.Tor: 0.3.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/21599Make hidden service descriptor creation more consistent2020-06-13T15:06:51ZteorMake hidden service descriptor creation more consistentThis cleans up #21596: now that circuit_established is reliable, it can be used during descriptor creation as well. This prevents a regression to bugs like #21594.This cleans up #21596: now that circuit_established is reliable, it can be used during descriptor creation as well. This prevents a regression to bugs like #21594.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21598Log a message when a hidden service has fewer introduction points than expected2020-06-13T15:06:51ZteorLog a message when a hidden service has fewer introduction points than expectedDiagnostic for bugs like #21446.Diagnostic for bugs like #21446.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21592Make sure linked and linked_conn can't get out of sync2020-06-13T15:06:48ZteorMake sure linked and linked_conn can't get out of syncIn #21576, we encountered a situation where linked is true, but linked_conn is NULL.
This shouldn't happen, so we need to diagnose the error, and fix it.In #21576, we encountered a situation where linked is true, but linked_conn is NULL.
This shouldn't happen, so we need to diagnose the error, and fix it.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21586Assertion my_rsa_cert failed in sr_generate_our_commit when BridgeAuthoritati...2020-06-13T15:06:48ZRoger DingledineAssertion my_rsa_cert failed in sr_generate_our_commit when BridgeAuthoritativeDir 1Running Tor 0.2.9.9:
```
$ src/or/tor BridgeAuthoritativeDir 1
Mar 01 01:09:03.633 [notice] Tor 0.2.9.9 (git-56788a2489127072) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Mar 01 01:09:03.634 [notice] Tor ...Running Tor 0.2.9.9:
```
$ src/or/tor BridgeAuthoritativeDir 1
Mar 01 01:09:03.633 [notice] Tor 0.2.9.9 (git-56788a2489127072) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Mar 01 01:09:03.634 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 01 01:09:03.634 [notice] Read configuration file "/usr/local/etc/tor/torrc".
Mar 01 01:09:03.638 [warn] ControlPort is open, but no authentication method has been configured. This means that any program on your computer can reconfigure your Tor. That's bad! You should upgrade your Tor controller as soon as possible.
Mar 01 01:09:03.639 [notice] Opening Socks listener on 127.0.0.1:9050
Mar 01 01:09:03.639 [notice] Opening Control listener on 127.0.0.1:9051
Mar 01 01:09:03.639 [notice] Opening Control listener on /home/arma/.tor/control
Mar 01 01:09:03.639 [warn] Your log may contain sensitive information - you disabled SafeLogging, and you're logging more than "notice". Don't log unless it serves an important reason. Overwrite the log afterwards.
Mar 01 01:09:03.647 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Mar 01 01:09:03.715 [notice] Bootstrapped 0%: Starting
Mar 01 01:09:04.220 [notice] Bootstrapped 80%: Connecting to the Tor network
Mar 01 01:09:04.220 [err] tor_assertion_failed_(): Bug: src/or/shared_random.c:908: sr_generate_our_commit: Assertion my_rsa_cert failed; aborting. (on Tor 0.2.9.9 56788a2489127072)
Mar 01 01:09:04.221 [err] Bug: Assertion my_rsa_cert failed in sr_generate_our_commit at src/or/shared_random.c:908. Stack trace: (on Tor 0.2.9.9 56788a2489127072)
Mar 01 01:09:04.221 [err] Bug: src/or/tor(log_backtrace+0x42) [0x7f6fab7a1442] (on Tor 0.2.9.9 56788a2489127072)
Mar 01 01:09:04.221 [err] Bug: src/or/tor(tor_assertion_failed_+0x8c) [0x7f6fab7b917c] (on Tor 0.2.9.9 56788a2489127072)
Mar 01 01:09:04.221 [err] Bug: src/or/tor(sr_generate_our_commit+0x2ce) [0x7f6fab6b251e] (on Tor 0.2.9.9 56788a2489127072)
Mar 01 01:09:04.221 [err] Bug: src/or/tor(sr_state_update+0x239) [0x7f6fab6b4e49] (on Tor 0.2.9.9 56788a2489127072)
Mar 01 01:09:04.221 [err] Bug: src/or/tor(sr_state_init+0x8c) [0x7f6fab6b531c] (on Tor 0.2.9.9 56788a2489127072)
Mar 01 01:09:04.221 [err] Bug: src/or/tor(do_main_loop+0x486) [0x7f6fab69ea16] (on Tor 0.2.9.9 56788a2489127072)
Mar 01 01:09:04.221 [err] Bug: src/or/tor(tor_main+0x1c25) [0x7f6fab6a1ee5] (on Tor 0.2.9.9 56788a2489127072)
Mar 01 01:09:04.221 [err] Bug: src/or/tor(main+0x19) [0x7f6fab69a179] (on Tor 0.2.9.9 56788a2489127072)
Mar 01 01:09:04.221 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f6fa9c8db45] (on Tor 0.2.9.9 56788a2489127072)
Mar 01 01:09:04.221 [err] Bug: src/or/tor(+0x401c9) [0x7f6fab69a1c9] (on Tor 0.2.9.9 56788a2489127072)
Aborted
```
Probably we want to handle this weird error case more gracefully.
Pointed out by a user on #tor who seemed to be confused and enabling all sorts of config options.Tor: 0.3.1.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/21580circuit_build_needed_circs comment mentions router_have_min_dir_info, which d...2020-06-13T15:06:46Zteorcircuit_build_needed_circs comment mentions router_have_min_dir_info, which does not existThis was introduced somewhere in 0.3.0 with the new guard code.This was introduced somewhere in 0.3.0 with the new guard code.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21564Regenerate fallback list for 0.3.1 or 0.3.22020-06-13T16:06:01ZteorRegenerate fallback list for 0.3.1 or 0.3.2This involves:
* checking for new relays
* contacting potential fallback operators
* rebuilding the list
* contacting all fallback operators
See detailed instructions here:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallb...This involves:
* checking for new relays
* contacting potential fallback operators
* rebuilding the list
* contacting all fallback operators
See detailed instructions here:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrorsTor: 0.3.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/21554Inventory proposals that need merging into specs ; merge them.2020-06-13T15:06:41ZNick MathewsonInventory proposals that need merging into specs ; merge them.Before we can call 0.3.0 done, we must have the specs up-to-date.Before we can call 0.3.0 done, we must have the specs up-to-date.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21540Warning "Failure from drain_fd"2020-06-13T15:06:39ZTracWarning "Failure from drain_fd" "Failure from drain_fd: No error [x similar messages suppressed in 72000
seconds]"
"x" stands for any number
**Possible the same as #16992**
```
Feb 18 19:41:59.564 [Warnung] Failure from drain_fd: No error [5 similar message(s) sup... "Failure from drain_fd: No error [x similar messages suppressed in 72000
seconds]"
"x" stands for any number
**Possible the same as #16992**
```
Feb 18 19:41:59.564 [Warnung] Failure from drain_fd: No error [5 similar message(s) suppressed in last 7200 seconds]
Feb 18 20:04:08.501 [Hinweis] Heartbeat: Tor's uptime is 16:22 hours, with 2 circuits open. I've sent 31.55 MB and received 211.71 MB.
Feb 18 20:04:08.501 [Hinweis] Average packaged cell fullness: 73.875%. TLS write overhead: 5%
Feb 18 20:04:08.501 [Hinweis] Circuit handshake stats since last time: 1/1 TAP, 0/0 NTor.
Feb 18 20:04:08.501 [Hinweis] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 43 v4 connections; and received 3 v1 connections, 12 v2 connections, 17 v3 connections, and 701 v4 connections.
Feb 18 21:54:40.556 [Warnung] Failure from drain_fd: No error [1 similar message(s) suppressed in last 7200 seconds]
Feb 19 00:00:07.179 [Warnung] Failure from drain_fd: No error [9 similar message(s) suppressed in last 7200 seconds]
Feb 19 01:15:16.376 [Hinweis] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now.
Feb 19 15:14:06.133 [Hinweis] Tor 0.2.9.9 (git-56788a2489127072) running on Windows 7 with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
Feb 19 15:14:06.134 [Hinweis] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 19 15:14:06.134 [Hinweis] Read configuration file "C:\Program Files (x86)\Vidalia Relay Bundle\Data\Tor\torrc".
Feb 19 15:14:06.134 [Warnung] Path for DataDirectory (C:/Program Files (x86)/Vidalia Relay Bundle/Data/Tor) is relative and will resolve to C:\Program Files (x86)\Vidalia Relay Bundle\Data\Tor. Is this what you wanted?
Feb 19 15:14:06.134 [Hinweis] Based on detected system memory, MaxMemInQueues is set to 2048 MB. You can override this by setting MaxMemInQueues by hand.
Feb 19 15:14:06.134 [Hinweis] Opening Socks listener on 127.0.0.1:9050
Feb 19 15:14:06.134 [Hinweis] Opening Control listener on 127.0.0.1:9051
Feb 19 15:14:06.134 [Hinweis] Opening OR listener on 0.0.0.0:443
Feb 19 15:14:06.135 [Hinweis] Opening Directory listener on 0.0.0.0:9030
Feb 19 17:28:38.911 [Warnung] Failure from drain_fd: No error [74 similar message(s) suppressed in last 7200 seconds]
Feb 19 20:48:42.369 [Warnung] Failure from drain_fd: No error [2 similar message(s) suppressed in last 7200 seconds]
Feb 19 21:15:07.100 [Hinweis] Heartbeat: Tor's uptime is 5:59 hours, with 3 circuits open. I've sent 55.97 MB and received 935.17 MB.
Feb 19 21:15:07.101 [Hinweis] Average packaged cell fullness: 57.651%. TLS write overhead: 5%
Feb 19 21:15:07.101 [Hinweis] Circuit handshake stats since last time: 1/1 TAP, 115/115 NTor.
Feb 19 21:15:07.101 [Hinweis] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 148 v4 connections; and received 0 v1 connections, 10 v2 connections, 11 v3 connections, and 377 v4 connections.
```
**Trac**:
**Username**: PjotrVTor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21529Bootstrap fails if one pinned ExitNode is not running2020-06-13T15:06:37ZDavid Gouletdgoulet@torproject.orgBootstrap fails if one pinned ExitNode is not runningSome user reported that he/she pinned a single ExitNode and that relay is not running which ultimately make tor not bootstrap. (Taken from #21520)
```
Feb 22 00:08:35.018 [notice] Opening Socks listener on 127.0.0.1:9550
Feb 22 00:08:35...Some user reported that he/she pinned a single ExitNode and that relay is not running which ultimately make tor not bootstrap. (Taken from #21520)
```
Feb 22 00:08:35.018 [notice] Opening Socks listener on 127.0.0.1:9550
Feb 22 00:08:35.018 [notice] Opening Control listener on 127.0.0.1:9551
Feb 22 00:08:35.000 [notice] Bootstrapped 0%: Starting
Feb 22 00:08:36.000 [notice] Bootstrapped 45%: Asking for relay descriptors
Feb 22 00:08:38.000 [notice] Bootstrapped 50%: Loading relay descriptors
Feb 22 00:08:46.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 7134/7268, and can only build 0% of likely paths. (We have 98% of guards bw, 98% of midpoint bw, and 0% of exit bw = 0% of path bw.)
```
This seems peculiar behavior because Tor should be able to download the consensus nevertheless through Dir Auth. or Fallback Directories? A tor without a working ExitNode is a valid Tor (hidden service client for instance) so it should bootstrap.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21510Make unit test captured log messages consistent2020-06-13T15:06:32ZteorMake unit test captured log messages consistentThere's an extra colon and missing space in b0a9e54705d.
It would be nice to clean these up - there's no reason to backport.There's an extra colon and missing space in b0a9e54705d.
It would be nice to clean these up - there's no reason to backport.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21496Check string passed to extrainfo_parse_entry_from_string2020-06-13T15:06:27ZteorCheck string passed to extrainfo_parse_entry_from_stringscan-build reports the following out of bounds access, because it doesn't know that s is always non-NULL. But we should guard against it being NULL.
extrainfo_parse_entry_from_string:
```
+ if (BUG(!s))
+ return;
while (end > s+2...scan-build reports the following out of bounds access, because it doesn't know that s is always non-NULL. But we should guard against it being NULL.
extrainfo_parse_entry_from_string:
```
+ if (BUG(!s))
+ return;
while (end > s+2 && *(end-1) == '\n' && *(end-2) == '\n')
```Tor: 0.3.1.x-finalNick MathewsonNick Mathewson