Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-10-20T23:47:23Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40673Percentage fraction over 100% in logs2022-10-20T23:47:23Zcomputer_freakPercentage fraction over 100% in logs```
[notice] General overload -> Ntor dropped (635498) fraction 325.6826% is above threshold of 0.5000%
[notice] General overload -> Ntor dropped (568293) fraction 222.1682% is above threshold of 0.5000%
[notice] General overload -> Ntor...```
[notice] General overload -> Ntor dropped (635498) fraction 325.6826% is above threshold of 0.5000%
[notice] General overload -> Ntor dropped (568293) fraction 222.1682% is above threshold of 0.5000%
[notice] General overload -> Ntor dropped (448158) fraction 247.2855% is above threshold of 0.5000%
```
Can a percentage _fraction_ ever be over 100% ?Tor: 0.4.7.x-post-stableRoger DingledineRoger Dingledinehttps://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
```https://gitlab.torproject.org/tpo/core/tor/-/issues/40665Disable DH10242022-10-24T20:48:29ZSebastian HahnDisable DH1024An automated scanner detected that Tor is still offering Diffie Hellman with a group size of 1024 bits, and it is creating a security policy question. Can we get this disabled? DH1024 should be pretty much dead around the web.An automated scanner detected that Tor is still offering Diffie Hellman with a group size of 1024 bits, and it is creating a security policy question. Can we get this disabled? DH1024 should be pretty much dead around the web.https://gitlab.torproject.org/tpo/core/tor/-/issues/40664Reject relays running Tor 0.4.6.x2023-12-03T18:23:06ZGeorg KoppenReject relays running Tor 0.4.6.xSimilar to previous tickets (e.g. #40480 and #40559) we should reject EOL versions at the directory authority level. This time the 0.4.6 series is concerned.
We started the whole process this week and are about to contact all relay oper...Similar to previous tickets (e.g. #40480 and #40559) we should reject EOL versions at the directory authority level. This time the 0.4.6 series is concerned.
We started the whole process this week and are about to contact all relay operators with a valid contact information. Additionally, we sent an announcement to [tor-relays@](https://lists.torproject.org/pipermail/tor-relays/2022-August/020765.html).Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40663dirauth: The "my-consensus-*" file is not in the sandbox allowlist2022-12-11T14:02:27ZDavid Gouletdgoulet@torproject.orgdirauth: The "my-consensus-*" file is not in the sandbox allowlistFrom IRC and our resident rodent @weasel:
```
14:55 <+weasel> Aug 18 18:55:01.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /var/lib/tor/my-consensus-microdesc.tmp (on Tor 0.4.7.10 )
14:55 <+weasel> Au...From IRC and our resident rodent @weasel:
```
14:55 <+weasel> Aug 18 18:55:01.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /var/lib/tor/my-consensus-microdesc.tmp (on Tor 0.4.7.10 )
14:55 <+weasel> Aug 18 18:55:01.000 [warn] Couldn't open "/var/lib/tor/my-consensus-microdesc.tmp" (/var/lib/tor/my-consensus-microdesc) for writing: Operation not permitted
```
Considering those are just for dirauth we can stick with 047 and not backport further down.Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40662Incorrect observed bandwidth2022-10-24T20:48:27ZVortIncorrect observed bandwidthRecently I noticed that Metrics shows 17.95 MiB/s observed bandwidth for my relay.
Such value is incorrect since I have physically only 100 Mbit/s connection.
I don't know if such problem is important since load balancing is based on...Recently I noticed that Metrics shows 17.95 MiB/s observed bandwidth for my relay.
Such value is incorrect since I have physically only 100 Mbit/s connection.
I don't know if such problem is important since load balancing is based on bwauth measurements, but I decided to tell about it just in case.
I can think about two reasons for such behaviour:
1. Overload because of DDoS.
2. Time jumps because of active NTPD.
Reason # 2 seems unlikely, because as far as I know ntpd is used in almost all Linux distributions.
Also OS should provide monotonic clocks which are immune to time jumps.
_Version: Tor 0.4.7.10 on Windows 7_https://gitlab.torproject.org/tpo/core/tor/-/issues/40661Do phase 3 of proposal 2892024-01-30T16:07:48ZGeorg KoppenDo phase 3 of proposal 289In [prop#289](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/289-authenticated-sendmes.txt) we included a deployment timeline. Currently we are at Phase 2 and Phase 3 contains the following:
```
This phase ...In [prop#289](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/289-authenticated-sendmes.txt) we included a deployment timeline. Currently we are at Phase 2 and Phase 3 contains the following:
```
This phase will effectively exit() all tor not supporting
"FlowCtrl=1". The earliest date we can do that is when all versions
not supporting v1 are EOL.
According to our release schedule[4], this can happen when our latest
LTS (0.3.5) goes EOL that is on Feb 1st, 2022.
```
We are past Feb 1st, 2022 and 0.3.5.x is gone for good for a while. Let's get to Phase 3 for the next major release at least then.Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40660"Unknown option ''" log message is confusing2022-10-24T20:48:26ZJeremyRand"Unknown option ''" log message is confusing### Summary
I recently upgraded a machine that runs a `tor` service; after a reboot, the `tor` service immediately fails with the log message "[warn] Failed to parse/validate config: Unknown option ''. Failing." This error message is ...### Summary
I recently upgraded a machine that runs a `tor` service; after a reboot, the `tor` service immediately fails with the log message "[warn] Failed to parse/validate config: Unknown option ''. Failing." This error message is confusing, as I initially interpreted it as indicating that empty lines are no longer permitted in `torrc`, which I was just told on IRC is not the case. It would be nice if this message was a bit more helpful in explaining what went wrong.
(Also, as this error has taken down some onion services I run, and I don't know how to fix it, I would appreciate a suggestion on what this log error means even if it's not fixed quickly in the source code.)
### Steps to reproduce:
I have no idea what I did to trigger this, other than installing `apt` upgrades on the machine where it happened. I did update the `torrc` config about 30 minutes before upgrading, but I had already restarted the `tor` service after updating `torrc` and it seemed fine then.
### What is the current bug behavior?
The message is "[warn] Failed to parse/validate config: Unknown option ''. Failing."
### What is the expected behavior?
The message should either say that empty lines are prohibited if that's the case (I believe it is not), or otherwise give some explanation of where the empty string came from and what's supposed to be there instead.
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
- 0.4.5.10.
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.
- Whonix-Gateway 16 (morphed from Debian Bullseye) on ppc64le.
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
- Distro morphing via `apt`.
### Relevant logs and/or screenshots
~~~
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.133 [notice] Tor 0.4.5.10 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5
.2.5, Libzstd 1.4.8 and Glibc 2.31 as libc.
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.133 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/downlo
ad/download#warning
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.133 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.134 [notice] Read configuration file "/etc/tor/torrc".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.142 [notice] Processing configuration path "/etc/torrc.d/*.conf" at recursion level 1.
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/etc/torrc.d/60_network.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/etc/torrc.d/65_gateway.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/etc/torrc.d/65_leak_tests.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/etc/torrc.d/70_workstation.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Processing configuration path "/usr/share/tor/tor-service-defaults-torrc.anondist" at recursion l
evel 2.
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/usr/share/tor/tor-service-defaults-torrc.anondist".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/etc/torrc.d/95_whonix.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Processing configuration path "/usr/local/etc/torrc.d/" at recursion level 2.
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/usr/local/etc/torrc.d//40_tor_control_panel.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.152 [notice] Including configuration file "/usr/local/etc/torrc.d//50_user.conf".
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.157 [warn] Option 'DisableNetwork' used more than once; all but the last value will be ignored.
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.164 [warn] Failed to parse/validate config: Unknown option ''. Failing.
Aug 13 19:50:20 host tor[899]: Aug 13 19:50:20.164 [err] Reading config failed--see warnings above.
~~~
### Possible fixes
No idea.Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40659"No more HSDir available to query" log message is confusing2024-02-24T21:53:25ZJeremyRand"No more HSDir available to query" log message is confusing### Summary
The "No more HSDir available to query" log message does not make it clear whether the problem is on the client's end, the onion's end, or some other network issue. This makes it harder for the user to understand what they s...### Summary
The "No more HSDir available to query" log message does not make it clear whether the problem is on the client's end, the onion's end, or some other network issue. This makes it harder for the user to understand what they should do about it.
### Steps to reproduce:
No idea how to reproduce this log message; it happened for a few hours when the Debian apt onion went down on 2022 August 5, and has not occurred since.
### What is the current bug behavior?
The log message is "No more HSDir available to query".
### What is the expected behavior?
The log message should be along the lines of "No more HSDir available to query; probably this means the onion service went away" according to @arma on IRC (see #tor logs from 2022 August 5).
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
- 982c50401c5e9bde6a1c3ef4bf7a9019e007ab03.
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.
- Debian Bullseye (with a few irrelevant packages pulled in from other Debian suites).
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
- Bug is present in both Debian Bullseye's `apt` package and latest Git source code from Tor Project.
### Relevant logs and/or screenshots
N/A.
### Possible fixes
Looks like this line should be amended: http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/core/tor/-/blob/982c50401c5e9bde6a1c3ef4bf7a9019e007ab03/src/feature/hs/hs_client.c#L89Tor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40658Update IPFire database to August 9th, 20222022-08-12T14:23:27ZDavid Gouletdgoulet@torproject.orgUpdate IPFire database to August 9th, 2022IPFire informed us on August 12th that databases generated after (including) August 10th did not have proper ARIN network allocations.
I'm working on an emergency release containing the August 9th, 2022 database as recommended by IPFire...IPFire informed us on August 12th that databases generated after (including) August 10th did not have proper ARIN network allocations.
I'm working on an emergency release containing the August 9th, 2022 database as recommended by IPFire people.
Making this ticket for a trace and so the changes file is happy.Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40657"This line should not have been reached"2022-11-23T20:52:09Zholmesworcester"This line should not have been reached"### Summary
We are using Tor in Quiet (tryquiet.org) and see a a bunch of lines that say `[warn] Bug: ...` and a line that says `This line should not have been reached` in our logs.
### Steps to reproduce:
This happens often but I'm...### Summary
We are using Tor in Quiet (tryquiet.org) and see a a bunch of lines that say `[warn] Bug: ...` and a line that says `This line should not have been reached` in our logs.
### Steps to reproduce:
This happens often but I'm not sure it happens always.
### What is the current bug behavior?
Tor seems to be working fine, but we see the following in our logs:
```
backend:tor Aug 09 11:04:22.000 [warn] tor_bug_occurred_(): Bug: src/core/or/reasons.c:498: end_reason_to_http_connect_response_line: This line should not have been reached. (on Tor 0.4.7.7 929a90a24fd63b44)
```
### What is the expected behavior?
Presumably we should not see this.
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure. **Tor 0.4.7.7**
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc. **Debian GNU/Linux Bullseye running on ChromeOS VM** (but we've seen it on Ubuntu too)
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc. **Binary from TorBrowser**
### Relevant logs and/or screenshots
[logs-tor.txt](/uploads/72b4353b29e02ef6a58772db3f33f650/logs-tor.txt)
### Possible fixesTor: 0.4.8.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40655Send TRUNCATED backward on an non-error closing OR circuit2022-10-12T13:54:37ZDavid Gouletdgoulet@torproject.orgSend TRUNCATED backward on an non-error closing OR circuitWith https://gitlab.torproject.org/tpo/core/tor/-/issues/40623, we decided to send back a `DESTROY` cell instead of a `TRUNCATED`. However, there is this undesirable effect of this that if data is in-flight to the client, they might get ...With https://gitlab.torproject.org/tpo/core/tor/-/issues/40623, we decided to send back a `DESTROY` cell instead of a `TRUNCATED`. However, there is this undesirable effect of this that if data is in-flight to the client, they might get a `DESTROY` before getting it all.
One example here would be if an `HSDir` would send the descriptor and then immediately close the circuit then it is likely that the whole descriptor might not fully arrive.
So one idea here is that we could simply send a `TRUNCATED` on an OR circuit (non origin) for which the reason for close is "finished" as in not an error. In our example above, the HSDir would send that cell and wait for a `DESTROY` to close the circuit.
In case of errors, we just immediately send a `DESTROY`.Tor: 0.4.7.x-post-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40654Debian repository not updated in over a month2022-08-10T11:59:58ZSpydar007Debian repository not updated in over a monthUnable to create an issue on [the debian project](https://gitlab.torproject.org/tpo/core/debian/tor) so creating here instead.
The repo has not been updated with nightly builds [since June 29](https://deb.torproject.org/torproject.org/d...Unable to create an issue on [the debian project](https://gitlab.torproject.org/tpo/core/debian/tor) so creating here instead.
The repo has not been updated with nightly builds [since June 29](https://deb.torproject.org/torproject.org/dists/tor-nightly-main-bullseye/main/binary-amd64/Packages) (stuck at `20220629T020411Z`).
The pipeline appears to be failing to deploy e.g. [#161655](https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/161655)https://gitlab.torproject.org/tpo/core/tor/-/issues/40653Is it useful turn on "keep alive" for Tor SOCKS5 TCP connection?2022-10-24T20:48:23ZmolnardIs it useful turn on "keep alive" for Tor SOCKS5 TCP connection?
Wasabi Wallet application connects to the [Tor SOCKS5](https://gitweb.torproject.org/torspec.git/tree/socks-extensions.txt) endpoint ([code](https://github.com/zkSNACKs/WalletWasabi/blob/13fdc1566b626ac2dc56c33f0eb707bcab04e55b/WalletWa...
Wasabi Wallet application connects to the [Tor SOCKS5](https://gitweb.torproject.org/torspec.git/tree/socks-extensions.txt) endpoint ([code](https://github.com/zkSNACKs/WalletWasabi/blob/13fdc1566b626ac2dc56c33f0eb707bcab04e55b/WalletWasabi/Tor/Socks5/TorTcpConnectionFactory.cs#L77-L93)) and it specifies various "keep alive" options for that socket connections. Note that the TCP connections connect the application and Tor both of which runs on the same machine and under the same user.
**Question**
Is it necessary to specify that keep-alive options? Is it recommended? Is it useless?
**Version**
we use the latest released Tor 0.4.7.8.
_The question asked here as well_
https://tor.stackexchange.com/questions/23258/is-it-useful-turn-on-keep-alive-for-tor-socks5-tcp-connectionhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40651Generate new fallbackdir list for 0.4.7.9 release2022-08-03T11:57:55ZRoger DingledineGenerate new fallbackdir list for 0.4.7.9 releaseWe're at about 1/3 failures on the current fallbackdir list. I see that @dgoulet has just requested the directory authorities to prepare for the 0.4.7.9 release. And I think there is a new Tor Browser coming out in August sometime.
All ...We're at about 1/3 failures on the current fallbackdir list. I see that @dgoulet has just requested the directory authorities to prepare for the 0.4.7.9 release. And I think there is a new Tor Browser coming out in August sometime.
All of these are great reasons to do a refresh of the fallbackdir list for these upcoming releases. (Releases plural, since it seems smart to put the refreshed list into 0.4.5 and 0.4.6 too, so LTS Tor users can have their Tor work too.)
Thanks!