Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T17:42:54Zhttps://gitlab.torproject.org/legacy/trac/-/issues/160"GETINFO network-status" seems to fail2020-06-13T17:42:54ZTrac"GETINFO network-status" seems to failWhen I send a GETINFO control message with the parameter "network-status", the server seems to close the control connection. The timing appears to be inconsistent, sometimes the reply message can be read fully, after which the socket is ...When I send a GETINFO control message with the parameter "network-status", the server seems to close the control connection. The timing appears to be inconsistent, sometimes the reply message can be read fully, after which the socket is closed, sometimes only 8636 bytes can be read. (The number may be coincidental, but was constant in my tests.) Found in 0.1.0.9-rc on win32.
agl ran the demo python script on 0.1.1.0-alpha-cvs and received the following output:
...
[12:41] <agl> {'version': '0.1.1.0-alpha-cvs'}
[12:41] <agl> Traceback (most recent call last):
[12:41] <agl> File "TorControl.py", line 457, in ?
[12:41] <agl> do_main_loop(sh,sp)
[12:41] <agl> File "TorControl.py", line 425, in do_main_loop
[12:41] <agl> print `get_info(s,"network-status")`
[12:41] <agl> File "TorControl.py", line 305, in get_info
[12:41] <agl> tp,body = receive_reply(s,[MSG_TYPE.INFOVALUE])
[12:41] <agl> File "TorControl.py", line 247, in receive_reply
[12:41] <agl> raise ErrorReply((errCode,
[12:41] <agl> __main__.ErrorReply: (1, 'Internal error', 'network-status')
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rmhttps://gitlab.torproject.org/legacy/trac/-/issues/156"NoPublish 1" honored incompletely2020-06-13T13:57:15ZTrac"NoPublish 1" honored incompletelyWhen I set
ClientOnly 1
NoPublish 1
in my torrc, the server nonetheless reports
---------
Jun 09 22:33:32.750 [notice] Tor has successfully opened a circuit. Looks like it's working.
Jun 09 22:33:32.750 [notice] Now checking whether...When I set
ClientOnly 1
NoPublish 1
in my torrc, the server nonetheless reports
---------
Jun 09 22:33:32.750 [notice] Tor has successfully opened a circuit. Looks like it's working.
Jun 09 22:33:32.750 [notice] Now checking whether ORPort and DirPort are reachable... (this may take several minutes)
Jun 09 22:33:43.000 [notice] directory_handle_command_get(): Client asked for the mirrored directory, but we don't have a good one yet. Sending 503 Dir not available.
Jun 09 22:34:36.500 [notice] router_orport_found_reachable(): Your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
---------
However, the node is not listed in the directory, so this seems to be ok. The two ports are actually probed from the outside, though.
Tested on Win2000, SP4.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: rmhttps://gitlab.torproject.org/legacy/trac/-/issues/159Better failure notice on tor_resolve2020-06-13T13:57:15ZTracBetter failure notice on tor_resolveWhen trying to resolve a non-existing domain, I get this:
>tor_resolve.exe doesntexist.abc
Jun 15 11:06:26.750 [warn] parse_socks4a_resolve_response(): Got status response '91': socks request failed.
This could be improved for the end ...When trying to resolve a non-existing domain, I get this:
>tor_resolve.exe doesntexist.abc
Jun 15 11:06:26.750 [warn] parse_socks4a_resolve_response(): Got status response '91': socks request failed.
This could be improved for the end user. I seem to remember that older versions returned something like "Tried resolving ... at three locations, giving up"?
Found with 0.1.0.9-rc, win32, not running as server.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rmhttps://gitlab.torproject.org/legacy/trac/-/issues/153control-spec does not cover password authentication2020-06-13T13:57:15ZTraccontrol-spec does not cover password authenticationThe section in the control-spec.txt about the AUTHENTICATE message (3.8) is a bit unclear on the format in which to send the credentials. The cookie authentication is only mentioned, but no message format given, and the password authenti...The section in the control-spec.txt about the AUTHENTICATE message (3.8) is a bit unclear on the format in which to send the credentials. The cookie authentication is only mentioned, but no message format given, and the password authentication is not mentioned at all.
(The cookie auth message is quite easy to figure out by trying, though - just send the cookie file as the message body.)
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rmhttps://gitlab.torproject.org/legacy/trac/-/issues/154replicable server crash by control message on win2k2020-06-13T13:57:15ZTracreplicable server crash by control message on win2kI found this while trying to implement the password authentication of the tor control protocol. On Windows 2000 Professional, tor 0.1.0.8-rc, the server can be replicably crashed by the following procedure:
- set a HashedControlPassword...I found this while trying to implement the password authentication of the tor control protocol. On Windows 2000 Professional, tor 0.1.0.8-rc, the server can be replicably crashed by the following procedure:
- set a HashedControlPassword in the torrc
- start tor
- open a local tcp connection to the ControlPort
- send a byte sequence like 00 04 00 07 49 50 51 00 (4 bytes length, message type AUTHENTICATE, any password [in this case "123"], null terminator)
On my machine, the server crashes immediately. Example log:
-------
Jun 04 21:54:35.046 [notice] Tor v0.1.0.8-rc. This is experimental software. Do not rely on it for strong anonymity.
Jun 04 21:54:35.109 [notice] Initialized libevent version 1.1 using method win32
Jun 04 21:54:48.437 [err] crypto_seed_rng(): Can't get CryptoAPI provider [2], error code: 8009000f
Jun 04 21:54:50.625 [notice] router_orport_found_reachable(): Your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jun 04 21:54:50.765 [notice] Tor has successfully opened a circuit. Looks like it's working.
Jun 04 21:54:51.406 [notice] directory_handle_command_get(): Client asked for the mirrored directory, but we don't have a good one yet. Sending 503 Dir not available.
Jun 04 21:55:01.703 [err] _tor_malloc(): Out of memory. Dying.
-------
At the time of testing, the machine had >200 MB of physical RAM available, so it's not an actual memory shortage.
Some lines of my torrc:
-------
ControlPort 9696
ClientOnly 1
HashedControlPassword oGd9L4OZ3aBgsMS4044OjH1UDd0tYfh3E1RZZcY=
#CookieAuthentication 1
-------
The rest are just standard settings.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: rmNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/32354Support "Cache Directory Tagging Standard" (already implemented e.g. in GNU tar)2020-06-13T15:47:44ZTracSupport "Cache Directory Tagging Standard" (already implemented e.g. in GNU tar)Tor seems to store sizable cached data in /var/lib/tor/diff-cache/. There is now a standard for apps to indicate that transient caches like this to be skipped from backups: https://bford.info/cachedir/spec.html
The application needs to ...Tor seems to store sizable cached data in /var/lib/tor/diff-cache/. There is now a standard for apps to indicate that transient caches like this to be skipped from backups: https://bford.info/cachedir/spec.html
The application needs to create (and recreate) a file called "CACHEDIR.TAG" in the cache directory, with content of "Signature: 8a477f597d28d172789f06886806bc55".
Skipping cache directories marked as such via this standard is already supported for example in GNU tar:
--exclude-caches
Exclude contents of directories containing file CACHEDIR.TAG, except for the tag file itself.
--exclude-caches-all
Exclude directories containing file CACHEDIR.TAG and the file itself.
--exclude-caches-under
Exclude everything under directories containing CACHEDIR.TAG
**Trac**:
**Username**: rmTor: unspecified