Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:04:08Zhttps://gitlab.torproject.org/legacy/trac/-/issues/57Only getting "Launched" circuit events2020-06-13T14:04:08ZTracOnly getting "Launched" circuit eventsI only receive "Launched" event messages (Event: 0x01, Status: 0x00). I have watched over 150 circuits launch but not a single other event is sent.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**:...I only receive "Launched" event messages (Event: 0x01, Status: 0x00). I have watched over 150 circuits launch but not a single other event is sent.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Aphexhttps://gitlab.torproject.org/legacy/trac/-/issues/56Tor is not aggressive enough about improving latency2020-06-13T14:02:11ZTracTor is not aggressive enough about improving latencySummary: Please make Tor more aggressive in detecting when it is using a slow OR path and hence causing it to test out alternate paths.
I've noticed that some Tor ORs are faster than others. The end result is that sometimes I get 'bum' ...Summary: Please make Tor more aggressive in detecting when it is using a slow OR path and hence causing it to test out alternate paths.
I've noticed that some Tor ORs are faster than others. The end result is that sometimes I get 'bum' ORs who slow my system down to a crawl. Tor does not seem to be nearly aggressive enough about detecting this situation and trying alternate routing paths.
I recognize that if Tor was more aggressive about finding better paths a really smart attacker could use DOS attacks against specific ORs to shape traffic into specific proxies but ya gotta admit that's a pretty esoteric attack. For the moment I think performance is more important.
I also recognize that if Tor is too aggressive in optimizing the routing path then better performing ORs will get slammed but that is a self correcting problem.
Please considering adding features to make Tor more aggressive in finding better ORs. The biggest thing keeping me from recommending Tor to all of my friends is the latency it introduces.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: nU8hJ1zQ9https://gitlab.torproject.org/legacy/trac/-/issues/53please do not even publish descriptors with ip 0.0.0.02020-06-13T14:02:11Zweasel (Peter Palfrader)please do not even publish descriptors with ip 0.0.0.0Jan 05 18:53:13.386 [warn] router_resolve(): Could not resolve address for router 'ohmymyohhellyes' at 0.0.0.0
Jan 05 18:53:13.386 [warn] router_resolve_routerlist(): Couldn't resolve router 'ohmymyohhellyes' at '0.0.0.0'; not using
Whi...Jan 05 18:53:13.386 [warn] router_resolve(): Could not resolve address for router 'ohmymyohhellyes' at 0.0.0.0
Jan 05 18:53:13.386 [warn] router_resolve_routerlist(): Couldn't resolve router 'ohmymyohhellyes' at '0.0.0.0'; not using
While the directory does not accept the descriptor, I think tor shouldn't even publish it. Same goes for 127.0.0.1, which the 'foobar' router had the other day.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/52win32 uname doesn't exist2020-06-13T14:02:11ZRoger Dingledinewin32 uname doesn't existDoes uname exist on win32? If so, we should use it. If not,
we should print something vaguely useful in the platform
string.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]Does uname exist on win32? If so, we should use it. If not,
we should print something vaguely useful in the platform
string.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]https://gitlab.torproject.org/legacy/trac/-/issues/50HiddenServiceDir not being parsed correctly2020-06-13T14:10:09ZTracHiddenServiceDir not being parsed correctlyWhen sending SETCONF messages with a hidden service configured, it complains about missing HiddenServiceDir. (NOTE: Probably not reading the config in the correct order?)
rend_config_services(): HiddenServicePort with no preceding Hidde...When sending SETCONF messages with a hidden service configured, it complains about missing HiddenServiceDir. (NOTE: Probably not reading the config in the correct order?)
rend_config_services(): HiddenServicePort with no preceding HiddenServiceDir directive
handle_control_setconf(): Controller gave us config lines that didn't validate.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Aphex0.0.9.3Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/49AllowUnverifiedNodes string keeps growing2020-06-13T14:02:11ZTracAllowUnverifiedNodes string keeps growingWhen saving the AllowUnverifiedNodes in response to a SAVECONF control message, the old values are written out as well.
"AllowUnverifiedNodes middle,rendezvous"
becomes
"AllowUnverifiedNodes middle,rendezvous,middle,rendezvous"
and s...When saving the AllowUnverifiedNodes in response to a SAVECONF control message, the old values are written out as well.
"AllowUnverifiedNodes middle,rendezvous"
becomes
"AllowUnverifiedNodes middle,rendezvous,middle,rendezvous"
and so on...
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Aphex0.0.9.3https://gitlab.torproject.org/legacy/trac/-/issues/48assertion failure: resolve->pending_connection2020-06-13T14:02:11ZNick Mathewsonassertion failure: resolve->pending_connectionReported by Giorgos P.
Dec 31 07:50:01.038 [err] dns.c:399: dns_cancel_pending_resolve:
Assertion resolve->pending_connections failed; aborting.
_probably_ unrelated to other warning:
Dec 30 15:46:29.338 [warn] connection_dns_reached_...Reported by Giorgos P.
Dec 31 07:50:01.038 [err] dns.c:399: dns_cancel_pending_resolve:
Assertion resolve->pending_connections failed; aborting.
_probably_ unrelated to other warning:
Dec 30 15:46:29.338 [warn] connection_dns_reached_eof(): Read eof.
Worker died unexpectedly.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/47Why does the win32 installer have a click-through license?2020-06-13T14:36:29ZRoger DingledineWhy does the win32 installer have a click-through license?Our license is permissive, that is, it only grants rights,
it does not grant rights in exchange for giving up other
rights. So why do we require users to acknowledge that
they "agree" to it?
[Automatically added by flyspray2trac: Operat...Our license is permissive, that is, it only grants rights,
it does not grant rights in exchange for giving up other
rights. So why do we require users to acknowledge that
they "agree" to it?
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/45win32 torrc contains automake macros2020-06-13T14:02:11ZRoger Dingledinewin32 torrc contains automake macrosThe entries in the torrc that ships with win32 still contain
macros like @LOCALSTATEDIR@, which win32 users don't know
what to do with. This makes it really hard for them to, e.g.,
configure logs. Can we convert them to a reasonable set ...The entries in the torrc that ships with win32 still contain
macros like @LOCALSTATEDIR@, which win32 users don't know
what to do with. This makes it really hard for them to, e.g.,
configure logs. Can we convert them to a reasonable set of
defaults on win32 before shipping?
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]0.0.9.5Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/44resolve_my_address() failures can lead to crash.2020-06-13T14:07:13ZNick Mathewsonresolve_my_address() failures can lead to crash.If resolve_my_address() fails at a HUP, then rather than continuing with the old address (desirable if the address hasn't changed) or exiting gracefully (maybe desirable if the address has changed), Tor simply crashes at places like
ma...If resolve_my_address() fails at a HUP, then rather than continuing with the old address (desirable if the address hasn't changed) or exiting gracefully (maybe desirable if the address has changed), Tor simply crashes at places like
main.c: if (write_str_to_file(keydir,
router_get_my_descriptor(), 0)) {
This should get fixed.
Reported by Ben L.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/43Worker threads die vigorously on win32.2020-06-13T14:02:11ZNick MathewsonWorker threads die vigorously on win32.When people try to run a Tor server on windows, it seems that their CPU worker threads and DNS threads too die badly. Or maybe the tor_socketpair stuff isn't really working.
[...]
Dec 25 07:55:03.156 [warn] connection_dns_reached_eof(...When people try to run a Tor server on windows, it seems that their CPU worker threads and DNS threads too die badly. Or maybe the tor_socketpair stuff isn't really working.
[...]
Dec 25 07:55:03.156 [warn] connection_dns_reached_eof(): Read eof. Worker died unexpectedly.
Dec 25 07:55:03.156 [warn] connection_cpu_reached_eof(): Read eof. Worker died unexpectedly.
[...]
Also, these dead workers don't prevent Tor from reporting itself as working when the first circuit is built. That's probably bad.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]https://gitlab.torproject.org/legacy/trac/-/issues/42Overzealous clock skew checking keeps clients from working2020-06-13T14:02:11ZNick MathewsonOverzealous clock skew checking keeps clients from workingThe check for time skew in connection_or.c which produces the log message: "Router '%s' (%s:%d) has a skewed clock..." seems to get called even when Tor is running as a client. This is not as intended; only servers should be forced to m...The check for time skew in connection_or.c which produces the log message: "Router '%s' (%s:%d) has a skewed clock..." seems to get called even when Tor is running as a client. This is not as intended; only servers should be forced to make sure their clocks are relatively correct.
Arma questions whether we should care about clock skew at all. The attacks that we're protecting against are server impersonation attacks where the attacker manage to compromise an older private key for a server, but not a newer one. This doesn't seem very realistic now, since compromising a server's private key will almost surely reveal its identity key; but a slightly cleverer key management system might in the future make this attack meaningfully difficult.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/41nickname length enforcement has fencepost errors2020-06-13T14:02:11ZRoger Dingledinenickname length enforcement has fencepost errorsDec 23 19:08:53.410 [warn] connection_tls_finish_handshake(): Other side (80.127.47.237:9001) is 'thetimesareachangi', but we tried to connect to 'thetimesareachangin'
It should either not have a problem here, or it should have prevente...Dec 23 19:08:53.410 [warn] connection_tls_finish_handshake(): Other side (80.127.47.237:9001) is 'thetimesareachangi', but we tried to connect to 'thetimesareachangin'
It should either not have a problem here, or it should have prevented this guy from starting his server.
Once we track down which it is, we should audit the rest of the uses of options->nickname to make sure it isn't happening elsewhere.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewson