The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-06-17T16:19:03Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29573Tests fail without network interface configured2022-06-17T16:19:03ZTracTests fail without network interface configuredI build packages on Linux as an unprivileged user inside a network namespace with no interfaces configured (to catch packages that try to use Internet resources during the build process). With tor 0.3.5.7 and earlier, this worked fine an...I build packages on Linux as an unprivileged user inside a network namespace with no interfaces configured (to catch packages that try to use Internet resources during the build process). With tor 0.3.5.7 and earlier, this worked fine and the test suite passed completely.
With tor 0.3.5.8, three test cases fail:
```
address/get_if_addrs_list_internal: Feb 24 12:59:28.031 [err] connect() failed: Network is unreachable
[get_if_addrs_list_internal FAILED]
address/get_if_addrs_list_no_internal: Feb 24 12:59:28.040 [err] connect() failed: Network is unreachable
[get_if_addrs_list_no_internal FAILED]
address/get_if_addrs: Feb 24 12:59:28.309 [err] connect() failed: Network is unreachable
[get_if_addrs FAILED]
```
Here's strace output for one of the failures:
```
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_UDP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(9), sin_addr=inet_addr("18.0.0.1")}, 16) = -1 ENETUNREACH (Network is unreachable)
```
So this looks like get_interface_address6_via_udp_socket_hack failing - comments in the tests suggest that they ought to be getting an empty list rather than an error in this circumstance?
**Trac**:
**Username**: atsampsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29232Write a function that prints a link specifier and link specifier list2021-09-16T14:24:10ZteorWrite a function that prints a link specifier and link specifier listWe want to print link specifiers for debugging, and log link specifiers, but we don't have an easy way to do that.We want to print link specifiers for debugging, and log link specifiers, but we don't have an easy way to do that.https://gitlab.torproject.org/tpo/core/tor/-/issues/29131Split rephist.c into modules for each type of statistic2021-09-16T14:24:09ZteorSplit rephist.c into modules for each type of statisticLet's split up rephist.c by statistic. We can also split out the stat-specific structs at the same time.
If we do this in 0.4.1, it will help us remove the bandwidth stats as part of our Sponsor V work.Let's split up rephist.c by statistic. We can also split out the stat-specific structs at the same time.
If we do this in 0.4.1, it will help us remove the bandwidth stats as part of our Sponsor V work.https://gitlab.torproject.org/tpo/core/tor/-/issues/29110Allow passing seed value to slow/prop_distr/* tests2020-07-28T23:49:33ZAlexander Færøyahf@torproject.orgAllow passing seed value to slow/prop_distr/* testsIt would be useful to be able to pass the seed as an environment variables or argument to the `slow/prop_distr/...` tests to quickly check if one can reproduce a known test error with a given seed.
This is related to legacy/trac#29109.It would be useful to be able to pass the seed as an environment variables or argument to the `slow/prop_distr/...` tests to quickly check if one can reproduce a known test error with a given seed.
This is related to legacy/trac#29109.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29015Document tor_ersatz_socketpair() and the functions it calls2021-07-22T16:20:05ZteorDocument tor_ersatz_socketpair() and the functions it callsThe function comments in socketpair.c are missing or incomplete.
Maybe we should add function comments, using the tor_socketpair() comment as a starting point?
https://github.com/torproject/tor/blob/701eaef980de4f7dbb5c31c4fee9b7e1e266...The function comments in socketpair.c are missing or incomplete.
Maybe we should add function comments, using the tor_socketpair() comment as a starting point?
https://github.com/torproject/tor/blob/701eaef980de4f7dbb5c31c4fee9b7e1e266d7a1/src/lib/net/socket.c#L450Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28984Update dir-spec observed bandwidth to 5 days2021-07-22T16:20:05ZteorUpdate dir-spec observed bandwidth to 5 daysIn legacy/trac#23856 we accidentally updated the observed bandwidth to 5 days from 1 day. It's a good change for privacy, and it doesn't seem to affect load-balancing too much.
So let's update the spec, and review as part of sbws 1.1.In legacy/trac#23856 we accidentally updated the observed bandwidth to 5 days from 1 day. It's a good change for privacy, and it doesn't seem to affect load-balancing too much.
So let's update the spec, and review as part of sbws 1.1.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28941tor-spec: Wrong default HiddenServiceVersion value in section 3.27 of control...2021-07-22T16:20:05Zrl1987tor-spec: Wrong default HiddenServiceVersion value in section 3.27 of control-spec.txt```
1695 (The "NEW:BEST" option obeys the HiddenServiceVersion torrc option default
1696 value. Currently it is 2.)
```
Since 0.3.5.1-alpha, default `HiddenServiceVersion` is 3.```
1695 (The "NEW:BEST" option obeys the HiddenServiceVersion torrc option default
1696 value. Currently it is 2.)
```
Since 0.3.5.1-alpha, default `HiddenServiceVersion` is 3.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28920rep_hist_log_link_protocol_counts() only knows about 4 link protocols, but To...2020-06-27T13:51:20Zteorrep_hist_log_link_protocol_counts() only knows about 4 link protocols, but Tor has 5Maybe we should just log all the versions in a loop?Maybe we should just log all the versions in a loop?Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28919Log IPv4 and IPv6 connections in Tor's heartbeat message2020-06-27T13:51:21ZteorLog IPv4 and IPv6 connections in Tor's heartbeat messageDo we already keep IPv4 and IPv6 statistics?
If we do, then this ticket is easy.
If not, then it's a bit harder, because we'll need to add some code to rephist (or wherever we get the other stats from).Do we already keep IPv4 and IPv6 statistics?
If we do, then this ticket is easy.
If not, then it's a bit harder, because we'll need to add some code to rephist (or wherever we get the other stats from).Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28895"Your guard" log messages are causing confusion2020-06-27T13:51:21ZGeorge Kadianakis"Your guard" log messages are causing confusionSee this thread https://lists.torproject.org/pipermail/tor-talk/2018-December/044756.html for some confusion that is called by the pathbias log messages refering to guards.
We should improve them since they tend to confuse and agitate u...See this thread https://lists.torproject.org/pipermail/tor-talk/2018-December/044756.html for some confusion that is called by the pathbias log messages refering to guards.
We should improve them since they tend to confuse and agitate users.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28805ControlPort has undocumented behavior2021-07-22T16:20:04ZTracControlPort has undocumented behavior== Problem 1
`ControlPort`'s value can be set to address:port though `man torrc` says that only port can be specified.
== Problem 2
Option `ControlPort` can be set few times to bind to different "address:port"s. This is also not docum...== Problem 1
`ControlPort`'s value can be set to address:port though `man torrc` says that only port can be specified.
== Problem 2
Option `ControlPort` can be set few times to bind to different "address:port"s. This is also not documented. Other options which can be set multiple times are explicitly documented with a statement like
```
This directive can be specified multiple times to bind to multiple addresses/ports
```
for `SocksPort`.
Original comment about these issues is [[http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28676#comment:15|here]].
**Trac**:
**Username**: wagonTor: 0.4.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28779Remove double function declarations in circuitpadding.c/test_circuitpadding.c2021-09-16T14:27:19ZGeorge KadianakisRemove double function declarations in circuitpadding.c/test_circuitpadding.cWe can use the STATIC macro to avoid defining every function twice.
We can also rearrange the circuitpadding.c functions so that we don't need to define them on top of the .c file.We can use the STATIC macro to avoid defining every function twice.
We can also rearrange the circuitpadding.c functions so that we don't need to define them on top of the .c file.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28760Option/* format for ControlPort options needs to be homogeneous2021-06-18T18:29:56ZTracOption/* format for ControlPort options needs to be homogeneousAccording to [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|control-spec.txt]]:
> The OptionPrefix form indicates a number of options beginning with the prefix. So if `config/*` is listed, other options beginning with...According to [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|control-spec.txt]]:
> The OptionPrefix form indicates a number of options beginning with the prefix. So if `config/*` is listed, other options beginning with `config/` will work, but `config/*` itself is not an option.
In Nyx and `tor-prompt` interpreters' `/help`, if the format `Option/*` is used to name a group of options (each of them is still described separately), it must be done for everything. However, e.g., we have many options inside `accounting`, but key `accounting/*` doesn't exist:
```
accounting/bytes - Number of bytes read/written so far in the accounting interval.
accounting/bytes-left - Number of bytes left to write/read so far in the accounting interval.
accounting/enabled - Is accounting currently enabled?
accounting/hibernating - Are we hibernating or awake?
accounting/interval-end - Time when the accounting period ends.
accounting/interval-start - Time when the accounting period starts.
accounting/interval-wake - Time to wake up in this accounting period.
```
Compare it with:
```
config/* - Current configuration values.
config/defaults - List of default values for configuration options. See also config/names
config/names - List of configuration options, types, and documentation.
```
If grouping syntax is used, it should be used everywhere (for all groups) or nowhere. Otherwise, it is confusing, because for many other options the syntax `option/*` implies that something not listed here (in list of options) should be substituted (e.g. fingerprint of a relay, IP address, etc.).
P.S. At first glance it looks like Nyx controller interpreter's bug, but atagar [[https://trac.torproject.org/projects/tor/ticket/28300#comment:5|says]] that it is taken literally from `control-spec.txt`. Initially it was reported in [[comment](https://trac.torproject.org/projects/tor/ticket/28300#comment:6|this)]. Separate ticket was created because of [[suggestion](https://trac.torproject.org/projects/tor/ticket/28676#comment:8|teor's)].
**Trac**:
**Username**: wagonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28757Remove deprecated ControlPort commands from GETINFO info/names listing2020-06-27T13:51:27ZTracRemove deprecated ControlPort commands from GETINFO info/names listingIf `GETINFO` commands `status/version/num-concurring` and `status/version/num-versioning` are used in Nyx or `tor-prompt`, Tor writes to its log file:
```
[warn] status/version/num-concurring is deprecated; it no longer gives useful inf...If `GETINFO` commands `status/version/num-concurring` and `status/version/num-versioning` are used in Nyx or `tor-prompt`, Tor writes to its log file:
```
[warn] status/version/num-concurring is deprecated; it no longer gives useful information
[warn] status/version/num-versioning is deprecated; it no longer gives useful information
```
These commands should be removed from interpreter's `/help GETINFO` listing. They are deprecated according to [[https://gitweb.torproject.org/torspec.git/tree/control-spec.txt|control-spec.txt]]:
```
"status/version/num-concurring"
"status/version/num-versioning"
These options are deprecated; they no longer give useful information.
```
[[0.2.0.30](https://blog.torproject.org/tor-02030-released-stable|since)] (more than 10 years):
> o Newly deprecated features:
> - The `status/version/num-versioning` and `status/version/num-concurring` `GETINFO` controller options are no longer useful in the v3 directory protocol: treat them as deprecated, and warn when they're used.
Probably, there are also other deprecated commands in `/help` listing. They should be removed too.
P.S. Initially it was reported in [[comment](https://trac.torproject.org/projects/tor/ticket/28300#comment:4|this)]. teor [[http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28676#comment:8|recommended]] to create separate ticket.
**Trac**:
**Username**: wagonTor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/28734CIRC_BW is only for origin circuits2021-07-22T16:20:04ZteorCIRC_BW is only for origin circuitsThe CIRC_BW event is only sent for origin circuits:
https://github.com/torproject/torspec/blob/master/control-spec.txt#L2990
We should update the control spec:
https://lists.torproject.org/pipermail/tor-relays/2018-December/016696.htmlThe CIRC_BW event is only sent for origin circuits:
https://github.com/torproject/torspec/blob/master/control-spec.txt#L2990
We should update the control spec:
https://lists.torproject.org/pipermail/tor-relays/2018-December/016696.htmlhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28698When circuit times are fixed, they can't be "relaxed"2020-06-27T13:51:29ZteorWhen circuit times are fixed, they can't be "relaxed"In legacy/trac#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 t...In legacy/trac#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/tpo/core/tor/-/issues/28623use documentation IP ranges for documentation (manpage)2021-07-22T16:20:04Znusenuuse documentation IP ranges for documentation (manpage)https://phabricator.whonix.org/T878 made me read
https://www.torproject.org/docs/tor-manual.html.en#MapAddress
which uses other peoples IP addresses for examples.
That manual entry might have contributed to that bug.
Please consider us...https://phabricator.whonix.org/T878 made me read
https://www.torproject.org/docs/tor-manual.html.en#MapAddress
which uses other peoples IP addresses for examples.
That manual entry might have contributed to that bug.
Please consider using documentation IP ranges
example: 192.0.2.0/24
https://tools.ietf.org/html/rfc5737Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28560hs: Mention in the manpage that Sandbox and adding a service with the control...2021-09-30T13:25:26ZDavid Gouletdgoulet@torproject.orghs: Mention in the manpage that Sandbox and adding a service with the control port failsFrom legacy/trac#16106.
We can't tell the sandbox about a new `HiddenServiceDir` at runtime so this will always fail until we get a better sandbox system.
For now, we should at least document it in the manpage.From legacy/trac#16106.
We can't tell the sandbox about a new `HiddenServiceDir` at runtime so this will always fail until we get a better sandbox system.
For now, we should at least document it in the manpage.Tor: 0.4.0.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/28344Should we log \r\n on Windows?2022-06-17T16:36:14ZteorShould we log \r\n on Windows?Tor's logging code terminates strings with \n.
When I run tor.exe via the command prompt on Windows, I don't see any of the log output, because there's no \r at the end of the line.
Should we make tor log \r\n on Windows?Tor's logging code terminates strings with \n.
When I run tor.exe via the command prompt on Windows, I don't see any of the log output, because there's no \r at the end of the line.
Should we make tor log \r\n on Windows?https://gitlab.torproject.org/tpo/core/tor/-/issues/28113notify systemd if shutdown will be longer than 30 seconds2022-06-17T18:19:00ZAlex Xunotify systemd if shutdown will be longer than 30 secondscurrently systemd just kills tor if the user sets ShutdownWaitLength more than 30 seconds. we should tell systemd not to kill tor.currently systemd just kills tor if the user sets ShutdownWaitLength more than 30 seconds. we should tell systemd not to kill tor.