Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:57:15Zhttps://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/152Hidden Services resolving issues2020-06-13T13:57:15ZTracHidden Services resolving issuesIt would seem that hidden services do not resolve to what you might
expect. I found this issue with an incorrectly appended www on the
front of my hidden service, i.e. www.[myhiddenhostremoved].onion which
took me to another hidden serv...It would seem that hidden services do not resolve to what you might
expect. I found this issue with an incorrectly appended www on the
front of my hidden service, i.e. www.[myhiddenhostremoved].onion which
took me to another hidden service (with a pink heart motif favicon)
which definitely wasn't mine, although it was just a blank page.
I tested a few others, and found that www.onion took me to the webpage
of airstrip.jp
Are these resolving oddities intentional, or is there a problem here?
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Grillhttps://gitlab.torproject.org/legacy/trac/-/issues/147os x installer still references 0.0.9.1?2020-06-13T13:57:15ZRoger Dingledineos x installer still references 0.0.9.1?http://tor.eff.org/cvs/tor/contrib/osx/TorStartupDesc.plist
still lists 0.0.9.1. Perhaps it should get autoconfed like
the others to keep pace with the version?
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]http://tor.eff.org/cvs/tor/contrib/osx/TorStartupDesc.plist
still lists 0.0.9.1. Perhaps it should get autoconfed like
the others to keep pace with the version?
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/148osx installer creates startup items even if you don't want them2020-06-13T13:57:15ZRoger Dingledineosx installer creates startup items even if you don't want themReported by Thomas Hardly:
Finally got around to installing the OSX Tor 0.1.0.8-rc Bundle. I
selected "Customize" for the install and chose to install Tor only and
nothing else. The installer instal...Reported by Thomas Hardly:
Finally got around to installing the OSX Tor 0.1.0.8-rc Bundle. I
selected "Customize" for the install and chose to install Tor only and
nothing else. The installer installed a Tor directory inside of
/Library/StartupItems/. Which contained a file called Tor.loc that
contained the text: "//Library/Tor"
While this is not a valid StartupItem, I didnt choose to install any
StartupItem's. It shouldnt be installing anything in that directory.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]https://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/161Tor links to pthreads on OpenBSD by default2020-06-13T13:57:16ZTracTor links to pthreads on OpenBSD by defaultThe ChangeLog and configure.in state that threads are disabled on OpenBSD and NetBSD by default, but it still continues to link to them when building.
> uname -a
OpenBSD chaos.brain-box.net 3.7 FLOW#40 i386
gcc -g -O2 -Wall -g -O2 -o...The ChangeLog and configure.in state that threads are disabled on OpenBSD and NetBSD by default, but it still continues to link to them when building.
> uname -a
OpenBSD chaos.brain-box.net 3.7 FLOW#40 i386
gcc -g -O2 -Wall -g -O2 -o tor buffers.o circuitbuild.o circuitlist.o circuituse.o command.o config.o connection.o connection_edge.o connection_or.o control.o cpuworker.o directory.o dirserv.o dns.o hibernate.o main.o onion.o relay.o rendcommon.o rendclient.o rendmid.o rendservice.o rephist.o router.o routerlist.o routerparse.o tor_main.o ../common/libor.a ../common/libor-crypto.a -lz -lssl -lcrypto -lpthread -levent
../common/libor.a(util.o)(.text+0x3bf): In function `tor_strpartition':
/home/jon/src/tor-0.1.0.10/src/common/util.c:265: warning: strcpy() is almost always misused, please use strlcpy()
../common/libor.a(util.o)(.text+0xad9): In function `base16_encode':
/home/jon/src/tor-0.1.0.10/src/common/util.c:466: warning: sprintf() is often misused, please use snprintf()
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -Wall -g -O2 -c test.c
gcc -g -O2 -Wall -g -O2 -o test buffers.o circuitbuild.o circuitlist.o circuituse.o command.o config.o connection.o connection_edge.o connection_or.o control.o cpuworker.o directory.o dirserv.o dns.o hibernate.o main.o onion.o relay.o rendcommon.o rendclient.o rendmid.o rendservice.o rephist.o router.o routerlist.o routerparse.o test.o ../common/libor.a ../common/libor-crypto.a -lz -lssl -lcrypto -lpthread -levent
test.o(.text+0x2077): In function `test_crypto':
/home/jon/src/tor-0.1.0.10/src/or/test.c:490: warning: strcpy() is almost always misused, please use strlcpy()
../common/libor.a(util.o)(.text+0xad9): In function `base16_encode':
/home/jon/src/tor-0.1.0.10/src/common/util.c:466: warning: sprintf() is often misused, please use snprintf()
test.o(.text+0x23c1): In function `test_crypto':
/home/jon/src/tor-0.1.0.10/src/or/test.c:531: warning: strcat() is almost always misused, please use strlcat()
Making all in tools
cd ../.. && CONFIG_FILES=src/tools/Makefile CONFIG_HEADERS= /bin/sh ./config.status
config.status: creating src/tools/Makefile
config.status: executing default-1 commands
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -Wall -g -O2 -c tor-resolve.c
gcc -g -O2 -Wall -g -O2 -o tor-resolve tor-resolve.o ../common/libor.a -lpthread -levent
tor-resolve.o(.text+0x89): In function `build_socks4a_resolve_request':
***
Even specifing --disable-threads to ./configure does not fix the problem. It still links to pthreads.
'ldd' verifies this :
> ldd tor
tor:
Start End Type Ref Name
00000000 00000000 exe 1 tor
0eb93000 2eb9b000 rlib 1 /usr/lib/libz.so.4.0
09bd2000 29bdd000 rlib 1 /usr/lib/libssl.so.10.0
08447000 28475000 rlib 1 /usr/lib/libcrypto.so.12.0
0ae21000 2ae2a000 rlib 1 /usr/lib/libpthread.so.6.1
0809d000 280d6000 rlib 1 /usr/lib/libc.so.38.0
0890b000 0890b000 rtld 1 /usr/libexec/ld.so
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: jonhttps://gitlab.torproject.org/legacy/trac/-/issues/146Tor Spontaneously Closing on Windows XP SP2 (libevent-related?)2020-06-13T13:57:15ZTracTor Spontaneously Closing on Windows XP SP2 (libevent-related?)Greetings. I am running Windows XP Professional, SP2, with all of
the latest patches and whatnot. I am unsure what--if any--other
information would be relevant to this problem.
I have been having this problem for the last few release ca...Greetings. I am running Windows XP Professional, SP2, with all of
the latest patches and whatnot. I am unsure what--if any--other
information would be relevant to this problem.
I have been having this problem for the last few release candidate
versions (probably since 0.1.0.3). While running
Tor/Tor-in-Server-Mode the program will, at times, just spontaneously
close. Sometimes I will be browsing the Internet through Tor;
sometimes it'll just be running in the background; sometimes I won't
even be at the computer. It gives no indication that there is a
problem; it just shuts down. It can do this anywhere from a few
minutes to a few hours after starting the program. I've tried studying
the debug logs to see some kind of 'common pattern' among the
shutdowns, but have been unable to find one. The only common
occurrence is the line:
[err] do_main_loop(): libevent poll with win32 failed: No such file or directory [2]
Searching the Internet/forums for this problem was not able to yield
any results/fixes. Considering that it hasn't been reported by anyone
else, I would assume this might be a problem with my local setup. But,
I thought I would submit it and see if there is any possible reason
for this or if I had a genuine bug in the program.
I'd be glad to provide any information that anyone may need. Feel free
to ask. And, thanks for any guidance you can provide in attempting to
solve the problem.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: JutralAndrew LewmanAndrew Lewman