The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-06-17T12:59:00Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28311Call expand_filename (e.g. for ~ expansion) on all FILENAME config options2022-06-17T12:59:00ZteorCall expand_filename (e.g. for ~ expansion) on all FILENAME config optionsSplit off legacy/trac#28298:
Replying to [arma](#note_4):
> Ok, that above fix is bad, because it will complain when you set DataDirectory to e.g. `~/.test` -- which is actually an absolute path, even if it doesn't start with `/`.
"~" ...Split off legacy/trac#28298:
Replying to [arma](#note_4):
> Ok, that above fix is bad, because it will complain when you set DataDirectory to e.g. `~/.test` -- which is actually an absolute path, even if it doesn't start with `/`.
"~" expansion is not universal: it only works in some shells, some languages, and some applications.
In particular, "~" expansion is not a documented feature of path_is_relative() or make_path_absolute(). We can add it as a feature if you want.https://gitlab.torproject.org/tpo/core/tor/-/issues/28309Log the rust version when printing other library versions2022-06-17T18:56:10ZteorLog the rust version when printing other library versionstor --library-versions prints the versions of Tor's library dependencies.
Would it be useful for it to print the rust version as well?
Or the versions of our rust library dependencies?
Tor also prints the OS version and library version...tor --library-versions prints the versions of Tor's library dependencies.
Would it be useful for it to print the rust version as well?
Or the versions of our rust library dependencies?
Tor also prints the OS version and library versions when it starts up. We could add the rust version and significant rust library versions to that log message.https://gitlab.torproject.org/tpo/core/tor/-/issues/28308Log the Tor version before running the unit tests2020-06-27T13:51:45ZteorLog the Tor version before running the unit testsThis feature is useful by itself. It also tests get_uname() for legacy/trac#28096.This feature is useful by itself. It also tests get_uname() for legacy/trac#28096.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28307DisableNetwork is set2020-07-28T23:26:53ZTracDisableNetwork is setwhen i try to open tor i see this log
[NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
and this
Delaying directory fetches: DisableNetwork is set.
...when i try to open tor i see this log
[NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
and this
Delaying directory fetches: DisableNetwork is set.
and i don't see any disable network words in any torcc file, how can i fix it?
**Trac**:
**Username**: Cyber 404Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28303Include sys/time.h in timers.c and time_fmt.c to fix OpenBSD build2020-06-27T13:51:45ZTracInclude sys/time.h in timers.c and time_fmt.c to fix OpenBSD buildThe files `src/lib/encoding/time_fmt.c` and `src/lib/evloop/timers.c` both need to include `sys/time.h` for `struct timeval`. Otherwise compilation fails on OpenBSD with the following errors:
```
CC src/lib/encoding/time_fmt.o
...The files `src/lib/encoding/time_fmt.c` and `src/lib/evloop/timers.c` both need to include `sys/time.h` for `struct timeval`. Otherwise compilation fails on OpenBSD with the following errors:
```
CC src/lib/encoding/time_fmt.o
src/lib/encoding/time_fmt.c: In function 'format_iso_time_nospace_usec':
src/lib/encoding/time_fmt.c:318: error: dereferencing pointer to incomplete type
src/lib/encoding/time_fmt.c:319: error: dereferencing pointer to incomplete type
gmake[1]: *** [Makefile:9088: src/lib/encoding/time_fmt.o] Error 1
```
and
```
CC src/lib/evloop/timers.o
src/lib/evloop/timers.c: In function 'tv_to_timeout':
src/lib/evloop/timers.c:115: error: dereferencing pointer to incomplete type
src/lib/evloop/timers.c:116: error: dereferencing pointer to incomplete type
src/lib/evloop/timers.c: In function 'timeout_to_tv':
src/lib/evloop/timers.c:128: error: dereferencing pointer to incomplete type
src/lib/evloop/timers.c:129: error: dereferencing pointer to incomplete type
src/lib/evloop/timers.c: In function 'libevent_timer_reschedule':
src/lib/evloop/timers.c:156: error: storage size of 'd' isn't known
src/lib/evloop/timers.c:156: warning: unused variable 'd'
gmake[1]: *** [Makefile:9088: src/lib/evloop/timers.o] Error 1
```
This change does not appear to be necessary on FreeBSD or NetBSD.
**Trac**:
**Username**: kjakTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28298Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory2020-06-27T13:51:45ZRoger DingledineTor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectoryIn 0.3.2.1-alpha we fixed legacy/trac#22731 (in commit 6fea44c6): we started refusing to start if RunAsDaemon is set and also any of a variety of config options are set to a relative value.
And then in 0.3.3.1-alpha we did commit 192be0...In 0.3.2.1-alpha we fixed legacy/trac#22731 (in commit 6fea44c6): we started refusing to start if RunAsDaemon is set and also any of a variety of config options are set to a relative value.
And then in 0.3.3.1-alpha we did commit 192be006, which split the original options->DataDirectory into a new DataDirectory_option variable.
But warn_about_relative_paths() continues to look at
```
n += warn_if_option_path_is_relative("DataDirectory",options->DataDirectory);
```
and that function is called near the top of options_validate() -- before we call validate_data_directories() which is what populates options->DataDirectory.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28286Missing header in freespace.c when building for Android2020-06-27T13:51:45ZTracMissing header in freespace.c when building for AndroidBuilding tor 0.3.5.3-alpha for Android fails with the following error:
```
src/lib/fs/freespace.c: In function 'tor_get_avail_disk_space':
src/lib/fs/freespace.c:59:3: error: 'errno' undeclared (first use in this function)
errno = ENO...Building tor 0.3.5.3-alpha for Android fails with the following error:
```
src/lib/fs/freespace.c: In function 'tor_get_avail_disk_space':
src/lib/fs/freespace.c:59:3: error: 'errno' undeclared (first use in this function)
errno = ENOSYS;
^
src/lib/fs/freespace.c:59:3: note: each undeclared identifier is reported only once for each function it appears in
src/lib/fs/freespace.c:59:11: error: 'ENOSYS' undeclared (first use in this function)
errno = ENOSYS;
^
Makefile:9088: recipe for target 'src/lib/fs/freespace.o' failed
```
On Android <errno.h> should be included in the header.
**Trac**:
**Username**: goapunkTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28281outline of high-level bootstrap tracker abstractions2020-06-27T13:51:45ZTaylor Yuoutline of high-level bootstrap tracker abstractionsThis is a placeholder to summarize the high-level bootstrap tracking abstractions I talked about with Nick.This is a placeholder to summarize the high-level bootstrap tracking abstractions I talked about with Nick.Tor: unspecifiedTaylor YuTaylor Yuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28280control: Add a key to GETINFO to get the DoS subsystem stats2022-06-22T15:42:54ZDavid Gouletdgoulet@torproject.orgcontrol: Add a key to GETINFO to get the DoS subsystem statsThe DoS subsystem keeps track of statistics that are logged in the heartbeat with `dos_log_heartbeat()`. I would like those to be exposed to the control port so it can be collected and graph over time (improve relay monitoring).
(Follow...The DoS subsystem keeps track of statistics that are logged in the heartbeat with `dos_log_heartbeat()`. I would like those to be exposed to the control port so it can be collected and graph over time (improve relay monitoring).
(Follows the idea behind legacy/trac#28279)https://gitlab.torproject.org/tpo/core/tor/-/issues/28279control: Add a key to GETINFO to fetch the circuit onion handshake rephist va...2020-07-01T16:35:47ZDavid Gouletdgoulet@torproject.orgcontrol: Add a key to GETINFO to fetch the circuit onion handshake rephist valuesBasically something that would export the rephist value of the onion handshakes:
```
onion_handshakes_assigned
onion_handshakes_requested
```
The heartbeat uses `rep_hist_log_circuit_handshake_stats()` to log the ntor and tap stats. I ...Basically something that would export the rephist value of the onion handshakes:
```
onion_handshakes_assigned
onion_handshakes_requested
```
The heartbeat uses `rep_hist_log_circuit_handshake_stats()` to log the ntor and tap stats. I want those from the GETINFO command in order to be able to graph and keep stats over time of those values.Tor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/28275hs-v3: Rotate intro points and close RP circuits when removing client auth se...2021-09-30T13:25:26ZDavid Gouletdgoulet@torproject.orghs-v3: Rotate intro points and close RP circuits when removing client auth service sideOn the service side (only), when a client authorization is removed and then tor is HUP, right now the service notices that and re-upload a new descriptor containing that new auth.
However, the into points are most likely kept as is (if ...On the service side (only), when a client authorization is removed and then tor is HUP, right now the service notices that and re-upload a new descriptor containing that new auth.
However, the into points are most likely kept as is (if no normal rotation happened during re-build) which means that a revoked client can still access the service with their cached descriptor because the intro points are still valid...
Furthermore, the RP circuits for that client aren't closed.
Security wise, that is not ideal to have a "not really revoked client" ;). Fortunately, only applies to 0.3.5.1-alpha and onward so no need for a TROVE.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28269Repeated HSFETCH queries fail with QUERY_NO_HSDIR2021-09-30T13:25:26ZDamian JohnsonRepeated HSFETCH queries fail with QUERY_NO_HSDIRHi lovely network team. Iain is working on a script to inform him of hidden service descriptor age. He's using stem to fetch them but unfortunately after a few HSFETCH calls it begins to fail with QUERY_NO_HSDIR. Maybe some attempt at ra...Hi lovely network team. Iain is working on a script to inform him of hidden service descriptor age. He's using stem to fetch them but unfortunately after a few HSFETCH calls it begins to fail with QUERY_NO_HSDIR. Maybe some attempt at rate limiting? Once the tor process gets into a borked state it doesn't seem to recover until I bounce the tor process.
Here's an example of my first query (which succeeds)...
```
>>> SETEVENTS HS_DESC HS_DESC_CONTENT
250 OK
>>> HSFETCH facebookcorewwwi
250 OK
>>> /events
HS_DESC_CONTENT facebookcorewwwi 3jjxhgi72xguhnihk4nwzrcpyvwf3ml5 $DA722ECCB9C0DE462C4FA585B93C99CCCA1C7547~SIRDRAKE2018
rendezvous-service-descriptor 3jjxhgi72xguhnihk4nwzrcpyvwf3ml5
version 2
permanent-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBALfng/krEfrBcvblDiM3PAkowkiAKxLoTsXt3nPEzyTP6Cw+Gdr0ODje
hmxTngN1pKiH7szk4Q1p2RabOrUHWwXmGXeDDNs00fcyU6HupgqsCoKOqCsmPac6
/58apC64A7xHeS02wtfWJp6qiZ8i6GGu6xWXRWux+ShPgcHvkajRAgMahU8=
-----END RSA PUBLIC KEY-----
secret-id-part wuyfue4erz2hlh4d5o4kduweosco6rw4
publication-time 2018-10-31 18:00:00
protocol-versions 2,3
introduction-points
-----BEGIN MESSAGE-----
aW50cm9kdWN0aW9uLXBvaW50IHR6c3U3ZXh5amVlZWU2cm92cDd1Z25lM3pxemlo
ZHk1CmlwLWFkZHJlc3MgMTQ0Ljc2Ljk2LjYKb25pb24tcG9ydCA5MDAxCm9uaW9u
... lot more base64...
L1UycythTGNtYmhITGJPWlhZRjRMcERTV1R3THkwb0ZzTEFnTUJBQUU9Ci0tLS0t
RU5EIFJTQSBQVUJMSUMgS0VZLS0tLS0KCg==
-----END MESSAGE-----
signature
-----BEGIN SIGNATURE-----
cMLWu42NG+I5hH9QAHZUQ8eDGCUzcny/uN/FwAYiLsUSc3QLg7MKbRTZ3v2ARonB
wcUgEAGpO4wDjuEj2ivNmpt6U0smJ7nM5KTWy4l0732QnTeSEX+P53qIJ7KwxDro
+JyBARfK4orCMieHuxYtJop6YgVRQ8XN6NtP6NiDrWY=
-----END SIGNATURE-----
OK
HS_DESC RECEIVED facebookcorewwwi NO_AUTH $DA722ECCB9C0DE462C4FA585B93C99CCCA1C7547~SIRDRAKE2018 3jjxhgi72xguhnihk4nwzrcpyvwf3ml5
HS_DESC REQUESTED facebookcorewwwi NO_AUTH $DA722ECCB9C0DE462C4FA585B93C99CCCA1C7547~SIRDRAKE2018 3jjxhgi72xguhnihk4nwzrcpyvwf3ml5
```
... and here's an example of my fourth onward, which always fail.
```
>>> /events clear
cleared event backlog
>>> HSFETCH facebookcorewwwi
250 OK
>>> /events
HS_DESC_CONTENT facebookcorewwwi 3jjxhgi72xguhnihk4nwzrcpyvwf3ml5 UNKNOWN
OK
HS_DESC FAILED facebookcorewwwi NO_AUTH UNKNOWN REASON=QUERY_NO_HSDIR
HS_DESC_CONTENT facebookcorewwwi csq76xfzmtyepzmkhzz2lb7ja3vmylwu UNKNOWN
OK
HS_DESC FAILED facebookcorewwwi NO_AUTH UNKNOWN REASON=QUERY_NO_HSDIR
```
I'm filing this on irl's behalf. If anything's needed from me on the stem front just let me know.Tor: 0.4.1.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/28266Implement proposal 298-canonical-families.txt2020-06-27T13:51:46ZNick MathewsonImplement proposal 298-canonical-families.txtThis will improve the performance of legacy/trac#27359 by making more family lines match.This will improve the performance of legacy/trac#27359 by making more family lines match.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28265Should Tor 0.3.5 be the last 0.3.x since it's an LTS?2020-06-27T13:51:46ZRoger DingledineShould Tor 0.3.5 be the last 0.3.x since it's an LTS?Tor 0.2.9 was the final Tor on the 0.2.x branch, and it was an LTS.
We could follow that pattern and move from 0.3.5 to 0.4.0.
The only downside I can see is that we hasten our arrival to Tor 1.0.0. But is that so bad?Tor 0.2.9 was the final Tor on the 0.2.x branch, and it was an LTS.
We could follow that pattern and move from 0.3.5 to 0.4.0.
The only downside I can see is that we hasten our arrival to Tor 1.0.0. But is that so bad?Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28264spec: Actually do base32 in the client auth pubkey example2021-09-30T13:25:26ZDavid Gouletdgoulet@torproject.orgspec: Actually do base32 in the client auth pubkey examplefrom https://trac.torproject.org/projects/tor/ticket/20700#comment:51
Spec fix is here: https://github.com/torproject/torspec/pull/40from https://trac.torproject.org/projects/tor/ticket/20700#comment:51
Spec fix is here: https://github.com/torproject/torspec/pull/40Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28262HS v3 auth-private files loaded twice on startup2020-06-27T13:51:46ZTracHS v3 auth-private files loaded twice on startuptor-0.3.5.3-alpha is loading the contents of ClientOnionAuthDir twice on startup. This is occurring on Win32; I don't know about other platforms.
I learnt this indirectly because Tor complains twice about the bunch of private files who...tor-0.3.5.3-alpha is loading the contents of ClientOnionAuthDir twice on startup. This is occurring on Win32; I don't know about other platforms.
I learnt this indirectly because Tor complains twice about the bunch of private files whose extensions are invalid. Possibly this is not visible unless you have invalid files. And possibly the valid entries are not loaded twice, but once then overriden, but still.
**Trac**:
**Username**: jchevalihttps://gitlab.torproject.org/tpo/core/tor/-/issues/28257CID 1440805: Memory leak in configured_nameserver_address() due to #219002020-06-27T13:51:46ZteorCID 1440805: Memory leak in configured_nameserver_address() due to #21900```
** CID 1440805: Resource leaks (RESOURCE_LEAK)
/src/feature/relay/dns.c: 1389 in configured_nameserver_address()
________________________________________________________________________________________________________
*** CID 144...```
** CID 1440805: Resource leaks (RESOURCE_LEAK)
/src/feature/relay/dns.c: 1389 in configured_nameserver_address()
________________________________________________________________________________________________________
*** CID 1440805: Resource leaks (RESOURCE_LEAK)
/src/feature/relay/dns.c: 1389 in configured_nameserver_address()
1383 tor_addr_t *tor_addr = tor_malloc(sizeof(tor_addr_t));
1384 if (tor_addr_from_sockaddr(tor_addr,
1385 (const struct sockaddr *)&sa,
1386 NULL) == 0) {
1387 return tor_addr;
1388 }
CID 1440805: Resource leaks (RESOURCE_LEAK)
Variable "tor_addr" going out of scope leaks the storage it points to.
1389 }
1390
1391 return NULL;
1392 }
1393 #endif
```Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28256Add tests for UTF-8 encoded torrcs on Windows2022-06-16T18:02:45ZteorAdd tests for UTF-8 encoded torrcs on WindowsWe need these tests for legacy/trac#25729.We need these tests for legacy/trac#25729.https://gitlab.torproject.org/tpo/core/tor/-/issues/28255verify guard selection consensus expiry constraints2020-06-27T13:51:47ZTaylor Yuverify guard selection consensus expiry constraintsThe hypothesis in legacy/trac#23605 is that bootstrapping can get stuck at legacy/trac#23605 if there is enough clock skew for the consensus to be expired but still "reasonably live". Let's verify this and try to record more details.The hypothesis in legacy/trac#23605 is that bootstrapping can get stuck at legacy/trac#23605 if there is enough clock skew for the consensus to be expired but still "reasonably live". Let's verify this and try to record more details.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28250"___UsingTestNetworkDefaults" not in "GETINFO config/names"2020-07-28T23:28:06ZTrac"___UsingTestNetworkDefaults" not in "GETINFO config/names"I played around with my little Tor relay monitor and when I tried to get the config options I noticed that the option `__UsingTestNetworkDefaults` is not returned by "GETINFO config/names". It is however returned by "GETINFO config/defau...I played around with my little Tor relay monitor and when I tried to get the config options I noticed that the option `__UsingTestNetworkDefaults` is not returned by "GETINFO config/names". It is however returned by "GETINFO config/defaults"
Maybe an easy fix to put in the low priority queue?
**Trac**:
**Username**: LogformeTor: unspecified