Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:45:33Zhttps://gitlab.torproject.org/legacy/trac/-/issues/31707Better handling and UX for missing and expired guard descriptors2020-06-13T15:45:33ZteorBetter handling and UX for missing and expired guard descriptorsSplit off #31657:
Replying to teor:
> How do we reliably detect pathological cases?
> Suppress the message, until it occurs a few times within a short timeframe?
dgoulet:
That's a good question I don't have an answer for.
Unfortunate...Split off #31657:
Replying to teor:
> How do we reliably detect pathological cases?
> Suppress the message, until it occurs a few times within a short timeframe?
dgoulet:
That's a good question I don't have an answer for.
Unfortunately, I don't think that's the kind of message that occurs multiple times, looking at #30746 (and friends) this seems to be able to cause havoc with just a single repeatition.
I'm not sure why this is the case, since `router_have_minimum_dir_info()` seems to be called all the time and that should eventually call `entry_guards_get_err_str_if_dir_info_missing()` which is the source of the log message... Things are kinda messy between these two functions tho, so it's kinda hard to understand what's the issue.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31669Invalid signature for service descriptor signing key: expired2020-06-13T15:45:22ZTracInvalid signature for service descriptor signing key: expiredwhen searching for this log entry: #26932
The following log entry has been seen on exit relays running in OfflineMasterKey mode. Online keys did not expire, relay did not shutdown when this log entry was observed. We did not observe any...when searching for this log entry: #26932
The following log entry has been seen on exit relays running in OfflineMasterKey mode. Online keys did not expire, relay did not shutdown when this log entry was observed. We did not observe any service degradation.
```
Invalid signature for service descriptor signing key: expired
```
**Trac**:
**Username**: a_pTor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/31657Rephrase "missing descriptors" notice log to be less confusing2020-06-13T15:45:21ZteorRephrase "missing descriptors" notice log to be less confusingSome operators are confused or alarmed by these logs:
```
Sep 05 03:22:50.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total micro...Some operators are confused or alarmed by these logs:
```
Sep 05 03:22:50.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).
Sep 05 03:22:50.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/3 of our primary entry guards (total microdescriptors: 6515/6541).
```
We should rephrase them or document that:
* tor tries to keep active 3 primary guards for anonymity and safety
* we'll try to get new microdescs soon
* tor usually recovers quickly from this issueTor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28698When circuit times are fixed, they can't be "relaxed"2020-06-13T15:35:04ZteorWhen circuit times are fixed, they can't be "relaxed"In #28639, we had trouble diagnosing a sbws bug. tor said that circuit times were "relaxed", even when LearnCircuitBuildTimeout was 0.
When circuit_build_times_disabled() is true, we should change these log messages so that they make se...In #28639, we had trouble diagnosing a sbws bug. tor said that circuit times were "relaxed", even when LearnCircuitBuildTimeout was 0.
When circuit_build_times_disabled() is true, we should change these log messages so that they make sense:
https://github.com/torproject/tor/blob/b058f64cc002b44e6dd48616ca3163a01c3f3e14/src/core/or/circuituse.c#L591
I think relaxed_timeout is meaningless when circuit_build_times_disabled() is true, but that's another issue.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23090Sandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.322020-06-13T15:12:15ZteorSandbox failure on Debian 8.9 under OpenVZ with kernel version 2.6.32A relay operator reports a sandbox failure on Tor 0.3.0.9 with the following log lines:
```
sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
sandbox_getaddrinfo(): (Sandbox) getaddrinfo failed.
sandbox_getaddrinfo(): (Sandbox) get...A relay operator reports a sandbox failure on Tor 0.3.0.9 with the following log lines:
```
sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
sandbox_getaddrinfo(): (Sandbox) getaddrinfo failed.
sandbox_getaddrinfo(): (Sandbox) getaddrinfo succeeded.
install_syscall_filter(): Bug: (Sandbox) failed to load: -22 (Invalid argument)! (on Tor 0.3.0.9 )
tor_main(): Bug: Failed to create syscall sandbox filter (on Tor 0.3.0.9 )
main process exited, code=exited, status=1/FAILURE
```
See https://lists.torproject.org/pipermail/tor-relays/2017-August/012694.htmlTor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22723Avoid double-quoting esc_for_log output2020-06-13T15:10:40ZteorAvoid double-quoting esc_for_log outputIn #22368, arma posted a log where we double-quote relay nicknames.
```
[warn] There is a router named """" in my declared family, but that isn't a legal nickname. Skipping it.
```
Let's stop double-quoting esc_for_log output across the ...In #22368, arma posted a log where we double-quote relay nicknames.
```
[warn] There is a router named """" in my declared family, but that isn't a legal nickname. Skipping it.
```
Let's stop double-quoting esc_for_log output across the codebase.Tor: unspecifiedhttps://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/21474Fix make test-fuzz-corpora warnings2020-06-13T15:06:22ZteorFix make test-fuzz-corpora warningsThe following bug warnings should probably be protocol warnings, or be caught earlier:
```
./src/test/fuzz_static_testcases.sh
Running tests for consensus
Feb 16 02:17:26.012 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (o...The following bug warnings should probably be protocol warnings, or be caught earlier:
```
./src/test/fuzz_static_testcases.sh
Running tests for consensus
Feb 16 02:17:26.012 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Feb 16 02:17:30.133 [warn] sr_parse_commit: Bug: SR: Commit algorithm "sha6-256" is not recognized. (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Feb 16 02:17:34.625 [warn] commit_decode: Bug: SR: Commit from authority 20EE989200EF98A75102B461DF62F01B2932C0D6 decoded length doesn't match the expected length (36 vs 40). (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Feb 16 02:17:40.758 [warn] commit_decode: Bug: SR: Commit from authority B0F141F4B8CCBCC328572C71E5590BBA19775594 can't be decoded. (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Running tests for descriptor
Feb 16 02:18:08.780 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Running tests for extrainfo
Feb 16 02:18:18.548 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
...
```
I'm not sure whether we need this in 030, but it would be nice to fix them eventually.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21355Warn when IPv6Exits have no ipv6-policy line in their descriptor2020-06-13T15:05:49ZteorWarn when IPv6Exits have no ipv6-policy line in their descriptorThere appears to be a bug in Tor's IPv6 Exit code, where exits that have IPv6Exit set do not have an ipv6-policy line in their descriptor.
To assist in diagnosing this bug, we should log a warning message (not a bug message) containing ...There appears to be a bug in Tor's IPv6 Exit code, where exits that have IPv6Exit set do not have an ipv6-policy line in their descriptor.
To assist in diagnosing this bug, we should log a warning message (not a bug message) containing the full exit policy, when the IPv6 exit policy summary is empty, but IPv6Exit is 1 and ExitRelay is 1 or auto.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20492Tor git version is not generated in git worktrees2020-07-31T12:44:02ZteorTor git version is not generated in git worktreesWhen I compile tor on macOS, it doesn't log the git version on startup:
```
Oct 29 01:27:48.261 [notice] Tor 0.3.0.0-alpha-dev running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
```
This happens regardless of ...When I compile tor on macOS, it doesn't log the git version on startup:
```
Oct 29 01:27:48.261 [notice] Tor 0.3.0.0-alpha-dev running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
```
This happens regardless of compiler and architecture:
gcc (MacPorts gcc49 4.9.4_0+universal) 4.9.4 (i386/x86_64)
clang version 3.9.0 (tags/RELEASE_390/final) (x86_64)
$ git --version
git version 2.10.1
But when I compile it on Linux, I see a git commit hash:
```
Oct 28 14:28:15.669 [notice] Tor 0.3.0.0-alpha-dev (git-f3e158edf7d8128d) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g and Zlib 1.2.8.
```
Compiler:
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
$ git --version
git version 2.6.3.36.g9a8c740
I'm putting this in 0.3.0 because it makes diagnosing issues much easier if we have the full commit. But feel free to disagree.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19711circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay...2020-06-13T14:59:38ZTraccircuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:701 has n_chan==NULL. Dropping. (on Tor 0.2.8.5-rc )circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:701 has n_chan==NULL. Dropping. (on Tor 0.2.8.5-rc )
**Trac**:
**Username**: user100500circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:701 has n_chan==NULL. Dropping. (on Tor 0.2.8.5-rc )
**Trac**:
**Username**: user100500Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18499Improved event selection dialog2016-07-05T00:50:14ZDamian JohnsonImproved event selection dialogTo select events to log Nyx uses a weird dialog, requiring users to pick letters corresponding with the events they want. To see it press 'e' on the first page...
![https://www.atagar.com/transfer/tmp/event_selection.png](https://www.at...To select events to log Nyx uses a weird dialog, requiring users to pick letters corresponding with the events they want. To see it press 'e' on the first page...
![https://www.atagar.com/transfer/tmp/event_selection.png](https://www.atagar.com/transfer/tmp/event_selection.png)
This was ok years ago when tor had few events, but as you can see this now requires the user to type really arcane strings ('CaruF'?). We should change this to be similar to our [config editor](https://www.atagar.com/arm/images/screenshot_configPanel_full.png), showing a dialog like...
```
+------------------------------------------------------+
| BW event |
| Bandwidth used by tor. This shows both the number of |
| bytes sent and received. |
+------------------------------------------------------+
| [ ] DEBUG |
| [ ] INFO |
| [X] NOTICE |
| [X] WARN |
| [X] ERR |
+------------------------------------------------------+
| [ ] BW |
| [ ] CIRC |
| ... etc... |
+------------------------------------------------------+
```
Note we'll be dropping the '--log' argument as part of this. A big part of the reason for this arcane alphabet soup was to allow users to specify events with that argument but this clunkiness is hardly worth it. Users can configure initial events in their nyxrc instead.Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18114Warn when ReachableAddresses restricts connections to relays chosen by others2020-06-13T14:53:35ZteorWarn when ReachableAddresses restricts connections to relays chosen by othersTor clients which use one-hop paths to access relays chosen by other clients can't use ReachableAddresses (or similar options) or ClientUseIPv4 0 (#17840). If they did, this would deny them access to some relays, potentially impairing fu...Tor clients which use one-hop paths to access relays chosen by other clients can't use ReachableAddresses (or similar options) or ClientUseIPv4 0 (#17840). If they did, this would deny them access to some relays, potentially impairing functionality or performance.
This affects the following Tor modes:
* Tor2Web - Introduction Points
* RSOS - Rendezvous Points
For directory, guard, and bridge connections, clients choose or are configured with accessible relays based on ReachableAddresses / ClientUseIPv4/ClientUseIPv6.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17971Unrecognized relay in exit address '[scrubbed].exit'. Refusing.2020-06-13T14:53:10ZcypherpunksUnrecognized relay in exit address '[scrubbed].exit'. Refusing.This line appeared in my tor log the other day.
> Unrecognized relay in exit address '[scrubbed].exit'. Refusing.
I don't know what it means, and a quick search didn't return anything useful. I wasn't doing anything out of the ordinary...This line appeared in my tor log the other day.
> Unrecognized relay in exit address '[scrubbed].exit'. Refusing.
I don't know what it means, and a quick search didn't return anything useful. I wasn't doing anything out of the ordinary; just using Tor Browser. I use the system-installed Tor, so it could have come from anything on the system I guess. Safe logging was enabled, so I don't know what address was requested.
When I tried to reproduce it by making an explicit request to foo.nonexistant.exit, I got this.
> The ".exit" notation is disabled in Tor due to security risks. Set AllowDotExit in your torrc to enable it (at your own risk).
What does the first line mean, and why wasn't the request rejected by AllowDotExit=0? Is this something I should be worried about? Even if it's benign, hopefully users who get this warning will find this ticket in searches, since I've been unable to find the exact message anywhere.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16070Tor log doesn't have to be world readable2020-06-13T14:46:19Zyurivict271Tor log doesn't have to be world readableCurrently log is:
> -rw-r--r-- 1 _tor _tor 3485 May 17 12:52 tor.log
tor-0.2.6.7Currently log is:
> -rw-r--r-- 1 _tor _tor 3485 May 17 12:52 tor.log
tor-0.2.6.7Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15607Tor log dates imprecise2020-06-15T23:32:36ZDamian JohnsonTor log dates impreciseHi Nick. Tor's log file uses the local timezone and lacks the year in its log file entries...
```
Apr 06 11:03:39.000 [notice] Tor 0.2.7.0-alpha-dev (git-4247ce99e5d9b7b2) opening new log file.
Apr 06 11:03:39.832 [notice] Tor v0.2.7.0-...Hi Nick. Tor's log file uses the local timezone and lacks the year in its log file entries...
```
Apr 06 11:03:39.000 [notice] Tor 0.2.7.0-alpha-dev (git-4247ce99e5d9b7b2) opening new log file.
Apr 06 11:03:39.832 [notice] Tor v0.2.7.0-alpha-dev (git-4247ce99e5d9b7b2) running on Linux with Libevent 2.0.16-stable, OpenSSL 1.0.1 and Zlib 1.2.3.4.
Apr 06 11:03:39.832 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
```
This is fine, but has meant some hacks for arm which reads the log file to prepopulate that information. For instance, arm pretends the year is always 2012 to ensure log files made on leap years are readable (otherwise February 29th isn't a thing, see #5265).
Feel free to close this as 'no plan to fix' if you'd like. Just thought I'd run this by you to see if iso8601 timestamps or something more complete would be preferable.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/12672Tor log should be accessible while Tor Browser is starting up2020-06-13T17:43:02ZTracTor log should be accessible while Tor Browser is starting upSometimes users write to the Help Desk saying that their Tor Browsers do not manage to start. Since it does not start and stops in the initial loading "Tor Status" screen displaying "Connecting to the Tor Network", users are unable to gr...Sometimes users write to the Help Desk saying that their Tor Browsers do not manage to start. Since it does not start and stops in the initial loading "Tor Status" screen displaying "Connecting to the Tor Network", users are unable to grab a log to send to the Help Desk.
**Trac**:
**Username**: EnviteKathleen BradeKathleen Bradehttps://gitlab.torproject.org/legacy/trac/-/issues/10045Tor for Windows lacks eventlog support2020-06-13T14:32:46ZTracTor for Windows lacks eventlog supportTor for Windows does not support Windows' native system event logging facility "eventlog". Syslog is unsupported on Windows so an enhancement of Tor for Windows is necessary.
Administrators of Tor relays on Windows have a hard time of k...Tor for Windows does not support Windows' native system event logging facility "eventlog". Syslog is unsupported on Windows so an enhancement of Tor for Windows is necessary.
Administrators of Tor relays on Windows have a hard time of keeping track of Tor's events. This enhancement should ease this problem.
# Proposed changes/additions
## `/etc/torrc` or `%APPDATA%\tor\torrc`
* The `Log` configuration option's value `syslog` should enable logging to eventlog and be synonymous with the new value `eventlog` on Windows systems.
* A new `Log` configuration option value `eventlog` should be added. Setting `Log` to `eventlog` should enable logging to eventlog on Windows and be synonymous on other operating systems with the `syslog` value.
* Eventlog supports only four relevant event types for this matter: `EVENTLOG_SUCCESS`, `EVENTLOG_ERROR_TYPE`, `EVENTLOG_INFORMATION_TYPE`, and `EVENTLOG_WARNING_TYPE`. While `EVENTLOG_SUCCESS` usually maps to `EVENTLOG_INFORMATION_TYPE` leaving effectively three event types. These event types have to correspond to syslog's priorities/severities.
Proposed corresponding:
* `debug`, `info`, and `notice` correspond to `EVENTLOG_INFORMATION_TYPE`
* `warn` corresponds to `EVENTLOG_WARNING_TYPE`
* `err` corresponds to `EVENTLOG_ERROR_TYPE`
Verbosity should remain unaffected of priority/severity to event type correspondings, e.g. `notice` should not produce `info` or `debug` eventlog reports although they all correspond to the same event type `EVENTLOG_INFORMATION_TYPE`.
## Installing Tor as a service
* When installing Tor as service with "`tor.exe --service install`" tor should create an [event source](http://msdn.microsoft.com/en-us/library/aa363661%28v=vs.85%29.aspx) in the registry for eventlog.
* When removing the Tor service with "`tor.exe --service remove`" the previously created event source during service installation should be removed from registry.
**NOTE:** Generally speaking, this Tor installing as a service feature should be revised because by convention it is an uncommon practice on Windows for tools to provide such a feature. Service installation functionality is provided by the `sc.exe` external command and the Windows Installer (and the PowerShell lately). The preferred way for software vendors to install services is via the Windows Installer during application setup.
## Alternatives
Use a cross-platform logging library with good support for Windows.
**Trac**:
**Username**: GITNETor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9802Obfsproxy shouldn't log raw network data2013-09-22T22:42:34ZPhilipp Winterphw@torproject.orgObfsproxy shouldn't log raw network dataCode in obfsproxy's `socks.py` logs raw network data which quickly inflates log files and messes with the terminal reading the log file.
The branch `nolog_raw` in this repository fixes this problem:
https://github.com/NullHypothesis/obf...Code in obfsproxy's `socks.py` logs raw network data which quickly inflates log files and messes with the terminal reading the log file.
The branch `nolog_raw` in this repository fixes this problem:
https://github.com/NullHypothesis/obfsproxyGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/9779Stem configs resetting to default2013-09-20T06:17:18ZcypherpunksStem configs resetting to defaultAfter some time, Tor receives a HUP signal (during a long period without any user interaction) and any configuration changes made in Stem are replaced with whatever is in the torrc file. Specifically, this change occurs at the precise mo...After some time, Tor receives a HUP signal (during a long period without any user interaction) and any configuration changes made in Stem are replaced with whatever is in the torrc file. Specifically, this change occurs at the precise moment that the tor log is rotated. Stem maintains authentication and can still communicate with tor...
My concern is with the purpose of Tor's HUP signal and the loss of any configuration made in Stem...
Example log tail:
.....
Sep 1 01:25:57.000 [notice] new bridge descriptor 'XXXXXX' (fresh): $0000000000000000000000000000000000000000~XXXXXX at 1.23.4.5
Sep 1 01:39:04.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Sep 1 01:39:04.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Sep 1 01:39:04.000 [notice] Read configuration file "/etc/tor/torrc".Damian JohnsonDamian Johnson