Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T17:18:08Zhttps://gitlab.torproject.org/legacy/trac/-/issues/124Need uninstall directions2020-06-13T17:18:08ZTracNeed uninstall directionsThere should be better instructions for uninstalling tor. The TorFAQ has a really sorry excuse for directions. The OS X installer offers no uninstall option.
Sure, I can delete /usr/bin/tor, but what else was installed and where?
-----...There should be better instructions for uninstalling tor. The TorFAQ has a really sorry excuse for directions. The OS X installer offers no uninstall option.
Sure, I can delete /usr/bin/tor, but what else was installed and where?
--------
2.2. How do I uninstall tor?
This depends entirely on how you installed it. If you installed a package, then hopefully your package has a way to uninstall itself.
If you installed by source, I'm afraid there is no easy uninstall method. But on the bright side, by default it only installs into /usr/local/ and it should be pretty easy to notice things there.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: kmm0.1.0.9Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1220.1.0.2_RC_CVS - Unstable Builds Under NetBSD 2.02020-06-13T13:57:15ZTrac0.1.0.2_RC_CVS - Unstable Builds Under NetBSD 2.0This is a Flyspray task for the NetBSD wierdness we have been discussing on the or-talk list.
To this point in time:
- Beginning about March 30, my daily CVS builds were being unstable - for a few days they crashed upon launch
- Then on...This is a Flyspray task for the NetBSD wierdness we have been discussing on the or-talk list.
To this point in time:
- Beginning about March 30, my daily CVS builds were being unstable - for a few days they crashed upon launch
- Then on April 3 or 4, the daily CVS builds started working again...
web browsing through tor dramatically increased in speed relative to builds prior to March 30
- About the same time there were many log messages. Initiated or-talk discussion...
- On the evening of April 5 (I'm in Indiana - EST for ref.) Nick Mathewson informed me he fixed part
of the problem in CVS but only for the no-pthreads version of tor.
- Morning of April 6, tor was running fine and no new log messages.
- Noticed new CVS changes so updated no-pthreads - restarted tor at 0600
- Just Checked log @ April 6, 3:30PM:
Apr 06 06:06:49.935 [err] Catching signal TERM, exiting cleanly.
Apr 06 06:06:52.404 [notice] Tor 0.1.0.2-rc-cvs opening log file.
Apr 06 11:13:53.401 [warn] circuit_receive_relay_cell(): Didn't recognize cell, but circ stops here! Closing circ.
Apr 06 11:13:53.450 [warn] command_process_relay_cell(): circuit_receive_relay_cell (forward) failed. Closing.
Apr 06 11:15:01.928 [err] Catching signal TERM, exiting cleanly.
Apr 06 11:15:04.890 [notice] Tor 0.1.0.2-rc-cvs opening log file.
Note: I do not recall restarting tor at 11:15, no new core file was generated???
- Just noticed more CVS changes, recompiled no-pthreads but have not installed and restarted
...should I?
- If I don't hear back, I probably will update and restart prior to going to sleep tonight.
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: yancmNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/121if two unverified servers exist at the same address, we list both as running2020-06-13T13:57:15ZRoger Dingledineif two unverified servers exist at the same address, we list both as runningrouter jet 194.152.184.163 9001 9050 9030
published 2005-04-05 20:16:10
router node01 194.152.184.163 9001 9050 9030
published 2005-04-05 13:55:51
Presumably node01 was published first, and then the operator changed the nickname
to jet...router jet 194.152.184.163 9001 9050 9030
published 2005-04-05 20:16:10
router node01 194.152.184.163 9001 9050 9030
published 2005-04-05 13:55:51
Presumably node01 was published first, and then the operator changed the nickname
to jet and left the same identity key in place. Now the dirservers list both as up.
Maybe this will get fixed in 24 hours when node01's descriptor becomes obsolete.
But this is a bad precedent. :)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/120servers don't transform destroys to truncateds2020-06-13T13:57:15ZRoger Dingledineservers don't transform destroys to truncatedsIn command_process_destroy_cell(), we are supposed to convert client-ward destroy cells into
truncated cells, so the client can know at what hop in the path the circuit broke. But we
don't actually do this currently, because the client b...In command_process_destroy_cell(), we are supposed to convert client-ward destroy cells into
truncated cells, so the client can know at what hop in the path the circuit broke. But we
don't actually do this currently, because the client behave was always to close the circuit,
so we were wasting bandwidth with a two-round-trip circuit close.
If we're going to start trying to re-extend circuits, though, we need this functionality.
Should we re-enable the ifdef 0'ed stuff (and remove the circuit_mark_for_close())?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/118server crash when exiting2020-06-13T13:57:15ZRoger Dingledineserver crash when exitingMar 31 12:37:21.214 [notice] Interrupt: will shut down in 30 seconds. Interrupt again to exit now.
Mar 31 12:37:21.347 [notice] Sigint received a second time; exiting now.
Segmentation fault
(gdb) where
#0 0x0808d11f in _openssl_lock...Mar 31 12:37:21.214 [notice] Interrupt: will shut down in 30 seconds. Interrupt again to exit now.
Mar 31 12:37:21.347 [notice] Sigint received a second time; exiting now.
Segmentation fault
(gdb) where
#0 0x0808d11f in _openssl_locking_cb (mode=9, n=9, file=0x40103857 "rsa_lib.c", line=217)
at crypto.c:1653
#1 0x4007b0b8 in CRYPTO_lock () from /lib/libcrypto.so.2
#2 0x4007b120 in CRYPTO_add_lock () from /lib/libcrypto.so.2
#3 0x4009e987 in RSA_free () from /lib/libcrypto.so.2
#4 0x08088f5d in crypto_free_pk_env (env=0x80d1cd0) at crypto.c:265
#5 0x08066663 in cpuworker_main (data=0x815f7f8) at cpuworker.c:272
#6 0x08086977 in tor_pthread_helper_fn (_data=0x8166278) at compat.c:685
#7 0x40122f77 in pthread_start_thread () from /lib/libpthread.so.0
#8 0x4020deba in thread_start () from /lib/libc.so.6
(gdb) print _openssl_mutexes[n]
Cannot access memory at address 0x24
(gdb) print n
$1 = 9
(gdb) print _openssl_mutexes
$2 = (tor_mutex_t **) 0x0
looks like we free the mutexes before we should?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/117event poll failed: Invalid argument [22]2020-06-13T13:57:15Zgoodellevent poll failed: Invalid argument [22]Running 0.1.0.1-rc-cvs:
The Tor server summarily crashes within minutes of starting, with this error:
Mar 31 12:25:25.818 [err] do_main_loop(): event poll failed: Invalid argument [22]
[Automatically added by flyspray2trac: Operating...Running 0.1.0.1-rc-cvs:
The Tor server summarily crashes within minutes of starting, with this error:
Mar 31 12:25:25.818 [err] do_main_loop(): event poll failed: Invalid argument [22]
[Automatically added by flyspray2trac: Operating System: Other Linux]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/115win32 torrc file has funny line endings2020-06-13T13:57:15ZRoger Dingledinewin32 torrc file has funny line endingswordpad works for the win32 torrc we ship in 0.1.0.1-rc, but apparently notepad gets
confused by it. notepad apparently used to work for the previous ones.
is there something wrong with the torrc we ship, or did we skip a step in making...wordpad works for the win32 torrc we ship in 0.1.0.1-rc, but apparently notepad gets
confused by it. notepad apparently used to work for the previous ones.
is there something wrong with the torrc we ship, or did we skip a step in making the exe, or what?
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]0.1.0.2-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/114hidden service descriptors quietly rejected when clock skewed2020-06-13T13:57:15ZRoger Dingledinehidden service descriptors quietly rejected when clock skewedMar 29 06:47:33.643 [warn] rend_cache_store(): Service descriptor h7dkd7zc7aeplgy4 is too far in the future
When clients publish hidden services but their clock is wrong, the hidden service doesn't work. There might
be a log entry expla...Mar 29 06:47:33.643 [warn] rend_cache_store(): Service descriptor h7dkd7zc7aeplgy4 is too far in the future
When clients publish hidden services but their clock is wrong, the hidden service doesn't work. There might
be a log entry explaining this, but perhaps the log entry doesn't say enough? In any case, a log entry may
not be enough to let the user know, if he never looks at his logs.
Is there a better way to communicate this to the user, or is there some way we can cope anyway? (E.g. be more
forgiving about clock skew wrt hidden service descriptors (easy) or remember our skew based on dirserver
timestamps and have Tor "fix" outgoing published timestamps (foolishly hard))
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/113support for user authetication on HttpProxy and HttpsProxy2020-06-13T13:57:15ZTracsupport for user authetication on HttpProxy and HttpsProxyDear TOR-team!
I am stranded behind a firewall which requires user authentication for HTTP, HTTPS, ...
I tried to get a connection to the onion network starting with 0.0.9.5 and it did not work because of the missing httpSproxy option w...Dear TOR-team!
I am stranded behind a firewall which requires user authentication for HTTP, HTTPS, ...
I tried to get a connection to the onion network starting with 0.0.9.5 and it did not work because of the missing httpSproxy option which became available later in the CVS tree. Therefore I tried to compile the latest from CVS but had some problems. So I was very pleased to see the new compiled versions arriving the days before.
Nevertheless an option to specify a user and the required password for a HttpProxy is still missing. The question is: am I missing something or is it "missing in the code"? Will there be a solution or suggestion?
Thank you very much and keep on developing!
Adrian
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: adrianshttps://gitlab.torproject.org/legacy/trac/-/issues/112tor-resolve gives funny error message on failure2020-06-13T13:57:15ZRoger Dingledinetor-resolve gives funny error message on failure%tor-resolve imserver.com
Mar 28 22:17:44.706 [warn] parse_socks4a_resolve_response(): Got status response '91', meaning not success.
Mar 28 22:17:44.706 [err] do_resolve(): Error parsing SOCKS response
[Automatically added by flyspra...%tor-resolve imserver.com
Mar 28 22:17:44.706 [warn] parse_socks4a_resolve_response(): Got status response '91', meaning not success.
Mar 28 22:17:44.706 [err] do_resolve(): Error parsing SOCKS response
[Automatically added by flyspray2trac: Operating System: All]