Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2024-01-24T19:18:02Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40904--disable-module-dirauth has no effect2024-01-24T19:18:02ZJulien Voisin--disable-module-dirauth has no effectI've [been trying](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/58264) to disable dirauth support in Alpine's tor package, but it seems that `--disable-module-dirauth` isn't working, as the size of the binary [didn't cha...I've [been trying](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/58264) to disable dirauth support in Alpine's tor package, but it seems that `--disable-module-dirauth` isn't working, as the size of the binary [didn't change](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/58264#note_367134) when the flag was added.
Am I doing something wrong? Note that the tests still mention dirauth-related things, so maybe asking the build system to build and run the testsuite makes it ignore `--disable-module-dirauth`?https://gitlab.torproject.org/tpo/core/tor/-/issues/40838Add config to prefer IPV6 Address than IPV42024-02-12T20:35:15ZredbearAdd config to prefer IPV6 Address than IPV4Since IPV4 address is limited in numbers and there is a migration to IPV6 could be nice you remove limitation while config IPV44Only and IPV6Only; IPV6ONly seems not working since we got a message about free ipv4 :) ... no exact denied u...Since IPV4 address is limited in numbers and there is a migration to IPV6 could be nice you remove limitation while config IPV44Only and IPV6Only; IPV6ONly seems not working since we got a message about free ipv4 :) ... no exact denied use of IPV4 .. but make sure others use IPV6 to reach IPV4 since behind NAT.https://gitlab.torproject.org/tpo/core/tor/-/issues/40814log line doubled2023-06-26T15:57:57Ztoralflog line doubledI configured 2 obfs4 bridges here for latest Tor (git HEAD) - and do wonder why only 1 is mentioned during bootstrap, but this twice in a row:
```
Jun 21 19:15:07.000 [notice] Tor 0.4.8.1-alpha-dev (git-633355a88e9c1f5b) opening log file...I configured 2 obfs4 bridges here for latest Tor (git HEAD) - and do wonder why only 1 is mentioned during bootstrap, but this twice in a row:
```
Jun 21 19:15:07.000 [notice] Tor 0.4.8.1-alpha-dev (git-633355a88e9c1f5b) opening log file.
Jun 21 19:15:07.820 [notice] We compiled with OpenSSL 1010115f: OpenSSL 1.1.1u 30 May 2023 and we are running with OpenSSL 1010115f: 1.1.1u. These two versions should be binary compatible.
Jun 21 19:15:07.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Jun 21 19:15:07.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Jun 21 19:15:07.000 [notice] Bootstrapped 0% (starting): Starting
Jun 21 19:15:08.000 [notice] Starting with guard context "bridges"
Jun 21 19:15:08.000 [notice] Delaying directory fetches: No running bridges
Jun 21 19:15:08.000 [notice] Bridge 'toralf4mauz' has both an IPv4 and an IPv6 address. Will prefer using its IPv4 address (<snip>) based on the configured Bridge address.
Jun 21 19:15:08.000 [notice] new bridge descriptor 'toralf4mauz' (cached): <snip>
Jun 21 19:15:09.000 [notice] Bridge 'toralf4mauz' has both an IPv4 and an IPv6 address. Will prefer using its IPv4 address <snip> based on the configured Bridge address.
Jun 21 19:15:09.000 [notice] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40786allow host names in `HiddenServicePort` option2023-07-07T13:07:28ZAndreasallow host names in `HiddenServicePort` option### Summary
In the `HiddenServicePort` configuration option, allow (simple) host names to be used in place of IP addresses.
In my case, I'm using Tor in a Docker container with orchestration by docker-compose. The actual services I wan...### Summary
In the `HiddenServicePort` configuration option, allow (simple) host names to be used in place of IP addresses.
In my case, I'm using Tor in a Docker container with orchestration by docker-compose. The actual services I want to "hide" are all in separate containers. In such a setup, IP addresses are not stable – they are assigned on start of docker-compose, and depend on many factors. Which is why it's recommended to use host names to refer to other containers, rather than IPs. However `tor` doesn't seem to resolve host names in this case.
I guess other usecases would benefit too, like home networks with DHCP-assigned addresses.
(If you want to prevent DNS lookups for privacy reasons, perhaps limit this to simple host names, without dots.)
### What is the expected behavior?
Something like `HiddenServicePort "443 otherhost:443"` to work.https://gitlab.torproject.org/tpo/core/tor/-/issues/40776Unable to find IPv4 address for ORPort2023-04-12T14:48:03ZmfilipeUnable to find IPv4 address for ORPort### Summary
Using a Tor Relay behind a NAT with dynamic IP address, the relay isn't able to get the IP.
The network only accepts IPv4.
### Steps to reproduce:
1. Configure router to NAT 9001 into Tor Relay;
2. Define `ORPort 9001 I...### Summary
Using a Tor Relay behind a NAT with dynamic IP address, the relay isn't able to get the IP.
The network only accepts IPv4.
### Steps to reproduce:
1. Configure router to NAT 9001 into Tor Relay;
2. Define `ORPort 9001 IPv4Only` in `torrc`;
3. Run the relay and wait until `journald` receives `Unable to find IPv4 address for ORPort`.
### What is the current bug behavior?
The relay isn't able to identify which public IPv4 it should use, so it isn't joining into the consensus and receiving flags. It is being ignored by the Tor network.
### What is the expected behavior?
Identify its IPv4 and be part of the Tor network contributing with bandwidth.
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
0.4.7.13
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.
Ubuntu 22.04.2 LTS @ Raspberry Pi 3 Model B Plus.
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
Apt packages from https://deb.torproject.org
### Relevant logs and/or screenshots
[torrc](/uploads/e8fb1069bf46a8bba85f320e69123915/torrc)
debug.log
```
Mar 25 17:10:42.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download.
Mar 25 17:10:42.000 [debug] compute_weighted_bandwidths(): Generated weighted bandwidths for rule weight as directory based on weights Wg=0.412700 Wm=1.000000 We=0.000000
Wd=0.000000 with total bw 35527529420.000000
Mar 25 17:10:42.000 [debug] directory_initiate_request(): anonymized 0, use_begindir 1.
Mar 25 17:10:42.000 [debug] directory_initiate_request(): Initiating consensus network-status fetch
Mar 25 17:10:42.000 [info] connection_ap_make_link(): Making internal direct tunnel to [scrubbed]:9001 ...
Mar 25 17:10:42.000 [debug] connection_add_impl(): new conn type Socks, socket -1, address (Tor_internal), n_conns 143.
Mar 25 17:10:42.000 [info] connection_ap_make_link(): ... application connection created and linked.
Mar 25 17:10:42.000 [debug] connection_add_impl(): new conn type Directory, socket -1, address 185.21.216.197, n_conns 144.
Mar 25 17:10:42.000 [info] directory_send_command(): Downloading consensus from 185.21.216.197:9001 using /tor/status-vote/current/consensus-microdesc/0232AF+14C131+23D15
D+27102B+49015F+E8A9C4+ED03BB+F533C8.z
Mar 25 17:10:42.000 [debug] directory_send_command(): Sent request to directory server 185.21.216.197:9001 (purpose: 14, request size: 350, payload size: 0)
Mar 25 17:10:42.000 [info] update_consensus_router_descriptor_downloads(): 0 router descriptors downloadable. 0 delayed; 6527 present (0 of those were in old_routers); 0
would_reject; 0 wouldnt_use; 0 in progress.
Mar 25 17:10:42.000 [debug] tor_rename(): Renaming /var/lib/tor/state.tmp to /var/lib/tor/state
Mar 25 17:10:42.000 [info] or_state_save(): Saved state to "/var/lib/tor/state"
Mar 25 17:10:42.000 [debug] prune_old_routers_callback(): Pruning routerlist...
Mar 25 17:10:42.000 [info] routerlist_remove_old_routers(): We have 6527 live routers and 13007 old router descriptors.
Mar 25 17:10:42.000 [debug] consdiffmgr_cleanup(): Looking for consdiffmgr entries to remove
Mar 25 17:10:42.000 [info] channel_check_for_duplicates(): Performed connection pruning. Found 3 connections to 33 relays. Found 3 current canonical connections, in 3 of
which we were a non-canonical peer. 0 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
Mar 25 17:10:42.000 [info] router_rebuild_descriptor(): Rebuilding relay descriptor
Mar 25 17:10:42.000 [debug] get_address_from_config(): Attempting to get address from configuration
Mar 25 17:10:42.000 [info] get_address_from_config(): No Address option found in configuration.
Mar 25 17:10:42.000 [debug] get_address_from_orport(): Attempting to get address from ORPort
Mar 25 17:10:42.000 [info] address_can_be_used(): Address '0.0.0.0' is a private IP address. Tor relays that use the default DirAuthorities must have public IP addresses.
Mar 25 17:10:42.000 [debug] get_address_from_interface(): Attempting to get address from network interface
Mar 25 17:10:42.000 [debug] get_interface_address6(): Found internal interface address '192.168.13.3'
Mar 25 17:10:42.000 [info] address_can_be_used(): Address '192.168.13.3' is a private IP address. Tor relays that use the default DirAuthorities must have public IP addre
sses.
Mar 25 17:10:42.000 [debug] get_address_from_hostname(): Attempting to get address from local hostname
Mar 25 17:10:42.000 [info] address_can_be_used(): Address '127.0.1.1' is a private IP address. Tor relays that use the default DirAuthorities must have public IP addresse
s.
Mar 25 17:10:42.000 [info] find_my_address(): Unable to find our IP address.
Mar 25 17:10:42.000 [notice] Unable to find IPv4 address for ORPort 9001. You might want to specify IPv6Only to it or set an explicit address or set Address.
Mar 25 17:10:42.000 [info] router_build_fresh_unsigned_routerinfo(): Don't know my address while generating descriptor. Launching circuit to authority to learn it.
Mar 25 17:10:42.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/relay/relay_find_addr.c:225: relay_addr_learn_from_dirauth: Non-fatal assertion !(!ei) failed. (on Tor
0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: Tor 0.4.7.13: Non-fatal assertion !(!ei) failed in relay_addr_learn_from_dirauth at ../src/feature/relay/relay_find_addr.c:225. Stack trac
e: (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x6c) [0xaaaad427e72c] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x164) [0xaaaad4296bb4] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(relay_addr_learn_from_dirauth+0x1f0) [0xaaaad43d6964] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(+0x27d78c) [0xaaaad440d78c] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(router_build_fresh_descriptor+0x44) [0xaaaad423a0f4] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(router_rebuild_descriptor+0x94) [0xaaaad423a604] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(consider_publishable_server+0x44) [0xaaaad423aa84] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(+0x245b6c) [0xaaaad43d5b6c] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(+0x8832c) [0xaaaad421832c] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /lib/aarch64-linux-gnu/libevent-2.1.so.7(+0x1fd04) [0xffff95dbfd04] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /lib/aarch64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x444) [0xffff95dc1868] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(do_main_loop+0xfc) [0xaaaad41fb51c] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1e0) [0xaaaad41ff4a0] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(tor_main+0x54) [0xaaaad41ff8e4] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(main+0x20) [0xaaaad41f2320] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /lib/aarch64-linux-gnu/libc.so.6(+0x273fc) [0xffff955573fc] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98) [0xffff955574cc] (on Tor 0.4.7.13 )
Mar 25 17:10:42.000 [warn] Bug: /usr/bin/tor(_start+0x30) [0xaaaad41f23b0] (on Tor 0.4.7.13 )
```
### Possible fixes
Set `Address` with a host that points to my dynamic IP address but as far as I know when the relay is configured with `Address` and the public IP changes, the relays isn't able to get this change.https://gitlab.torproject.org/tpo/core/tor/-/issues/40772Support range in RejectPlaintextPorts2023-04-12T14:47:49ZcypherpunksSupport range in RejectPlaintextPortsexample, `RejectPlaintextPorts 1-442,444-65535` to force tor only accept https and reject else.example, `RejectPlaintextPorts 1-442,444-65535` to force tor only accept https and reject else.https://gitlab.torproject.org/tpo/core/tor/-/issues/40765Re think about connection management and vote relays2023-04-12T14:46:31ZredbearRe think about connection management and vote relaysHello people , how are you ? :smile:
People am here here testing few things and seeing how network usage testing both tor 4.7.xx and dev with some modifications and i would like share some of observations and ask to implement some feat...Hello people , how are you ? :smile:
People am here here testing few things and seeing how network usage testing both tor 4.7.xx and dev with some modifications and i would like share some of observations and ask to implement some features could low those DDOS attacks and spam request by guards to connections.
My first phase test was test a normal version Tor without modifications and perform some usage Advertised Bandwidth and found some to sahre :
1. A guard mode using normal features frozen more times using full/low capacity ISP usage taking hours to back to normal
2. Usually those frozen is caused by malicious people DDOS attacks and excess requests
3. Those open bar configurations overload all network tor and make our contribution hard
4. Increase my energy bills and frozen your internet most of time
Those actual implementation give me also
[warn] Decrypting superencrypted desc failed.
[warn] Service descriptor decryption failed.
[warn] HSDesc parsing failed!
IP: 148.251.46.115 Port: 1
IP: 148.251.46.115 Port: 0
IP: 95.217.200.54 Port: 1
IP: 95.217.200.54 Port: 0
IP: 85.214.42.55 Port: 1
IP: 85.214.42.55 Port: 0
IP: 185.220.101.34 Port: 1
IP: 185.220.101.34 Port: 0
IP: 37.75.166.2 Port: 1
IP: 37.75.166.2 Port: 0
This is another one i took during execution tor
[notice] Application asked to connect to port 0. Refusing.
[warn] Rejecting SOCKS request for anonymous connection to private address [scrubbed].
My second phase resumes take a dev tor and let people use what my tor/guard/middle and internet permits
1. Limit ports guard can offer in way to prevent flood requests and provide to those already connected good and stable connections
2. Accept basic ports as 53,80,443,5005,8333 and reject all btw 2:8999
3. Observe how ISP act this phase test and if it wont frozen
4. Detected some 1.1.1.1:443 try uses my guard to make spam
Using this approach this test i get a better result than running openbar stuff. This suggest me most tor using lowers ports make terrible spam and have been overload who offer low Advertised Bandwidth and as consequence get Consensus Weight very low. i don't like put my hands on source code cause sometimes i don't few comfortable to code on stuff of others so i would like make some requests in order to prevent those things to happen to low quality ISP providers and give more options to people without hurt relays internet capacity.
Suggestions to change about how servers and built:
1. Make ORPort range port usage
2. Server Could restart after time and use ORPort range as parameter to define new port usage cause actual AUTO make from 0-65535 and ISP blocks some range or low ports
3. Keep DirPort static; no need change anything
4. Makes guard limitations port to prevent overload and spam requests
5. Add blacklist capacity as sockspolicy IP "i dont know if we already have it to guards too"
6. Build a open database ips used to be scam / ddos or other bad related stuff
7. Add options to Dir vote to make sure no misunderstands appear because limitations
8. AUTO detect ports could restart many times as possible to detect ports ISP let you use
I would like more to advocate and run relays and make more suggestions if possible .... but all depends if community will be more friendly and near future help people as me to build more relays or exits . For now is all i can say and suggests. Thank you.https://gitlab.torproject.org/tpo/core/tor/-/issues/40763Implement standard Prometheus metrics2023-04-12T14:46:21Zfriendly73Implement standard Prometheus metricsMost client libraries and applications export a few standard metrics that would be useful for tor to implement. Below are some examples from a Prometheus' own `/metrics` page.
Build Info - Don't need as many labels as GO provides here b...Most client libraries and applications export a few standard metrics that would be useful for tor to implement. Below are some examples from a Prometheus' own `/metrics` page.
Build Info - Don't need as many labels as GO provides here but the short version tag that appears on the relay consensus would be good.
```
# HELP prometheus_build_info A metric with a constant '1' value labeled by version, revision, branch, goversion from which prometheus was built, and the goos and goarch for the build.
# TYPE prometheus_build_info gauge
prometheus_build_info{branch="HEAD",goarch="amd64",goos="linux",goversion="go1.19.5",revision="225c61122d88b01d1f0eaaee0e05b6f3e0567ac0",version="2.42.0"} 1
```
Process start time and last config reload - Useful for dashboard annotations and alerts.
```
# HELP process_start_time_seconds Start time of the process since unix epoch in seconds.
# TYPE process_start_time_seconds gauge
process_start_time_seconds 1.67604147258e+09
# HELP prometheus_config_last_reload_success_timestamp_seconds Timestamp of the last successful configuration reload.
# TYPE prometheus_config_last_reload_success_timestamp_seconds gauge
prometheus_config_last_reload_success_timestamp_seconds 1.6761274276477513e+09
```
CPU / Memory of the current process - These might be a bit of a stretch as they could be hard to implement in a cross platform way and will require supporting float values for counters.
```
# HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.
# TYPE process_cpu_seconds_total counter
process_cpu_seconds_total 6232.69
# HELP process_virtual_memory_bytes Virtual memory size in bytes.
# TYPE process_virtual_memory_bytes gauge
process_virtual_memory_bytes 1.924509696e+09
# HELP process_virtual_memory_max_bytes Maximum amount of virtual memory available in bytes.
# TYPE process_virtual_memory_max_bytes gauge
process_virtual_memory_max_bytes 1.8446744073709552e+19
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40762add MetricsPort metrics, labels, values documentation to man page2023-04-15T19:59:07Znatadd MetricsPort metrics, labels, values documentation to man page
As mentioned during the last relay operator meetup, please document the MetricsPort prometheus metrics
their labels and values. In many cases pointer to other documentation is enough, for example in the case of tor relay flags you can p...
As mentioned during the last relay operator meetup, please document the MetricsPort prometheus metrics
their labels and values. In many cases pointer to other documentation is enough, for example in the case of tor relay flags you can point to the relevant tor specification section.
When new metrics/labels/values get introduced they should get a manpage entry with the same merge request (like requiring a changes file) to avoid this situation - metrics without documentation - from mounting up in the future again.
```
## HELP tor_relay_dos_total Denial of Service defenses related counters
## TYPE tor_relay_dos_total counter
tor_relay_dos_total
labels:
* type
* "circuit_rejected
* "circuit_killed_max_cell"
* "circuit_killed_max_cell_outq"
* "marked_address"
* "marked_address_maxq"
* "conn_rejected"
* "concurrent_conn_rejected"
* "single_hop_refused"
* "introduce2_rejected"
## HELP tor_relay_traffic_bytes Traffic related counters
## TYPE tor_relay_traffic_bytes counter
tor_relay_traffic_bytes
labels:
* direction
* "read"
* "written"
## HELP tor_relay_load_oom_bytes_total Total number of bytes the OOM has freed by subsystem
## TYPE tor_relay_load_oom_bytes_total counter
tor_relay_load_oom_bytes_total
labels:
* subsys
* "cell"
* "dns"
* "geoip"
* "hsdir"
## HELP tor_relay_load_socket_total Total number of sockets
## TYPE tor_relay_load_socket_total gauge
tor_relay_load_socket_total
labels:
* state
* "opened"
## HELP tor_relay_streams_total Total number of streams
## TYPE tor_relay_streams_total counter
tor_relay_streams_total
labels:
* type
* "BEGIN"
* "BEGIN_DIR"
* "RESOLVE"
## HELP tor_relay_circuits_total Total number of circuits
## TYPE tor_relay_circuits_total gauge
tor_relay_circuits_total
labels:
* state
* "opened"
## HELP tor_relay_load_onionskins_total Total number of onionskins handled
## TYPE tor_relay_load_onionskins_total counter
tor_relay_load_onionskins_total
labels:
* type
* "tap"
* "fast"
* "ntor"
* "ntor_v3"
* action
* "processed"
* "dropped"
## HELP tor_relay_load_global_rate_limit_reached_total Total number of global connection bucket limit reached
## TYPE tor_relay_load_global_rate_limit_reached_total counter
tor_relay_load_global_rate_limit_reached_total
labels:
* side
* "read"
* "write"
## HELP tor_relay_load_tcp_exhaustion_total Total number of times we ran out of TCP ports
## TYPE tor_relay_load_tcp_exhaustion_total counter
tor_relay_load_tcp_exhaustion_total
## HELP tor_relay_congestion_control_total Congestion control related counters
## TYPE tor_relay_congestion_control_total counter
tor_relay_congestion_control_total
labels:
* state
* "starvation"
* "clock_stalls"
* "flow_control"
* "cc_limits"
* "cc_circuits"
* action
* "rtt_reset"
* "rtt_skipped"
* "xoff_num_sent"
* "xon_num_sent"
* "above_delta"
* "above_ss_cwnd_max"
* "below_ss_inc_floor"
* "circs_created"
* "circs_exited_ss"
## HELP tor_relay_exit_dns_query_total Total number of DNS queries done by this relay
## TYPE tor_relay_exit_dns_query_total counter
tor_relay_exit_dns_query_total
## HELP tor_relay_flag Relay flags from consensus
## TYPE tor_relay_flag gauge
tor_relay_flag
labels:
* type
* "Fast"
* "Exit"
* "Authority"
* "Stable"
* "HSDir"
* "Running"
* "V2Dir"
* "Sybil"
* "Guard"
## HELP tor_relay_connections Total number of opened connections
## TYPE tor_relay_connections gauge
tor_relay_connections
labels:
* type
* "OR listener"
* "OR"
* "Exit"
* "Socks listener"
* "Socks"
* "Directory listener"
* "Directory"
* "Control listener"
* "Control"
* "Transparent pf/netfilter listener"
* "Transparent natd listener"
* "DNS listener"
* "Extended OR"
* "Extended OR listener"
* "HTTP tunnel listener"
* "Metrics listener"
* "Metrics"
* direction
* "initiated"
* "received"
* state
* "opened"
* family
* "ipv4"
* "ipv6"
## HELP tor_relay_congestion_control Congestion control related gauges
## TYPE tor_relay_congestion_control gauge
tor_relay_congestion_control
labels:
* state
* "slow_start_exit"
* "on_circ_close"
* "buffers"
* "cc_backoff"
* "cc_cwnd_update"
* "cc_estimates"
* action
* "cwnd"
* "bdp"
* "inc"
* "ss_cwnd"
* "xon_outbuf"
* "xoff_outbuf"
* "chan_blocked_pct"
* "gamma_drop"
* "delta_drop"
* "ss_chan_blocked_pct"
* "alpha_pct"
* "beta_pct"
* "delta_pct"
* "ss_queue"
* "queue"
* "bdp"
## HELP tor_relay_connections_total Total number of created/rejected connections
## TYPE tor_relay_connections_total counter
tor_relay_connections_total
same description as metric tor_relay_connections lables/values
## HELP tor_relay_exit_dns_error_total Total number of DNS errors encountered by this relay
## TYPE tor_relay_exit_dns_error_total counter
tor_relay_exit_dns_error_total
labels:
* reason
* "success"
* "format"
* "serverfailed"
* "notexist"
* "notimpl"
* "refused"
* "truncated"
* "unknown"
* "tor_timeout"
* "shutdown"
* "cancel"
* "nodata"
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40714add option for declaring the result of querying the socks proxy port via cont...2023-05-02T09:22:32ZAndreasadd option for declaring the result of querying the socks proxy port via control port### Summary
I'm using tor in a container within a docker-compose application and thus have the Socks port bound to all interfaces:
```
SocksPort 0.0.0.0:9050
SocksPort [::]:9050
```
I'm also using a control port (config not shown here...### Summary
I'm using tor in a container within a docker-compose application and thus have the Socks port bound to all interfaces:
```
SocksPort 0.0.0.0:9050
SocksPort [::]:9050
```
I'm also using a control port (config not shown here) to have hidden services managed by applications, more specifically bitcoind.
The application queries via control port for the socks proxy port and arbitrary gets the last entry from the above list as result. This is already weird, why the last entry and not the first? To make matters worse, both entries are entirely wrong from the perspective of the application container, because it resolves to local addresses. If the application then tries to connect the socky proxy, it will fail.
To work around this problem, I replaced my declarations with this one
```
SocksPort tor:9050
```
"tor" being the hostname of my tor container. This works, but now the tor proxy is only listening on its external interface and only on one of the protocol families IPv4 or IPv6 (again, not clear which). This is undesired mainly because I want the socks proxy listening on both IPv4 and IPv6, and also on all interfaces. Note I can't use numerical IP addresses here, because Docker changes them around for each fresh container.
**Feature request:**
So my feature request would be a new (optional) configuration entry to declare the result of the query for socks proxy port via control port explicitly and independant of the binding declaration. And maybe a warning message if wildcard SocksPorts are used and the new configuration option is not present. Something like
```
SocksPort 0.0.0.0:9050
SocksPort [::]:9050
SocksPortQueryResult tor:9050
```
should do. Feel free to come up with a better option name.https://gitlab.torproject.org/tpo/core/tor/-/issues/40690Scoped Bandwidth Accounting2022-11-14T17:41:18ZJeremy Sakladjeremy@saklad5.comScoped Bandwidth Accounting### Summary
Last discussed in https://gitlab.torproject.org/tpo/core/tor/-/issues/8276, I feel it would be quite useful to allow AccountingMax to both ignore and avoid impacting onion services. Running a relay and hidden onion service o...### Summary
Last discussed in https://gitlab.torproject.org/tpo/core/tor/-/issues/8276, I feel it would be quite useful to allow AccountingMax to both ignore and avoid impacting onion services. Running a relay and hidden onion service on the same node is obviously a bad idea, but that's not who this would be for.
The way I see it, Tor's functionality can be cleanly separated into two categories: anonymous and non-anonymous. It is ill-advised to mix the two. Clients and standard/hidden onion services are anonymous, while relays, directories, and single onion services are not.
To take load off exit relays, I run single onion services for pretty much every server I operate. If I have space in my traffic quota, I also configure those instances as relays. If I only have *some* space, like with a VPS, I use AccountingMax to shut off the relay and avoid overage charges. Unfortunately, this shuts off the single onion services, which were the main reason I'm even running an instance there.
I don't want to choose between donating spare bandwidth and optimizing my servers for Tor clients, and I certainly don't want the added complexity and overhead of running multiple Tor instances. **Previous discussions have indicated that this would be difficult to implement due to how Tor is coded, but I think this should be considered for Arti's shiny new codebase.**
### What is the expected behavior?
There are two ways this could be configured:
1. Add more AccountingRule options, such as "relay-out", that only apply to relay traffic
2. Add a new option, "AccountingScope", with options such as "client", "onion-service", and most importantly "relay", which further constrain "AccountingRule"
I think \#2 would be cleanest.
Once the limit is hit, Tor will hibernate only the functionality that is tracked under "AccountingScope". This obviously means that the instance would go over that budget, but anyone setting this should be fully aware of that. In theory you could add an additional option that controls whether everything is hibernated even with scoped accounting, but I can't conceive of a use case for that.https://gitlab.torproject.org/tpo/core/tor/-/issues/40689dirauth: Add new Faravahar 2.0 back to code2023-04-12T15:17:56ZDavid Gouletdgoulet@torproject.orgdirauth: Add new Faravahar 2.0 back to codeWe'll be in the next release removing the current Faravahar (https://gitlab.torproject.org/tpo/core/tor/-/issues/40688) due to its network location at team Cymru. Sina, its operator, is in the process of moving it out and securing a new ...We'll be in the next release removing the current Faravahar (https://gitlab.torproject.org/tpo/core/tor/-/issues/40688) due to its network location at team Cymru. Sina, its operator, is in the process of moving it out and securing a new location.
At this point, we'll add it back into the code with fresh new keys and IP. This ticket tracks this effort.https://gitlab.torproject.org/tpo/core/tor/-/issues/40682Directory authorities might store wrong descriptor in relay list2023-05-11T17:27:28ZGeorg KoppenDirectory authorities might store wrong descriptor in relay listThis morning we had a relay operator wondering why their healthy [guard relay](https://metrics.torproject.org/rs.html#details/2889D778367BFBE2D594E95524E3FB908B49AA02) with a consensus weight of 30000 suddenly dropped to a consensus weig...This morning we had a relay operator wondering why their healthy [guard relay](https://metrics.torproject.org/rs.html#details/2889D778367BFBE2D594E95524E3FB908B49AA02) with a consensus weight of 30000 suddenly dropped to a consensus weight of 20. In particular, as the sibling relay on the *same* machine was still behaving fine.
It turned out the relay, `nognu`, got just two measurements and made it barely in the consensus, so the consensus weight = 20 fallback kicked in. Now, why exactly did it not make into, e.g. `moria1`'s vote then? For some reason `moria1` did not get the latest two descriptors directly but from different directory authorities:
```
published 2022-10-11 17:06:38
@downloaded-at 2022-10-11 17:50:44
@source "154.35.175.225"
published 2022-10-11 18:36:51
@downloaded-at 2022-10-11 18:50:03
@source "199.58.81.140"
```
That's not too bad. However, `moria1` thought none of those was the latest descriptor, rather it was the one it fetched from `dizum`:
```
published 2022-10-10 23:06:35
@downloaded-at 2022-10-11 18:50:05
@source "45.66.33.45"
```
It seems it arrived two seconds later after `moria1` got the latest descriptor suddenly making this old descriptor the latest. And given that it already expired more than `ROUTER_MAX_AGE_TO_PUBLISH` ago *that* descriptor got discarded and now `moria1` (and it seems a bunch of other directory authorities) think that relay does not exist, i.e. they don't include it in their vote.
@arma did a bunch of debugging here. So, I'll take the liberty to just paste the IRC debug logs into this ticket, so I don't lose important details:
```
09:52 <+arma1> and then issue two is: there seems to be a bug where tor dir auths
store the wrong new descriptor in the relay list
09:53 <+arma1> they should take the new descriptor and compare published-by and
take the newest
09:53 <+arma1> though now that i think about it, i think there is some logic to
try to consense upon the most popular one
09:53 <+arma1> so if a relay publishes a new one every minute and there are
thousands of descriptors for it, the dir auths don't all vote
about a different one
09:57 <+arma1> yes, here is that logic: see dirserv_add_descriptor() in
feature/dirauth/process_descs.c,
09:57 <+arma1> /* Check whether this descriptor is semantically identical to
the last one
09:57 <+arma1> * from this server. (We do this here and not in
router_add_to_routerlist
09:57 <+arma1> * because we want to be able to accept the newest router
descriptor that
09:57 <+arma1> * another authority has, so we all converge on the same one.) */
09:59 <+arma1> we hit a race where in one voting period, we got two votes about
nognu each naming a different descriptor
10:02 <+arma1> Oct 11 14:50:03.773 [notice] longclaw posted a vote to me from
199.58.81.140.
10:02 <+arma1> Oct 11 14:50:07.099 [notice] dizum posted a vote to me from
45.66.33.45.
10:04 <+arma1> i wonder if the downloaded-at's are utc or local time
10:04 <+arma1> looks like they are utc
10:10 <+arma1> how did i receive the nognu descriptor from dizum at 18:50:03 if i
received dizum's vote at 14:50:07.099? that is weird.
10:10 <+arma1> erm, i mean 18:50:05. how did i receive it from dizum at 18:50:05
if i got the vote 2 seconds after that.
10:14 <+arma1> ok, i think i know where the bug happened,
10:14 <+arma1> in router_add_to_routerlist(),
10:14 <+arma1> if (old_router) {
10:14 <+arma1> if (!in_consensus && (router->cache_info.published_on <=
10:14 <+arma1> old_router->cache_info.published_on)) {
10:14 <+arma1> } else {
10:14 <+arma1> /* Same key, and either new, or listed in the consensus. */
10:14 <+arma1> log_debug(LD_DIR, "Replacing entry for router %s",
10:14 <+arma1> router_describe(router));
10:15 <+arma1> i bet that earlier nognu descriptor was the one listed in the
consensus at 18:00 utc on that day
10:15 <+arma1> so when i heard it from dizum, i fetched a copy, and put it as my
primary descriptor for nognu because that's what other people were
voting about at the time
10:20 <+arma1> https://gitlab.torproject.org/tpo/core/tor/-/issues/543 is the
original bug
10:20 -zwiebelbot:#tor-relays- tor:tpo/core/tor#543: 0.2.0.9-alpha servers don't
update enough dir info - https://bugs.torproject.org/tpo/core/tor/543
10:21 <+arma1> as added in commit acaa9a7f696
10:24 <+arma1> we do have code to rescue old descriptors if we see them listed in
the consensus,
10:24 <+arma1> log_info(LD_DIR, "%d router descriptors listed in consensus
are "
10:24 <+arma1> "currently in old_routers; making them current.",
10:24 <+arma1> smartlist_len(no_longer_old));
10:24 <+arma1> but we seem to have wrapped that code in if
(!authdir_mode_v3(options)
10:24 <+arma1> i.e. everybody does the rescuing except v3 dir auths
```
Tagging @nickm as I heard he might be our best bet here. :)Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40675NETINFO log line truncates canonical_addr2022-10-28T15:53:33ZpseudonymisaTorNETINFO log line truncates canonical_addrOn Tor 0.4.7.10 (recommended) Relay, the `Got good NETINFO cell loglines` appear to randomly truncate the canonical_addr ports
Examples:
```
[INFO] channel_tls_process_netinfo_cell(): Got good NETINFO cell on OR connection (open) with...On Tor 0.4.7.10 (recommended) Relay, the `Got good NETINFO cell loglines` appear to randomly truncate the canonical_addr ports
Examples:
```
[INFO] channel_tls_process_netinfo_cell(): Got good NETINFO cell on OR connection (open) with
│ 45.58.152.45:50268 ID=59KGIISLyF2YgL052AUBH29QyhJe9almx9mcIXYIooc RSA_ID=0541CE9E2DDA8C0B1D988FB640D65916B0683C35
│ canonical_addr=45.58.152.45:443; OR connection is now open, using protocol version 5. Its ID digest is
│ 0541CE9E2DDA8C0B1D988FB640D65916B0683C35. Our address is apparently
[INFO] channel_tls_process_netinfo_cell(): Got good NETINFO cell on OR connection (open) with
│ 130.162.208.178:50226 ID=cqxU2kBKfWPKwB1L04+ZuQwUybzUjSMWgG5Y21mGX5o RSA_ID=344F966AF902986227DA6C2F523D53BBD604892A
│ canonical_addr=130.162.208.178:; OR connection is now open, using protocol version 5. Its ID digest is
│ 344F966AF902986227DA6C2F523D53BBD604892A. Our address is apparently
[INFO] channel_tls_process_netinfo_cell(): Got good NETINFO cell on OR connection (open) with
│ 144.76.219.195:50302 ID=RRU6DDTnWc9azmpx7v3IhdLdPJNB4ciJ+j2Kv8lcv0Y RSA_ID=CE9003208A047960246052C604A213C3BF096F61
│ canonical_addr=144.76.219.195:9; OR connection is now open, using protocol version 5. Its ID digest is
│ CE9003208A047960246052C604A213C3BF096F61. Our address is apparently
```
just removed the relays IP myself behind `Our address is apparently`
Doesn't seem this is intended?
Notice that the shorter the IP address is, the more port digits fit into.
```
123.123.123.123:;
12.12.12.12:9001;
1.12.12.12:12345;
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40672Display nicnames on bridge cards2022-10-24T20:48:45ZcypherpunksDisplay nicnames on bridge cardsFor example, to simplify correlation of log events and cards.For example, to simplify correlation of log events and cards.https://gitlab.torproject.org/tpo/core/tor/-/issues/40671tor-0.4.7.10 tag missing 0.4.7.9 and 0.4.7.10 changelogs; anything to fix in ...2022-10-24T20:48:41ZRoger Dingledinetor-0.4.7.10 tag missing 0.4.7.9 and 0.4.7.10 changelogs; anything to fix in release checklist?The tor-0.4.7.10 git tag has a ChangeLog and ReleaseNotes that end at 0.4.7.8. That is, the tagged version doesn't have the last two changelog stanzas in it.
Whereas the tor-0.4.7.9 git tag *does* have the 0.4.7.9 changelog stanzas in i...The tor-0.4.7.10 git tag has a ChangeLog and ReleaseNotes that end at 0.4.7.8. That is, the tagged version doesn't have the last two changelog stanzas in it.
Whereas the tor-0.4.7.9 git tag *does* have the 0.4.7.9 changelog stanzas in it. This is confusing to me.
The 0.4.7.10 tarball has the right changelog stanzas in it, which I guess means the tarball isn't built from the tag, which is also a problem.
I guess it is too late for these particular releases, but it gives us the opportunity to check: is there anything in the release checklist that we can improve to reduce the chances of a repeat issue?
Thanks!https://gitlab.torproject.org/tpo/core/tor/-/issues/40670vanguards is not picking new Guard when the Guard is very unstable.2022-10-24T20:48:35Zcypherpunksvanguards is not picking new Guard when the Guard is very unstable.vanguards are yelling "The connection to guard [REDACTED] was closed with a live circuit" for about a week yet vanguards is not changing this guard to more better one.
Isn't this dangerous? Adversary could notice this tor service is dis...vanguards are yelling "The connection to guard [REDACTED] was closed with a live circuit" for about a week yet vanguards is not changing this guard to more better one.
Isn't this dangerous? Adversary could notice this tor service is disconnecting a lot which is not true cause the internet is always online.
```
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
WARNING: Possible Tor bug, or possible attack if very frequent: Got 1 dropped cell on circ X (in state HS_SERVICE_REND HSSR_JOINED; old state HS_SERVICE_REND HSSR_CONNECTING)
NOTICE: We force-closed circuit X
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
WARNING: Possible Tor bug, or possible attack if very frequent: Got 1 dropped cell on circ X (in state HS_SERVICE_REND HSSR_JOINED; old state HS_SERVICE_REND HSSR_CONNECTING)
NOTICE: We force-closed circuit X
WARNING: Possible Tor bug, or possible attack if very frequent: Got 2 dropped cell on circ X (in state HS_SERVICE_REND HSSR_JOINED; old state HS_SERVICE_REND HSSR_CONNECTING)
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [The Second Guard] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
NOTICE: Circ X exceeded CIRC_MAX_MEGABYTES: 2151034 > X.
NOTICE: We force-closed circuit X
NOTICE: The connection to guard [Guard Node ONE] was closed with a live circuit.
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40668bash-completion for tor2022-10-24T20:48:34Znyxnorbash-completion for torMade a bash-completion script for tor.
Miscellaneous addition.
It does not need to be in `core/tor`, I would just like some review from upstream (TPO) before trying to merge to the official repo on https://github.com/scop/bash-completio...Made a bash-completion script for tor.
Miscellaneous addition.
It does not need to be in `core/tor`, I would just like some review from upstream (TPO) before trying to merge to the official repo on https://github.com/scop/bash-completion/blob/master/completions/
It has all options, but it doesn't generate all arguments because that is too much work.
You can check the up to date version here https://github.com/nyxnor/tor-bash-completion/blob/main/tor
But if you just want to get a look at it.
```bash
# tor(1) completion -*- shell-script -*-
_comp_xfunc_tor_torrcopt()
{
_tor_torrc_opt="$(tor --list-torrc-options | sed "s|^|--|")"
COMPREPLY=($(compgen -W "${_tor_torrc_opt}" -- "$cur"))
}
_tor()
{
local cur prev words cword
_init_completion -s || return
case $prev in
## tor cli
--allow-missing-torrc | --ignore-missing-torrc | --verify-config | \
--list-torrc-options | --list-deprecated-options | \
--list-modules | --help | --version | --quiet | --hush )
return
;;
--hash-password )
## requires argument but not possible to complete
return
;;
--defaults-torrc | --torrc-file )
_filedir
return
;;
--dump-config )
COMPREPLY=($(compgen -W "short full" -- "$cur"))
return
;;
--list-fingerprint )
COMPREPLY=($(compgen -W "rsa ed25519" -- "$cur"))
return
;;
--keygen )
COMPREPLY=($(compgen -W "--newpass" -- "$cur"))
return
;;
--key-expiration )
COMPREPLY=($(compgen -W "sign" -- "$cur"))
return
;;
--format )
## depends on --key-expiration
COMPREPLY=($(compgen -W "iso8601 timestamp" -- "$cur"))
return
;;
--passphrase-fd )
COMPREPLY=($(compgen -W "$(ls /proc/$$/fd)" -- "$cur"))
return
;;
## torrc options
--AccelDir | --CacheDirectory | --DataDirectory | \
--ClientOnionAuthDir | --KeyDirectory | --HiddenServiceDir )
_filedir -d
return
;;
--ControlPortWriteToFile | --ControlSocket | --CookieAuthFile | \
--ExtORPortCookieAuthFile | --PidFile | --GeoIPFile | \
--GeoIPv6File | --ServerDNSResolvConfFile | \
--DirPortFrontPage | --GuardfractionFile | --V3BandwidthsFile )
_filedir
return
;;
--AvoidDiskWrites | --ConstrainedSockets | \
--ControlPortFileGroupReadable | --ControlSocketGroupWritable | \
--CookieAuthentication | --CookieAuhtfileGroupReadable | \
--CountPrivateBandwidth | --DataDirectoryGroupReadable | \
--DisableAllSwap | --DisableDebuggerAttachement | --DisableNetwork | \
--ExtORPortCookieAuthFileGroupReadable | --FetchDirInfoEarly | \
--FetchDirInfoExtraEarly | --FetchHidServDescriptors | \
--FetchServerDescriptors | --FetchUselessDescriptors | \
--HardwareAccel | --LogMessageDomains | --NoExec | \
--ProtocolWarnings | --RunAsDaemon | --SandBox | \
--TrunateLogFile| --UnixSocksGroupWritable | \
--UseDefaultFallbackDirs | --AllowNonRFC953Hostnames | \
--AutomapHostsOnResolve | --CircuitPadding | \
--ReducedCircuitPadding | --ClientDNSRejectInternalAddresses | \
--ClientOnly | --ClientRejectInternalAddresses | \
--ClientUseIPv4 | --ClientUseIPv6 | --ReducedConnectionPadding | \
--DownloadExtraInfo | --EnforceDistinctSubnets | \
--FascistFirewall | --SafeSocks | --TestSocks | \
--UpdateBridgesFromAuthority | --UseBridges | --UseEntryGuards | \
--LearnCircuitBuildTimeout | --DormantCanceledByStartup | \
--DormantOnFirstStartup | --DormantTimeoutDisabledByIdleStreams | \
--DormantTimeoutEnabled | --StrictNodes | --AddressDisableIPv6 | \
--AssumeReachable | --BridgeRelay | --DisableOOSCheck | \
--ExitPolicyRejectLocalInterfaces | --ExitPolicyRejectPrivate | \
--ExtendAllowPrivateAddresses | --IPv6Exit | --MainloopStats | \
--OfflineMasterKey | --ReducedExitPolicy | \
--ServerDNSAllowBrokenConfig | \
--ServerDNSAllowNonRFC953Hostnames | --ServerDNSDetectHijacking | \
--ServerDNSRandomizeCase | --ServerDNSSearchDomains | \
--BridgeRecordUsageByCountry | --CellStatistics | \
--ConnDirectionStatistics | --DirReqStatistics | \
--EntryStatistics | --ExitPortStatistics | --ExtraInfoStatistics | \
--HiddenServiceStatistics | --OverloadStatistics | \
--PaddingStatistics | --DirCache | \
--HiddenServiceEnableIntroDoSDefense | \
--AuthoritativeDirectory | --BridgeAuthoritativeDir | \
--V3AuthoritativeDirectory | --AuthDirHasIPv6Connectivity | \
--AuthDirListBadExits | --AuthDirListMiddleOnly | \
--AuthDirPinKeys | --AuthDirRejectRequestsUnderLoad | \
--AuthDirSharedRandomness | --AuthDirTestEd25519LinkKeys | \
--AuthDirTestReachability | --DirAllowPrivateAddresses | \
--V3AuthUseLegacyKey | --VersioningAuthoritativeDirectory | \
--HiddenServiceAllowUnknownPorts | \
--HiddenServiceDirGroupReadable | \
--HiddenServiceOnionBalanceInstance | \
--HiddenServiceMaxStreamsCloseCircuit | \
--HiddenServiceSingleHopMode | \
--HiddenServiceNonAnonymousMode | \
--PublishHidServDescriptors | \
--TestingTorNetwork | \
--TestingDirAuthVoteExitIsStrict | \
--TestingDirAuthVoteGuardIsStrict | \
--TestingDirAuthVoteHSDirIsStrict | \
--TestingEnableCellStatsEvent | \
--TestingEnableConnBwEvent )
COMPREPLY=($(compgen -W "0 1" -- "$cur"))
return
;;
--CacheDirectoryGroupReadable | --ExtendByEd25519ID | \
--KeepBindCapabilities | --ClientPreferIPv6DirPort | \
--ClientPreferIPv6ORPort | --ConnectionPadding | \
--UseGuardFraction | --VanguardsLiteEnabled | \
--UseMicroDescriptors | --GeoIPExcludeUnknown | \
--AssumeReachableIPv6 | --ExitRelay | \
--KeyDirectoryGroupReadable | --RefuseUnknownExits | \
--DoSCircuitCreationEnabled | --DoSConnectionEnabled | \
--DoSRefuseSingleHopClientRendezvous )
COMPREPLY=($(compgen -W "0 1 auto" -- "$cur"))
return
;;
--SafeLogging )
COMPREPLY=($(compgen -W "0 1 relay" -- "$cur"))
return
;;
--TransProxyType )
COMPREPLY=($(compgen -W "default TPROXY ipfw pf-divert" -- "$cur"))
return
;;
--AccountingRule )
COMPREPLY=($(compgen -W "sum max in out" -- "$cur"))
return
;;
--PublishServerDescriptor )
COMPREPLY=($(compgen -W "0 1 v3 bridge" -- "$cur"))
return
;;
--HiddenServiceExportCircuitID )
COMPREPLY=($(compgen -W "haproxy" -- "$cur"))
return
;;
--HiddenServiceVersion )
COMPREPLY=($(compgen -W "3" -- "$cur"))
return
;;
esac
if [[ $cur == -* ]]; then
_comp_xfunc_tor_torrcopt
COMPREPLY=($(compgen -W "--help --torrc-file --allow-missing-torrc
--defaults-torrc --ignore-missing-torrc --hash-password
--list-fingerprint --verify-config --dump-config
--list-torrc-options --list-deprecated-options --list-modules
--version --quiet --hush --keygen --newpass --passphrase-fd
--key-expiration --format ${_tor_torrc_opt}" -- "$cur"))
return
fi
} &&
complete -F _tor tor
# ex: filetype=sh
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40667pathbias_count_use_success() logs unhashed fingerprint twice2023-10-12T16:44:33Ztoralfpathbias_count_use_success() logs unhashed fingerprint twiceIn the notice log of a Tor client connected to the public bridge *toralf4elster* I got:
```
Aug 27 14:41:54.000 [notice] pathbias_count_use_success(): Bug: Unexpectedly high use successes counts (23.000000/1.000000) for guard $<snip> ($<...In the notice log of a Tor client connected to the public bridge *toralf4elster* I got:
```
Aug 27 14:41:54.000 [notice] pathbias_count_use_success(): Bug: Unexpectedly high use successes counts (23.000000/1.000000) for guard $<snip> ($<snip>) (on Tor 0.4.8.0-alpha-dev 982c50401c5e9bde)
...
Aug 27 21:48:38.000 [notice] pathbias_count_use_success(): Bug: Unexpectedly high use successes counts (27.000000/5.000000) for guard $<snip> ($<snip>) (on Tor 0.4.8.0-alpha-dev 982c50401c5e9bde)
```
where *\<snip\>* was always the (unhashed) fingerprint itself. This is IMO a waste of space -or- the hashed fingerprint was meant ?https://gitlab.torproject.org/tpo/core/tor/-/issues/40666Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.4.8...2022-10-24T20:48:30ZtoralfBug: Acting on config options left us in a broken state. Dying. (on Tor 0.4.8.0-alpha-dev 982c50401c5e9bde)Happened, when I configure torrc in this manner:
```
MetricsPortPolicy accept 127.0.0.1,accept ::1
```Happened, when I configure torrc in this manner:
```
MetricsPortPolicy accept 127.0.0.1,accept ::1
```