Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2023-05-25T13:08:33Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40332Heartbeat log unit size are not user-friendly2023-05-25T13:08:33ZcypherpunksHeartbeat log unit size are not user-friendlyIn the file `tor-0.4.5.6/src/feature/dirclient/dirclient.c`, at lines 2002-2005, the heartbeat log message shows different amount of data in bytes.
Exemple:
>>>
[XXX 00 00:00:00.000] [notice] While not bootstrapping, fetched this many...In the file `tor-0.4.5.6/src/feature/dirclient/dirclient.c`, at lines 2002-2005, the heartbeat log message shows different amount of data in bytes.
Exemple:
>>>
[XXX 00 00:00:00.000] [notice] While not bootstrapping, fetched this many bytes: XXXXXXXXX (server descriptor fetch); XXXXXX (server descriptor upload); XXXXXXXX (consensus network-status fetch); XXXX (authority cert fetch); XXXXX (microdescriptor fetch)
>>>
Knowing that my server fetch XXXXXXXXX bytes from the server directory does not really help me to easily understand my bandwidth usage. It could be more nice to look at if each amount of data will be followed by a appropriate unit size. For exemple:
>>>
[Time] [notice] While not bootstrapping, fetched this many data: XX.X `MiB` (server descriptor fetch); XX.X `KiB` (server descriptor upload); XX.X `MiB` (consensus network-status fetch); X.X `KiB` (authority cert fetch); XXX.X `KiB` (microdescriptor fetch)
>>>
And like it is said in the description of the file `core/or/status.c`, from line 4 to 13:
>>>
[...] heartbeat log messages, [...] inform users and operators about basic facts to do with their Tor instance. [...] It collects data [...] and logs it in a **human-readable** format.
>>>https://gitlab.torproject.org/tpo/core/tor/-/issues/24014Make exits check DNS periodically, and disable exit traffic if it fails2022-10-24T20:50:56ZteorMake exits check DNS periodically, and disable exit traffic if it failsCurrently exits check once at startup, which doesn't detect overloaded DNS servers once the exit receives significant traffic.
See legacy/trac#21394 for details,
Since this is a new feature, it is not going to make it into 0.3.2.Currently exits check once at startup, which doesn't detect overloaded DNS servers once the exit receives significant traffic.
See legacy/trac#21394 for details,
Since this is a new feature, it is not going to make it into 0.3.2.https://gitlab.torproject.org/tpo/core/tor/-/issues/29128Place complete obfs4 bridge line in accessible location2024-03-05T18:19:05ZColin ChildsPlace complete obfs4 bridge line in accessible locationCurrently operators wanting to distribute or use personal obfs4 bridges must follow 5 steps:
1. Determine their bridge's IP address
2. Check logs for their bridge's fingerprint
3. Check logs for which port obfs4 is running on
4. Retrie...Currently operators wanting to distribute or use personal obfs4 bridges must follow 5 steps:
1. Determine their bridge's IP address
2. Check logs for their bridge's fingerprint
3. Check logs for which port obfs4 is running on
4. Retrieve their obfs4 cert from /var/lib/tor/pt_state/obfs4_bridgeline.txt
5. String the above together in the following format:
```
Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=$FROMSTEP4 iat-mode=0
```
This can be a confusing process, and is only fully explained upon opening `/var/lib/tor/pt_state/obfs4_bridgeline.txt`; however it leaves filling in the fields (with the exception of the cert) to the user.
Having the complete bridge line placed somewhere accessible would make this process much less painful for operators.https://gitlab.torproject.org/tpo/core/tor/-/issues/31737Change handling of relative paths in %include directives?2022-09-01T21:42:48ZNick MathewsonChange handling of relative paths in %include directives?Right now, relative paths in %include directives are handled relative to Tor's working directory, which doesn't make a lot of sense. Handling them relative to the configuration file might make more sense?
We'd want to figure out a way ...Right now, relative paths in %include directives are handled relative to Tor's working directory, which doesn't make a lot of sense. Handling them relative to the configuration file might make more sense?
We'd want to figure out a way to handle this that won't break existing users.https://gitlab.torproject.org/tpo/core/tor/-/issues/40333`ServerTransportPlugin` option exit cleanly with exit code `-1`, but with no ...2024-03-05T15:39:31Zcypherpunks`ServerTransportPlugin` option exit cleanly with exit code `-1`, but with no user-friendly log warning when the argument `path-to-binary` is invalidIf we add in `/etc/tor/torrc` the line `ServerTransportPlugin obfs4 exec /path/that/does/not/exist`, have log minimum severity to `info` and execute the command `sudo systemctl reload tor`, we can clearly see in the following log extract...If we add in `/etc/tor/torrc` the line `ServerTransportPlugin obfs4 exec /path/that/does/not/exist`, have log minimum severity to `info` and execute the command `sudo systemctl reload tor`, we can clearly see in the following log extract, that the `path-to-binary` argument is improperly or not at all validated before executing it :
~~~
`XXX 00 00:00:00.001 [notice] Tor 0.4.5.6 opening new log file.` \
`[...]` \
`XXX 00 00:00:00.002 [info] process_exec(): Starting new process: /path/that/does/not/exist` \
`XXX 00 00:00:00.020 [info] launch_managed_proxy(): Managed proxy at \'/path/that/does/not/exist\' has spawned with PID \'XXXXX\'. ` \
`[...]` \
`XXX 00 00:00:00.300 [info] notify_waitpid_callback_by_pid(): Child process XXXXX has exited; running callback.` \
`XXX 00 00:00:00.300 [warn] Pluggable Transport process terminated with status code 256` \
`[...]` \
~~~
A relay operator who do no pay enough attentions while reading logs and have log minimum severity of `notice` will only see :
> `XXX 00 00:00:00.300 [warn] Pluggable Transport process terminated with status code 256`
We should definitely have a user-friendly log message to notify the operator that there is a problem with is configuration file.
The file `tor-0.4.5.6/app/config/config.c`, at the fonction `pt_parse_transport_line()`, in the `else` statement between line 5377 and 5421 look a promising place to validate the `path-to-binary`.
There is already a test for this case of non-existent executable, at `tor-0.4.5.6/src/test/test_process_slow.c`, `test_nonexistent_executable()`, starting at line 331.Tor: 0.4.9.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.org