Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2023-04-03T16:38:12Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40340Man tor - Option `ClientTransportPlugin` should move from `GENERAL OPTIONS` t...2023-04-03T16:38:12ZcypherpunksMan tor - Option `ClientTransportPlugin` should move from `GENERAL OPTIONS` to `CLIENT OPTIONS`For tor-0.4.6.0-alpha-dev.
ChangeLog :
```
o Documentation (man tor):
- Move option `ClientTransportPlugin` from `GENERAL OPTIONS` to `CLIENT OPTIONS`. Closes issue #40XXX
```
Output of `git diff HEAD` :
```
diff --git a/doc/...For tor-0.4.6.0-alpha-dev.
ChangeLog :
```
o Documentation (man tor):
- Move option `ClientTransportPlugin` from `GENERAL OPTIONS` to `CLIENT OPTIONS`. Closes issue #40XXX
```
Output of `git diff HEAD` :
```
diff --git a/doc/man/tor.1.txt b/doc/man/tor.1.txt
index f5dd1ec..308bf2d 100644
--- a/doc/man/tor.1.txt
+++ b/doc/man/tor.1.txt
@@ -334,20 +334,6 @@ forward slash (/) in the configuration file and on the command line.
as a float value. This is an advanced option; you generally shouldn't have
to mess with it. (Default: -1)
-[[ClientTransportPlugin]] **ClientTransportPlugin** __transport__ socks4|socks5 __IP__:__PORT__::
-**ClientTransportPlugin** __transport__ exec __path-to-binary__ [options]::
- In its first form, when set along with a corresponding Bridge line, the Tor
- client forwards its traffic to a SOCKS-speaking proxy on "IP:PORT".
- (IPv4 addresses should written as-is; IPv6 addresses should be wrapped in
- square brackets.) It's the
- duty of that proxy to properly forward the traffic to the bridge. +
- +
- In its second form, when set along with a corresponding Bridge line, the Tor
- client launches the pluggable transport proxy executable in
- __path-to-binary__ using __options__ as its command-line options, and
- forwards its traffic to it. It's the duty of that proxy to properly forward
- the traffic to the bridge. (Default: none)
-
[[ConnLimit]] **ConnLimit** __NUM__::
The minimum number of file descriptors that must be available to the Tor
process before it will start. Tor will ask the OS for as many file
@@ -1178,6 +1164,21 @@ The following options are useful only for clients (that is, if
controller request). If true, multicast DNS hostnames for machines on the
local network (of the form *.local) are also rejected. (Default: 1)
+[[ClientTransportPlugin1]] **ClientTransportPlugin** __transport__ socks4|socks5 __IP__:__PORT__ +
+
+[[ClientTransportPlugin2]] **ClientTransportPlugin** __transport__ exec __path-to-binary__ [options]::
+ In its first form, when set along with a corresponding Bridge line, the Tor
+ client forwards its traffic to a SOCKS-speaking proxy on "IP:PORT".
+ (IPv4 addresses should written as-is; IPv6 addresses should be wrapped in
+ square brackets.) It's the
+ duty of that proxy to properly forward the traffic to the bridge. +
+ +
+ In its second form, when set along with a corresponding Bridge line, the Tor
+ client launches the pluggable transport proxy executable in
+ __path-to-binary__ using __options__ as its command-line options, and
+ forwards its traffic to it. It's the duty of that proxy to properly forward
+ the traffic to the bridge. (Default: none)
+
[[ClientUseIPv4]] **ClientUseIPv4** **0**|**1**::
If this option is set to 0, Tor will avoid connecting to directory servers
and entry nodes over IPv4. Note that clients with an IPv4
```Tor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/26646add support for multiple OutboundBindAddressExit IP(ranges)2023-04-03T16:39:16Znusenuadd support for multiple OutboundBindAddressExit IP(ranges)tor has support for dedicated outbound IP addresses
for on exit relays via OutboundBindAddressExit.
This parameter supports only a single IPv4 and a single IPv6 address.
I propose to add an extension of this feature to support IPv4 and ...tor has support for dedicated outbound IP addresses
for on exit relays via OutboundBindAddressExit.
This parameter supports only a single IPv4 and a single IPv6 address.
I propose to add an extension of this feature to support IPv4 and IPv6
ranges/prefixes.
The idea is to assign an IP address to each tor circuit. The exit IP
address must never change during the lifetime of the circuit.
Exit IP addresses would be randomly assigned to circuits. Once
the exit runs out of IPs it cycles through his pool of IPs again.
With IPv6 address space availability this can take a long time
with IPv4 it will be limited.
This aims to reduce the negative impact of few "bad" users on many "good"
users since they will not share the same IP address on the exit.
This might also have some negative? side effect since
it demultiplexes tor clients to multiple source IPs on the exit
and an external observer (not running the exit itself)
can tell clients apart by looking at source IPs.
Instead of doing it on the circuit level you could do it
based on time. Change the exit IP every 5 minutes (but
do _not_ change the exit IPs for _existing_ circuits even if they
live longer than 5 minutes).
https://lists.torproject.org/pipermail/tor-dev/2018-March/013036.htmlTor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40594Early log messages are swallowed by the log subsystem2023-04-03T16:40:10ZAlex XuEarly log messages are swallowed by the log subsystem### Steps to reproduce:
1. Add `tor_assert_nonfatal(0);` before `add_default_log_for_quiet_level(quiet);` in `src/app/main/main.c`.
2. Compile and run Tor.
### What is the current bug behavior?
Tor starts normally with no message prin...### Steps to reproduce:
1. Add `tor_assert_nonfatal(0);` before `add_default_log_for_quiet_level(quiet);` in `src/app/main/main.c`.
2. Compile and run Tor.
### What is the current bug behavior?
Tor starts normally with no message printed.
### What is the expected behavior?
A message is printed, or if not possible, Tor fails to start.
### Environment
- Which version of Tor are you using? master
- Which operating system are you using? N/A
- Which installation method did you use? from git
### Additional information
This is related to 6d8b614729bc8011d68a7234a81190ec11f6cd5f; commenting out that segment allows the message to be printed, but then all the other pre-logging messages are duplicated.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40192add unix Socket support to MetricsPort2024-03-05T15:38:50Znusenuadd unix Socket support to MetricsPorttor recently got support for `MetricsPort` in v0.4.5.1-alpha (#40063).
According to the man page MetricsPort does not support unix sockets (like SocksPort or ControlSocket).
Using a socket allows for better access control than for examp...tor recently got support for `MetricsPort` in v0.4.5.1-alpha (#40063).
According to the man page MetricsPort does not support unix sockets (like SocksPort or ControlSocket).
Using a socket allows for better access control than for example binding it to localhost and only allowing localhost in MetricsPortPolicy because that would allow any local process to access it.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/7870Retry on a new circuit for more reasons.2023-04-03T16:41:58ZRoger DingledineRetry on a new circuit for more reasons.In git commit 388ac4126 I added some code that will never be reached:
```
if (rh->length > 0 && edge_reason_is_retriable(reason) &&
[...]
case END_STREAM_REASON_CONNECTREFUSED:
if (!conn->chosen_exit_optional)
b...In git commit 388ac4126 I added some code that will never be reached:
```
if (rh->length > 0 && edge_reason_is_retriable(reason) &&
[...]
case END_STREAM_REASON_CONNECTREFUSED:
if (!conn->chosen_exit_optional)
break; /* break means it'll close, below */
/* Else fall through: expire this circuit, clear the
* chosen_exit_name field, and try again. */
[...]
case END_STREAM_REASON_TIMEOUT:
```
since those two reasons aren't included in edge_reason_is_retriable().
One fix would be just to remove those dead code lines.
But another fix would be to include both of those reasons in the is_retriable() list, to better tolerate broken exits -- for example, an exit that sets -j REJECT in an iptable rule, rather than putting everything in its exit policy; or an exit for which the routing to the destination has a loop, causing the ttl to expire and some internet router to send back an icmp unreachable.
The downsides are a) if will take many seconds longer before your connection fails, if it fails, and b) we throw away circuits even more often, since we'll now chew through several circuits every time you attempt a destination that is down or unreachable.
The upside is that users will see fewer false failures, in proportion to how many broken or misconfigured exits there are.
I'm not entirely sure which side of the fence I'm on here. I think I lean slightly towards retrying for these two cases.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.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40865Add padding to INTRODUCE1 messages2023-09-26T19:59:35ZNick MathewsonAdd padding to INTRODUCE1 messagesSee torspec!167 and related tickets for rationale.See torspec!167 and related tickets for rationale.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40869dirvote.c: maxunmeasurdbw is misspelled2023-10-26T14:19:51ZNick Mathewsondirvote.c: maxunmeasurdbw is misspelledHave a look at this (from dirvote.c, in `networkstatus_compute_consensus`)
```
{
if (consensus_method < MIN_METHOD_FOR_CORRECT_BWWEIGHTSCALE) {
max_unmeasured_bw_kb = (int32_t) extract_param_buggy(
params, ...Have a look at this (from dirvote.c, in `networkstatus_compute_consensus`)
```
{
if (consensus_method < MIN_METHOD_FOR_CORRECT_BWWEIGHTSCALE) {
max_unmeasured_bw_kb = (int32_t) extract_param_buggy(
params, "maxunmeasuredbw", DEFAULT_MAX_UNMEASURED_BW_KB);
} else {
max_unmeasured_bw_kb = dirvote_get_intermediate_param_value(
param_list, "maxunmeasurdbw", DEFAULT_MAX_UNMEASURED_BW_KB);
if (max_unmeasured_bw_kb < 1)
max_unmeasured_bw_kb = 1;
}
}
```
See the problem? In the first case, we are checking an option called "maxunmeasuredbw". In the second case, we are checking "maxunmeasurdbw".
Here it is in monospace:
* `maxunmeasuredbw`
* `maxunmeasurdbw`
Whooops! I must have introduced this bug back in nickm/tor@fb3704b45982e6a97dbad4e2d6e9cf7ba8fd1151, which went into 0.4.6.1-alpha.
I see two fixes:
1. Document the current behavior in dir-spec and param-spec. If HTTP can fix the spelling of "referer", we can leave this as-is.
2. Add a new consensus method to fix the spelling.
3. Go into a corner and curse general state of computing.
I favor option 1.
Found while working on #40835.Nick MathewsonNick Mathewson