The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-10-11T23:40:04Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25193dos: Avoid blacklisting Exit relays2022-10-11T23:40:04ZDavid Gouletdgoulet@torproject.orgdos: Avoid blacklisting Exit relaysIt is possible to do "tor-in-tor" meaning a tor client connection can exit the network and come back at a Guard node.
And if this happens to be detected by the DoS subsystem, we'll blacklist the Exit relay for a while. That is *NOT* goo...It is possible to do "tor-in-tor" meaning a tor client connection can exit the network and come back at a Guard node.
And if this happens to be detected by the DoS subsystem, we'll blacklist the Exit relay for a while. That is *NOT* good.
Now that we have legacy/trac#25183, we can lookup the inbound address to learn if we know it. And if we do, don't consider it a potential malicious client that we need to look at.
That is one part of the solution, the second part is legacy/trac#2667 so we actually prevent reentry from Exit but that part won't be backported just yet (if ever).
This work will be part of legacy/trac#24902 so once merge_ready, it will be merged into my branch `ticket24902_029_05`.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25192change of bandwidth accounting intveral from 4 to 24 hours results in unreaso...2020-06-27T13:54:11Zstarlightchange of bandwidth accounting intveral from 4 to 24 hours results in unreasonable memory consumptionThe recent change of relay bandwidth reporting has increased the related memory consumption on a mid-size relay from about 200MB to about 1.2GB (i.e. a sixfold increase). The memory dedicated to this function has become unreasonably la...The recent change of relay bandwidth reporting has increased the related memory consumption on a mid-size relay from about 200MB to about 1.2GB (i.e. a sixfold increase). The memory dedicated to this function has become unreasonably large.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25188Spec bug in formal definition of Document in dir-spec.txt2020-06-27T13:54:11ZTracSpec bug in formal definition of Document in dir-spec.txtI was attempting to write a parser that reads vote/consensus documents using the the formal definition [here](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n210). However, I noticed an ambiguity.
Using only the formal defi...I was attempting to write a parser that reads vote/consensus documents using the the formal definition [here](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n210). However, I noticed an ambiguity.
Using only the formal definition, the following:
```
directory-signature 13241234321 12343234
-----BEGIN SIGNATURE-----
00thisisvalidbase64data12345
-----END SIGNATURE-----
```
Could be potentially parsed as
```
Document(
Item(
KeywordLine(
Keyword(KeywordChar+("directory-signature")),
WS,
ArgumentChar+("13241234321 12343234"),
NL
)
),
Item(
KeywordLine(
Keyword(KeywordChar+("-----BEGIN")),
WS,
ArgumentChar+("SIGNATURE-----"),
NL
)
),
Item(
KeywordLine(
Keyword(KeywordChar+("00thisisvalidbase64data12345"))
WS,
ArgumentChar+("SIGNATURE-----"),
NL
)
),
Item(
KeywordLine(
Keyword(KeywordChar+("-----END")),
WS,
ArgumentChar+("SIGNATURE-----"),
NL
)
),
)
```
When the correct parsing would be
```
Document(
Item(
KeywordLine(
Keyword(KeywordChar+("directory-signature")),
WS,
ArgumentChar+("13241234321 12343234"),
NL
),
Object(
BeginLine(
"-----BEGIN ",
Keyword(KeywordChar+("SIGNATURE")),
"-----",
NL
),
Base64-encoded-data("00thisisvalidbase64data12345"),
EndLine(
"-----END ",
Keyword(KeywordChar+("SIGNATURE")),
"-----",
NL
),
),
),
)
```
A potential change to the spec (assuming that keywords will never start with "-") that would prevent would be to replace
```
Keyword = KeywordChar+
KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
```
with
```
Keyword = KeywordStartChar KeywordChar*
KeywordStartChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9'
KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
```
**Trac**:
**Username**: witchof0x20Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25185Create utilities for using Rust static strings in C2020-06-27T13:54:11ZIsis LovecruftCreate utilities for using Rust static strings in CThis is a continuation of legacy/trac#25127, to provide some utilities for working with static strings across the FFI boundary without accidentally introducing leaks.This is a continuation of legacy/trac#25127, to provide some utilities for working with static strings across the FFI boundary without accidentally introducing leaks.Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/25183Implement a way to tell if an IP address is a known relay2022-10-11T23:40:04ZDavid Gouletdgoulet@torproject.orgImplement a way to tell if an IP address is a known relayFor the DoS mitigation subsystem (legacy/trac#24902), we need a way to lookup the connection address and *quickly* know if it is a known relay or not. This is also needed for legacy/trac#2667 which would prevent Exit to reenter the netwo...For the DoS mitigation subsystem (legacy/trac#24902), we need a way to lookup the connection address and *quickly* know if it is a known relay or not. This is also needed for legacy/trac#2667 which would prevent Exit to reenter the network.
nickm has started a branch to have IP addresses with bloom filter: `address_set_029`.
Next step is to use that and bridge it with the nodelist so we can lookup an IP address and learn if it is known or not (not get the `node_t` back, that would require more work and probably lose in performance).Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25182systemd unit file starts Tor before IPv6 address is available2020-06-27T13:54:12ZSteven Murdochsystemd unit file starts Tor before IPv6 address is availableOn Ubuntu xenial, systemd starts Tor before the IPv6 address is available and so Tor fails to assign an IPv6 address then exits. systemd tries to restart Tor (I think three times) but even by the last time there's still no IPv6 address a...On Ubuntu xenial, systemd starts Tor before the IPv6 address is available and so Tor fails to assign an IPv6 address then exits. systemd tries to restart Tor (I think three times) but even by the last time there's still no IPv6 address assigned and hence Tor fails to start.
As a work-around I copied `/lib/systemd/system/tor*` to `/etc/systemd/system/` and added `RestartSec=10` to the `[Service]` section of `tor@default.service` and `tor@.service`. This slows down the restart such that by the second time tor starts, there is an IPv6 address available.
See log file below.
```
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.587 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.588 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1313]: Feb 08 15:06:28.591 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1313]: Configuration was valid
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor 0.3.3.1-alpha (git-dc340725f08717e3) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2g, Zlib 1.2.8, Liblzma 5.1
.0alpha, and Libzstd N/A.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.651 [notice] Read configuration file "/etc/tor/torrc".
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Scheduler type KIST has been enabled.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening OR listener on [2001:630:212:2a8:a6bf:1ff:fe25:b961]:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Could not bind to 2001:630:212:2a8:a6bf:1ff:fe25:b961:9001: Cannot assign requested address
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Opening Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Socks listener on 127.0.0.1:9050
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed OR listener on 0.0.0.0:9001
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [notice] Closing partially-constructed Directory listener on 0.0.0.0:9030
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
Feb 08 15:06:28 ephemer tor[1352]: Feb 08 15:06:28.653 [err] Reading config failed--see warnings above.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit tor@default.service has failed
-- Unit tor@default.service has failed.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Unit entered failed state.
Feb 08 15:06:28 ephemer systemd[1]: tor@default.service: Failed with result 'exit-code'.
```Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25174Update to February GeoIP2 database2020-06-27T13:54:12ZKarsten LoesingUpdate to February GeoIP2 database[My geoip-2018-02-07 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-02-07) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other re...[My geoip-2018-02-07 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2018-02-07) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25173No Control Socket when DisableNetwork and User options are set2022-09-01T21:29:26ZiryNo Control Socket when DisableNetwork and User options are setTo successfully reproduce this, we need:
0. set DisableNetwork to 1
1. use User option as part of the Tor configuration
2. run sudo Tor from a different user in a different group
Here are the specific steps to reproduce it. I tested it...To successfully reproduce this, we need:
0. set DisableNetwork to 1
1. use User option as part of the Tor configuration
2. run sudo Tor from a different user in a different group
Here are the specific steps to reproduce it. I tested it on Debian
Stretch but it should be distribution independent:
```
user at host:~$ cat /home/user/my.torrc
DataDirectory /tmp/tor
ControlSocket /tmp/tor/control.sock
ControlSocketsGroupWritable 1
CookieAuthentication 1
CookieAuthFileGroupReadable 1
CookieAuthFile /tmp/tor/control.authcookie
SocksPort unix:/tmp/tor/socks.sock
```
```
user at host:~$ sudo /usr/bin/install -Z \
-m 02755 -o debian-tor \
-g debian-tor -d /tmp/tor
```
```
user at host:~$ ls -ld /tmp/tor/; ls -l /tmp/tor/
drwxr-s--- 2 debian-tor debian-tor 40 Feb 3 18:19 /tmp/tor/
total 0
```
```
user at host:~$ sudo /usr/bin/tor \
-f /home/user/my.torrc \
--User debian-tor \
--DisableNetwork 1
```
There should be control.sock, but not:
```
user at host:~$ ls -ld /tmp/tor/; sudo ls -l /tmp/tor/
drwx--S--- 2 debian-tor debian-tor 100 Feb 3 20:00 /tmp/tor/
total 8
-rw-r----- 1 debian-tor debian-tor 32 Feb 3 20:00 control.authcookie
-rw------- 1 debian-tor debian-tor 0 Feb 3 20:00 lock
-rw------- 1 debian-tor debian-tor 215 Feb 3 20:00 state
```
To let Tor really open the control.sock, we need to reload Tor (yes,
even though we just start it):
```
user at host:~$ ps -A | grep tor
863 ? 00:00:00 xenstore-watch
927 ? 00:00:04 tor-controlport
11851 pts/0 00:00:00 tor
```
```
user at host:~$ sudo /bin/kill -HUP 11851
```
```
user at host:~$ ls -ld /tmp/tor/; sudo ls -l /tmp/tor/
drwx--S--- 2 debian-tor debian-tor 120 Feb 3 20:01 /tmp/tor/
total 8
-rw-r----- 1 debian-tor debian-tor 32 Feb 3 20:01 control.authcookie
srw-rw---- 1 debian-tor debian-tor 0 Feb 3 20:01 control.sock
-rw------- 1 debian-tor debian-tor 0 Feb 3 20:01 lock
-rw------- 1 debian-tor debian-tor 215 Feb 3 20:01 state
```
I guess the reason Yawning was not able to reproduce it is because User
option was not set:
```
user at host:~$ sudo -u debian-tor \
/usr/bin/tor -f /home/user/my.torrc \
--DisableNetwork 1
[notice] Opening Control listener on /tmp/tor/control.sock
```
I was thinking Tor fixing /tmp/tor/ to 2700 may be the reason, but then
I cannot explain why this will work with /tmp/tor/ set to 2700:
```
user at host:~$ sudo /usr/bin/tor \
-f /home/user/my.torrc \
--User debian-tor \
--DisableNetwork 0
[notice] Opening Control listener on /tmp/tor/control.sock
```https://gitlab.torproject.org/tpo/core/tor/-/issues/25171Clarify 'recognized' field in tor-spec2021-07-22T16:21:37ZDamian JohnsonClarify 'recognized' field in tor-specOur tor-spec left me pretty mystified what the 'recognized' field actually was. It discussed what to do when it was zero, but not what the field *was* or what non-zero meant. Thankfully Roger filled me in over tasty, tasty pizza.
Patch ...Our tor-spec left me pretty mystified what the 'recognized' field actually was. It discussed what to do when it was zero, but not what the field *was* or what non-zero meant. Thankfully Roger filled me in over tasty, tasty pizza.
Patch available in the 'recognized' branch of my repo...
https://gitweb.torproject.org/user/atagar/torspec.git/commit/?h=recognizedTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25170explicitly mention email address to contact for rejected relays2020-11-04T14:18:57Zcypherpunksexplicitly mention email address to contact for rejected relaysfrom the discussion on bad-relays@..
When we reject relays the operator gets to see something like this in their logs:
```
[warn] http status 400 ("Fingerprint is marked rejected -- please contact us?") response from dirserver 'IP:Port...from the discussion on bad-relays@..
When we reject relays the operator gets to see something like this in their logs:
```
[warn] http status 400 ("Fingerprint is marked rejected -- please contact us?") response from dirserver 'IP:Port'. Please correct.
```
Lets change this to:
"Fingerprint is marked rejected, if you think this is a mistake please set a ContactInfo and send an email to bad-relays@lists.torproject.org mentioning your fingerprint(s)"Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25163rephist: Remove unused counters in or_history_t2020-06-27T13:54:12ZDavid Gouletdgoulet@torproject.orgrephist: Remove unused counters in or_history_tThe rephist subsystem seems to track EXTEND cells attempt (on the client side) but the overall results of this is not used except in `rep_hist_dump_stats()`. This is the only use of `link_history_t` also afaict. See:
```
void rep_hist_n...The rephist subsystem seems to track EXTEND cells attempt (on the client side) but the overall results of this is not used except in `rep_hist_dump_stats()`. This is the only use of `link_history_t` also afaict. See:
```
void rep_hist_note_extend_succeeded(const char *from_name,
const char *to_name);
void rep_hist_note_extend_failed(const char *from_name, const char *to_name);
```
Furthermore, tor tracks downtime and uptime of relays but actually never use that information anywhere. See:
```
void rep_hist_note_connect_failed(const char* nickname, time_t when);
void rep_hist_note_connect_succeeded(const char* nickname, time_t when);
void rep_hist_note_disconnect(const char* nickname, time_t when);
void rep_hist_note_connection_died(const char* nickname, time_t when);
```
The side effect of this is that we keep adding objects to the `history_map` that are wasting memory and never used in the end except when we dump statistics.
By removing this, we would cleanup quite a bit of code and effectively make the `or_history_t` object *ONLY* useful to directory authorities for relay reachability tracking.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25162Perhaps, use zstd's "static-only" functions2020-06-27T13:54:13ZNick MathewsonPerhaps, use zstd's "static-only" functionsI think maybe we can make this safe if we explicitly check that the compile version matches the runtime version. (Thanks to Hello71 for the tip)I think maybe we can make this safe if we explicitly check that the compile version matches the runtime version. (Thanks to Hello71 for the tip)Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25156Create unit tests for that check static strings match between Rust and C2021-09-16T14:31:19ZteorCreate unit tests for that check static strings match between Rust and CIn the protover crate, we list all supported protocol versions.
And then we do it again in C.
This makes it likely that they will get out of sync.
Also, passing static strings from Rust to C is error-prone (legacy/trac#25127).
Let's pu...In the protover crate, we list all supported protocol versions.
And then we do it again in C.
This makes it likely that they will get out of sync.
Also, passing static strings from Rust to C is error-prone (legacy/trac#25127).
Let's put all the static strings in C, and access them from Rust.
Yes, that might mean we pass them from C to Rust and back to C again. Oh well.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25153Specify how PrivCount in Tor statistics are configured and interpreted2020-07-28T18:31:45ZteorSpecify how PrivCount in Tor statistics are configured and interpretedIn ~~prop#280~~ prop#288, we specified the counters, noise, and secure aggregation for PrivCount in Tor.
Now we need to specify:
* how long each collection round goes for
* how we determine which counters are collected
* how we configur...In ~~prop#280~~ prop#288, we specified the counters, noise, and secure aggregation for PrivCount in Tor.
Now we need to specify:
* how long each collection round goes for
* how we determine which counters are collected
* how we configure the amount of noise for each counter
* how Metrics can interpret the final results
We should also try to answer the unanswered questions in prop280.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25152Try to call less circuitmux_find_map_entry()2022-06-17T16:02:47ZDavid Gouletdgoulet@torproject.orgTry to call less circuitmux_find_map_entry()The `circuitmux_find_map_entry()` function is currently taking more than 3% of the CPU on a busy relay. It is literally the second highest after curv25519 crypto stuff (which is expected to be high).
We can't really optimize that functi...The `circuitmux_find_map_entry()` function is currently taking more than 3% of the CPU on a busy relay. It is literally the second highest after curv25519 crypto stuff (which is expected to be high).
We can't really optimize that function so much but we can try to call it less! For instance, at every single cell we append to a circuit in `append_cell_to_circuit_queue()` we call `update_circuit_on_cmux()` which calls *4* functions in succession that calls `circuitmux_find_map_entry()`:
* `circuitmux_is_circuit_attached()`
* `circuitmux_attached_circuit_direction()`
* `circuitmux_set_num_cells()` and this function can call it again with `circuitmux_make_circuit_inactive()` or `circuitmux_make_circuit_active()`.
This is quite a lot of CPU at _each_ cell especially when we do have many many circuits.https://gitlab.torproject.org/tpo/core/tor/-/issues/25150Avoid malloc/free on each server-side ntor handshake2020-06-27T13:54:13ZNick MathewsonAvoid malloc/free on each server-side ntor handshakeNow that we require c99, we can use variable-length array here instead of a malloc/free pair.Now that we require c99, we can use variable-length array here instead of a malloc/free pair.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25149Hook rephist subsystem into the OOM handler2022-06-17T17:52:06ZDavid Gouletdgoulet@torproject.orgHook rephist subsystem into the OOM handlerIt appears we do not look at the `rephist` subsystem in the OOM handler.
But, we do track memory allocation with `rephist_total_alloc` counter. That counter needs to be audited because I found two places where we allocate memory for sta...It appears we do not look at the `rephist` subsystem in the OOM handler.
But, we do track memory allocation with `rephist_total_alloc` counter. That counter needs to be audited because I found two places where we allocate memory for stats but do not increment that global counter.
Bug legacy/trac#25141 could have been avoided in some ways with this or at least made obvious to the operator without tor crashing.https://gitlab.torproject.org/tpo/core/tor/-/issues/25148Make geoip_client_cache_total_allocation() use geoip_client_history_cache_size2020-06-27T13:54:13ZDavid Gouletdgoulet@torproject.orgMake geoip_client_cache_total_allocation() use geoip_client_history_cache_sizeIn commit `4d812e29b9b1ec88`, we forgot to make the function returning the total allocation return the counter instead of going over all entries which hugs the CPU like crazy.In commit `4d812e29b9b1ec88`, we forgot to make the function returning the total allocation return the counter instead of going over all entries which hugs the CPU like crazy.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25141enabling CellStatistics results in gigabytes of incremental memory consumption2022-10-11T23:40:04Zstarlightenabling CellStatistics results in gigabytes of incremental memory consumptionThis was causing my relay to crash every two days till I figured it out. At a minimum Tor should warn about memory consumption when this option is enabled. IMO the present behavior is broken and the feature should be redesigned or elim...This was causing my relay to crash every two days till I figured it out. At a minimum Tor should warn about memory consumption when this option is enabled. IMO the present behavior is broken and the feature should be redesigned or eliminated.https://gitlab.torproject.org/tpo/core/tor/-/issues/25140Parse only .torrc files in torrc.d directory2020-09-28T23:43:31ZiryParse only .torrc files in torrc.d directoryCurrently, when using a torrc.d directory, for example:
```
%include /etc/torrc.d/
```
Every file in the directory will be treated and parsed as a valid Tor
configuration file. However, sometime, this may not be what users and
develop...Currently, when using a torrc.d directory, for example:
```
%include /etc/torrc.d/
```
Every file in the directory will be treated and parsed as a valid Tor
configuration file. However, sometime, this may not be what users and
developers want.
For example, users may use /etc/torrc.d/50_user.torrc as the place to
put their own torrc configurations. But sometimes, when they use a
text editor to edit it, the text editor will leave a
/etc/torrc.d/50_user.torrc~ file which will also be treated as a valid
torrc file.
Another example that also happens very frequently is, when dpkg does
an update on /etc/torrc.d/30_distribution.torrc, users' previous
configuration can be saved as
/etc/torrc.d/30_distribution.torrc.dpkg-old which will also be parsed
by Tor.
In best case users will just be frustrated because Tor does not work
as expected and in worst case this could be dangerous. This could be a
severe problem especially because of the following reasons:
1. filename.torrc~ filename.torrc.dpkg-old has higher priority than
filename.torrc when Tor does the parsing.
2. In most cases, this will happen without being noticed by the normal
suer.
teor suggested on the tor-dev@:
> To be more precise, most tools accept files ending in ".conf".
> We might want tor to accept ".conf" for consistency.
> I suggest we also accept files called "torrc", or ending in ".torrc".
> This should probably also include files called literally ".torrc".
Downstream discussion to link everything together: http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/torrc-d-is-comming/4041/20Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.org