Trac issues
https://gitlab.torproject.org/legacy/trac/-/issues
2020-06-13T13:57:37Z
https://gitlab.torproject.org/legacy/trac/-/issues/402
Mac Uninstall
2020-06-13T13:57:37Z
Trac
Mac Uninstall
When I use the uninstall instructions for Mac OS X 10.4 (Tiger) Universal Binary : Tor & Privoxy & Vidalia bundle: 0.1.1.29, I get the following output. What I am doing wrong? How can I uninstall all components?
Welcome to Darwin!
jaso...
When I use the uninstall instructions for Mac OS X 10.4 (Tiger) Universal Binary : Tor & Privoxy & Vidalia bundle: 0.1.1.29, I get the following output. What I am doing wrong? How can I uninstall all components?
Welcome to Darwin!
jason-edwards-computer:~ Jason$ cd /Library/Tor
jason-edwards-computer:/Library/Tor Jason$ sudo -s
Password:
jason-edwards-computer:/Library/Tor root# ./uninstall_tor_bundle.sh
bash: ./uninstall_tor_bundle.sh: No such file or directory
jason-edwards-computer:/Library/Tor root#
Some background...
I installed the bundle without X11 Macports or Fink installed on my computer.
I now have X11 installed. I am not sure if this makes a differnce.
Jay
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: jasonedwards3
Andrew Lewman
Andrew Lewman
https://gitlab.torproject.org/legacy/trac/-/issues/403
0.1.2.x warns about non-named servers out of the blue
2020-06-13T13:57:37Z
Roger Dingledine
0.1.2.x warns about non-named servers out of the blue
Mar 11 18:19:50.085 [warn] You specified a server "BlueStar88b" by name, but thi
s name is not registered, so it could be used by any server, not just the one yo
u meant. To make sure you get the same server in the future, refer to it by...
Mar 11 18:19:50.085 [warn] You specified a server "BlueStar88b" by name, but thi
s name is not registered, so it could be used by any server, not just the one yo
u meant. To make sure you get the same server in the future, refer to it by key,
as "$F5B9ABFAB2C44E790AAFC5344B9F00FBDF6DC36E".
Problem is, I didn't ever mention it by name. I only have info level logs, but
they don't help at all. I was probably browsing at the time.
I guess something still refers to something by nickname, internally. I'll try
to collect more info as time goes by.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/404
seg fault on 0.1.2.9-rc dir authority
2020-06-13T13:57:38Z
Roger Dingledine
seg fault on 0.1.2.9-rc dir authority
Mar 10 09:52:01.416 [info] dirserv_orconn_tls_done(): Found router liquidvibration3 to be reachable. Yay.
Mar 10 09:52:01.542 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'mrs5'
Mar 10 09:52...
Mar 10 09:52:01.416 [info] dirserv_orconn_tls_done(): Found router liquidvibration3 to be reachable. Yay.
Mar 10 09:52:01.542 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'mrs5'
Mar 10 09:52:01.562 [info] dirserv_pick_cached_dir_obj(): The server directory is still clean; reusing.
Mar 10 09:52:01.711 [err] routerlist.c:4485: routerlist_assert_ok: Assertion r == r2 failed; aborting.
This was moria1. I'll hopefully get a core if it happens a second time.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/405
exitlist believes obsolete descriptors too
2020-06-13T13:57:38Z
Roger Dingledine
exitlist believes obsolete descriptors too
When you run exitlist with your DirPort enabled, you have many server descriptors
in your cached-routers file. Exitlist looks at every one of them. So if the router
allowed a connection within the past few days, exitlist lists it -- even...
When you run exitlist with your DirPort enabled, you have many server descriptors
in your cached-routers file. Exitlist looks at every one of them. So if the router
allowed a connection within the past few days, exitlist lists it -- even if a newer
descriptor says that its exit policy wouldn't allow that.
I guess that means exitlist should learn about "published" timestamps, and learn how
to recognize if two descriptors are from the same server.
[Automatically added by flyspray2trac: Operating System: All]
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/legacy/trac/-/issues/406
connection.c:2391 assert_connection_ok failed (on bridged dir conn?) 0.1.2.12-rc
2020-06-13T13:57:40Z
seeess
connection.c:2391 assert_connection_ok failed (on bridged dir conn?) 0.1.2.12-rc
0.1.2.12-rc
connection.c:2391 assert_connection_ok: Assertion connection_is_writing(conn) || conn->wants_to_write ||
(conn->type == CONN_TYPE_DIR && TO_DIR_CONN(conn)->is_blocked_on_or_conn) failed; aborting.
Aborted
from the log
Mar ...
0.1.2.12-rc
connection.c:2391 assert_connection_ok: Assertion connection_is_writing(conn) || conn->wants_to_write ||
(conn->type == CONN_TYPE_DIR && TO_DIR_CONN(conn)->is_blocked_on_or_conn) failed; aborting.
Aborted
from the log
Mar 20 09:42:49.783 [info] connection_edge_process_relay_cell(): 524: end cell (closed normally) for stream 23964. Removing stream.
Mar 20 09:42:49.783 [info] connection_edge_process_relay_cell(): end cell (closed normally) dropped, unknown stream.
Mar 20 09:42:49.784 [info] connection_edge_process_relay_cell(): end cell (closed normally) dropped, unknown stream.
Mar 20 09:42:49.784 [info] connection_edge_process_relay_cell(): end cell (closed normally) dropped, unknown stream.
Mar 20 09:42:49.784 [err] connection.c:2391: assert_connection_ok: Assertion connection_is_writing(conn) ||
conn->wants_to_write || (conn->type == CONN_TYPE_DIR && TO_DIR_CONN(conn)->is_blocked_on_or_conn) failed; aborting
[Automatically added by flyspray2trac: Operating System: All]
0.1.2.20
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/legacy/trac/-/issues/407
Unable to mmap new descriptor file
2020-06-13T13:57:41Z
Trac
Unable to mmap new descriptor file
Mar 29 23:23:54:062 [Warning] Unable to mmap new descriptor file at 'C:\Documents and Settings\Ils Haxor\Application Data\tor/cached-routers'.
This warning keeps popping up every time I run Tor. No matter what version I have used, both s...
Mar 29 23:23:54:062 [Warning] Unable to mmap new descriptor file at 'C:\Documents and Settings\Ils Haxor\Application Data\tor/cached-routers'.
This warning keeps popping up every time I run Tor. No matter what version I have used, both stable and the newest one, this keeps occurring.
I am pretty sure this is my only problem, but I haven't even been able to use Tor yet. Anyone know what to do?
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Raindog
https://gitlab.torproject.org/legacy/trac/-/issues/408
Java-Exception when trying to get config with default value
2007-03-27T22:44:01Z
Karsten Loesing
Java-Exception when trying to get config with default value
When requesting a configuration option that is set to a 'default' value semantically different from an empty string,
i.e. Tor replies with a reply line of the form: "250 keyword", the Java Tor controller throws the following exception:
...
When requesting a configuration option that is set to a 'default' value semantically different from an empty string,
i.e. Tor replies with a reply line of the form: "250 keyword", the Java Tor controller throws the following exception:
Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(Unknown Source)
at net.freehaven.tor.control.TorControlConnection1.getConf(TorControlConnection1.java:325)
at net.freehaven.tor.control.TorControlConnection.getConf(TorControlConnection.java:148)
An example for this is requesting the configuration for "DirServer" without having specified such an option in the
configuration file. The result from Tor is just "DirServer", not "DirServer=nodeXY...".
The explanation is that the following code (from TorControlConnection1) assumes that every line is formatted as
"key=value" which is not the case:
for (Iterator it = lst.iterator(); it.hasNext(); ) {
String kv = ((ReplyLine) it.next()).msg;
int idx = kv.indexOf('=');
result.add(new ConfigEntry(kv.substring(0, idx),
kv.substring(idx+1)));
}
A possible solution could be to create and add a ConfigEntry only if idx != -1. At least, this works for DirServer.
[Automatically added by flyspray2trac: Operating System: All]
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/legacy/trac/-/issues/409
Tor doesn't treat 0 as a valid port
2020-06-13T13:57:41Z
Trac
Tor doesn't treat 0 as a valid port
Tor does not treat the officially reserved port 0 as a valid port when considering
exit policies. For example, "reject *:0-19" would be summarixed as "reject *:1-19"
and would show up in the directory as such.
Actual version of tor is ...
Tor does not treat the officially reserved port 0 as a valid port when considering
exit policies. For example, "reject *:0-19" would be summarixed as "reject *:1-19"
and would show up in the directory as such.
Actual version of tor is 0.1.2.12-rc, but that is not listed in the options.
Reference: http://www.iana.org/assignments/port-numbers
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Orum
https://gitlab.torproject.org/legacy/trac/-/issues/410
Bug: circuituse.c:530 (svn 9918)
2020-06-13T13:57:43Z
Trac
Bug: circuituse.c:530 (svn 9918)
fyi...
tor is crashing with the following log message:
Mar 31 13:44:42.085 [err] circuit_detach_stream(): Bug: edge conn not in circuit's list?
Mar 31 13:44:42.085 [err] Bug: circuituse.c:530: circuit_detach_stream: Assertion 0 failed; ...
fyi...
tor is crashing with the following log message:
Mar 31 13:44:42.085 [err] circuit_detach_stream(): Bug: edge conn not in circuit's list?
Mar 31 13:44:42.085 [err] Bug: circuituse.c:530: circuit_detach_stream: Assertion 0 failed; aborting.
gdb bt gives:
clarity 74 -> gdb /usr/local/bin/tor tor.core
GNU gdb 5.3nb1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386--netbsdelf"...
Core was generated by `tor'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libz.so.0...done.
Loaded symbols for /usr/lib/libz.so.0
Reading symbols from /usr/lib/libpthread.so.0...done.
Loaded symbols for /usr/lib/libpthread.so.0
Reading symbols from /usr/local/lib/libevent-1.3b.so.1...done.
Loaded symbols for /usr/local/lib/libevent-1.3b.so.1
Reading symbols from /usr/lib/libssl.so.3...done.
Loaded symbols for /usr/lib/libssl.so.3
Reading symbols from /usr/lib/libcrypto.so.2...done.
Loaded symbols for /usr/lib/libcrypto.so.2
Reading symbols from /usr/lib/libc.so.12...done.
Loaded symbols for /usr/lib/libc.so.12
Reading symbols from /lib/libcrypt.so.0...done.
Loaded symbols for /lib/libcrypt.so.0
Reading symbols from /usr/libexec/ld.elf_so...done.
Loaded symbols for /usr/libexec/ld.elf_so
#0 0xbd9f80fb in kill () from /usr/lib/libc.so.12
(gdb) bt
#0 0xbd9f80fb in kill () from /usr/lib/libc.so.12
(gdb) bt
#0 0xbd9f80fb in kill () from /usr/lib/libc.so.12
#1 0xbda7917f in abort () from /usr/lib/libc.so.12
#2 0x08057d77 in circuit_detach_stream (circ=0x8edfc00, conn=0x8edfe00)
at circuituse.c:530
#3 0x0807d949 in dns_resolve (exitconn=0x8edfe00) at dns.c:631
#4 0x0806ac1d in connection_exit_begin_resolve (cell=0xbfbfe750,
circ=0x8edfc00) at connection_edge.c:2304
#5 0x08088785 in connection_edge_process_relay_cell (cell=0xbfbfe750,
circ=0x8edfc00, conn=0x0, layer_hint=0x0) at or.h:1555
#6 0x080868b9 in circuit_receive_relay_cell (cell=0xbfbfe750, circ=0x8edfc00,
cell_direction=2) at relay.c:170
#7 0x08059d30 in command_process_relay_cell (cell=0xbfbfe750, conn=0x8e6fb00)
at command.c:331
#8 0x0806ccdd in connection_or_process_cells_from_inbuf (conn=0x8e6fb00)
at connection_or.c:780
#9 0x08063cfe in connection_handle_read (conn=0x8e6fb00) at connection.c:1514
#10 0x0808263c in conn_read_callback (fd=25, event=2, _conn=0x8e6fb00)
at main.c:427
#11 0xbdbbb64c in event_process_active (base=0x80f3300) at event.c:315
#12 0xbdbbb8e2 in event_base_loop (base=0x80f3300, flags=0) at event.c:431
#13 0xbdbbb77b in event_loop (flags=0) at event.c:366
#14 0xbdbbb6ba in event_dispatch () at event.c:329
#15 0x08083ccc in do_main_loop () at main.c:1271
---Type <return> to continue, or q <return> to quit---
#16 0x0808498d in tor_main (argc=7, argv=0xbfbfed1c) at main.c:2497
#17 0x080a2c0b in main (argc=7, argv=0xbfbfed1c) at tor_main.c:22
#18 0x0804c996 in ___start ()
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: yancm
https://gitlab.torproject.org/legacy/trac/-/issues/411
Tor Dies, SVN 9918 (relay.c:1562, main.c:1271, tor_main.c:22)
2020-06-13T13:57:46Z
Trac
Tor Dies, SVN 9918 (relay.c:1562, main.c:1271, tor_main.c:22)
VER: Checked out revision 9918.
LOG:
Apr 01 06:23:12.256 [err] Bug: relay.c:1562: next_circ_on_conn_p: Assertion conn == orcirc->p_conn failed; aborting.
# gdb /usr/bin/tor /var/lib/tor/core.7405
GNU gdb Red Hat Linux (6.3.0.0-1.132...
VER: Checked out revision 9918.
LOG:
Apr 01 06:23:12.256 [err] Bug: relay.c:1562: next_circ_on_conn_p: Assertion conn == orcirc->p_conn failed; aborting.
# gdb /usr/bin/tor /var/lib/tor/core.7405
GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
Core was generated by `/usr/bin/tor -f /etc/tor/torrc --pidfile /var/run/tor/tor.pid --log notice file'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/tls/libpthread.so.0...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libevent-1.3b.so.1...Reading symbols from /usr/lib/debug/usr/lib/libevent-1.3b.so.1.0.3.debug...done.
done.
Loaded symbols for /usr/lib/libevent-1.3b.so.1
Reading symbols from /lib/libssl.so.4...done.
Loaded symbols for /lib/libssl.so.4
Reading symbols from /lib/libcrypto.so.4...done.
Loaded symbols for /lib/libcrypto.so.4
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /lib/libcom_err.so.2...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libk5crypto.so.3...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_dns.so.2...done.
Loaded symbols for /lib/libnss_dns.so.2
#0 0x0060e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) bt
#0 0x0060e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x0064e7a5 in raise () from /lib/tls/libc.so.6
#2 0x00650209 in abort () from /lib/tls/libc.so.6
#3 0x08087870 in make_circuit_inactive_on_conn (circ=0x8b6c940, conn=0x921d1b8) at relay.c:1562
#4 0x08054a23 in circuit_set_circid_orconn_helper (circ=0x8b6c940, id=0, conn=0x0, old_id=57696, old_conn=0x921d1b8, active=1)
at circuitlist.c:107
#5 0x08054c8b in circuit_set_p_circid_orconn (circ=0x8b6c940, id=0, conn=0x0) at circuitlist.c:152
#6 0x08059e6f in command_process_cell (cell=0xbffa09f0, conn=0x921d1b8) at or.h:1555
#7 0x0806cb76 in connection_or_process_inbuf (conn=0x921d1b8) at connection_or.c:780
#8 0x080638ad in connection_process_inbuf (conn=Variable "conn" is not available.
) at or.h:962
#9 0x08065d70 in connection_handle_read (conn=0x921d1b8) at connection.c:1514
#10 0x08083038 in conn_read_callback (fd=30, event=2, _conn=0x921d1b8) at main.c:427
#11 0x0098162d in event_base_loop (base=0x86affd8, flags=Variable "flags" is not available.
) at event.c:315
#12 0x009816e0 in event_loop (flags=0) at event.c:366
#13 0x00981704 in event_dispatch () at event.c:329
#14 0x08084e27 in tor_main (argc=15, argv=0xbffa1174) at main.c:1271
#15 0x080a3c23 in main (argc=15, argv=0xbffa1174) at tor_main.c:22
(gdb)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: xiando
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/legacy/trac/-/issues/412
Tor v0.1.2.12-rc segfaults after a while
2020-06-13T13:57:46Z
Trac
Tor v0.1.2.12-rc segfaults after a while
uname -mrs
FreeBSD 6.2-RELEASE-p3 i386
Tor version 0.1.2.12-rc.
Core was generated by `tor'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libz.so.3...done.
Loaded symbols for /lib/libz.so.3
Reading s...
uname -mrs
FreeBSD 6.2-RELEASE-p3 i386
Tor version 0.1.2.12-rc.
Core was generated by `tor'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libz.so.3...done.
Loaded symbols for /lib/libz.so.3
Reading symbols from /lib/libssl.so.5...done.
Loaded symbols for /lib/libssl.so.5
Reading symbols from /lib/libcrypto.so.5...done.
Loaded symbols for /lib/libcrypto.so.5
Reading symbols from /lib/libpthread.so.2...done.
Loaded symbols for /lib/libpthread.so.2
Reading symbols from /lib/libevent-1.2a.so.1...done.
Loaded symbols for /lib/libevent-1.2a.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x2827f537 in pthread_testcancel () from /lib/libpthread.so.2
[New Thread 0x8110200 (runnable)]
[New Thread 0x8110000 (LWP 100098)]
[New Thread 0x80f4000 (runnable)]
[New LWP 100066]
(gdb) where
#0 0x2827f537 in pthread_testcancel () from /lib/libpthread.so.2
#1 0x28277ec8 in pthread_mutexattr_init () from /lib/libpthread.so.2
#2 0x28108450 in ?? ()
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: Orum
https://gitlab.torproject.org/legacy/trac/-/issues/413
cannot compile svn 9944
2020-06-13T13:57:46Z
Trac
cannot compile svn 9944
When I try to build svn 9944, I receive the following:
gcc -g -O2 -Wall -g -O2 -L/usr/local/lib -Wl,-R/usr/local/lib -o tor buffers.o circuitbuild.o circuitlist.o circuituse.o command.o config.o connection.o connection_edge.o conne...
When I try to build svn 9944, I receive the following:
gcc -g -O2 -Wall -g -O2 -L/usr/local/lib -Wl,-R/usr/local/lib -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 policies.o relay.o rendcommon.o rendclient.o rendmid.o rendservice.o rephist.o router.o routerlist.o routerparse.o eventdns.o tor_main.o ../common/libor.a ../common/libor-crypto.a -lz -lpthread -levent -lssl -lcrypto
relay.o(.text+0x2d2e): In function `init_cell_pool':
/home/yancm/torsrc/src/or/relay.c:1488: undefined reference to `mp_pool_new'
relay.o(.text+0x2da4): In function `free_cell_pool':
/home/yancm/torsrc/src/or/relay.c:1496: undefined reference to `mp_pool_destroy'
relay.o(.text+0x2e1e): In function `clean_cell_pool':
/home/yancm/torsrc/src/or/relay.c:1505: undefined reference to `mp_pool_clean'
relay.o(.text+0x2f0e): In function `cell_queue_append_packed_copy':
/home/yancm/torsrc/src/or/relay.c:1519: undefined reference to `mp_pool_get'
relay.o(.text+0x2f4f): In function `cell_queue_clear':
/home/yancm/torsrc/src/or/relay.c:1512: undefined reference to `mp_pool_release'
relay.o(.text+0x3458): In function `connection_or_flush_from_first_active_circuit':
/home/yancm/torsrc/src/or/relay.c:1512: undefined reference to `mp_pool_release'
*** Error code 1
Stop.
make: stopped in /home/yancm/torsrc/src/or
*** Error code 1
Stop.
make: stopped in /home/yancm/torsrc/src
*** Error code 1
Stop.
make: stopped in /home/yancm/torsrc
*** Error code 1
Stop.
make: stopped in /home/yancm/torsrc
[1] Exit 1 make
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: yancm
https://gitlab.torproject.org/legacy/trac/-/issues/414
Dir always C:\program files\tor\ even when other is used
2007-04-16T01:09:17Z
Trac
Dir always C:\program files\tor\ even when other is used
When installed to E:\tor for example the directory in all defaults is still C:\program files\Tor
[Automatically added by flyspray2trac: Operating System: Windows]
**Trac**:
**Username**: liveuk
When installed to E:\tor for example the directory in all defaults is still C:\program files\Tor
[Automatically added by flyspray2trac: Operating System: Windows]
**Trac**:
**Username**: liveuk
Andrew Lewman
Andrew Lewman
https://gitlab.torproject.org/legacy/trac/-/issues/415
seg fault on r9801
2020-06-13T13:57:48Z
Roger Dingledine
seg fault on r9801
moria1 died last night:
#0 0x0000002a95e91be0 in strlen () from /lib/libc.so.6
#1 0x0000002a95e5fcf5 in vfprintf () from /lib/libc.so.6
#2 0x0000002a95e84c76 in vsnprintf () from /lib/libc.so.6
#3 0x0000000000465295 in tor_vsnprintf...
moria1 died last night:
#0 0x0000002a95e91be0 in strlen () from /lib/libc.so.6
#1 0x0000002a95e5fcf5 in vfprintf () from /lib/libc.so.6
#2 0x0000002a95e84c76 in vsnprintf () from /lib/libc.so.6
#3 0x0000000000465295 in tor_vsnprintf (
str=0x7fbfffcc6c "Forgetting obsolete (too old) routerinfo for router 'pr 16 21:11:03.0ôÿ¿\177", size=9962,
format=0x7fbffff3e0 "\027\214®-\031Â80¼Æ\002", args=0x1) at compat.c:320
#4 0x00000000004615d3 in format_msg (
buf=0x7fbfffcc30 "Apr 16 21:11:09.114 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'pr 16 21:11:03.0ôÿ¿\177", buf_len=10022, domain=8192, severity=6,
funcname=0x494ea0 "routerlist_remove_old_routers",
format=0x495bc0 "Forgetting obsolete (too old) routerinfo for router '%s'", ap=0x7fbffff3a0) at log.c:185
#5 0x0000000000460be1 in logv (severity=6, domain=8192,
funcname=0x494ea0 "routerlist_remove_old_routers",
format=0x495bc0 "Forgetting obsolete (too old) routerinfo for router '%s'", ap=0x7fbffff3a0) at log.c:232
#6 0x0000000000460d1f in _log_fn (severity=766413847, domain=2515679776,
fn=0x7fbffff3e0 "\027\214®-\031Â80¼Æ\002",
format=0x1 <Address 0x1 out of bounds>) at log.c:278
#7 0x0000000000454363 in routerlist_remove_old_routers () at routerlist.c:2191
#8 0x0000000000457f3b in update_router_have_minimum_dir_info ()
#9 0x0000000000457e90 in router_have_minimum_dir_info () at routerlist.c:4194
#10 0x0000000000440ccd in run_scheduled_events (now=1176772269) at main.c:931
#11 0x0000000000441219 in second_elapsed_callback (fd=766413847, event=14880,
args=0x7fbffff3e0) at main.c:1063
#12 0x0000002a9599b82d in event_base_priority_init ()
from /usr/lib/libevent-1.1a.so.1
#13 0x0000002a9599ba72 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#14 0x0000002a9599b8e5 in event_loop () from /usr/lib/libevent-1.1a.so.1
#15 0x0000002a9599b84b in event_dispatch () from /usr/lib/libevent-1.1a.so.1
#16 0x000000000044164b in do_main_loop () at main.c:1266
#17 0x000000000044235a in tor_main (argc=766413847, argv=0x2a95f23a20)
at main.c:2492
#18 0x0000002a95e31441 in __libc_start_main () from /lib/libc.so.6
#19 0x000000000040622a in _start () at ../sysdeps/x86_64/elf/start.S:96
iu
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/416
SVN r9989, crash, corrupt stack?
2020-06-13T13:57:50Z
Trac
SVN r9989, crash, corrupt stack?
Checked out revision 9989. Crashed.
(gdb) bt
#0 0x40254c91 in kill () from /lib/libc.so.6
#1 0x40032c85 in pthread_kill () from /lib/libpthread.so.0
#2 0x40032cc6 in raise () from /lib/libpthread.so.0
#3 0x40254a64 in raise () from ...
Checked out revision 9989. Crashed.
(gdb) bt
#0 0x40254c91 in kill () from /lib/libc.so.6
#1 0x40032c85 in pthread_kill () from /lib/libpthread.so.0
#2 0x40032cc6 in raise () from /lib/libpthread.so.0
#3 0x40254a64 in raise () from /lib/libc.so.6
#4 0x40255f9c in abort () from /lib/libc.so.6
#5 0x40289385 in __fsetlocking () from /lib/libc.so.6
#6 0x4028ed40 in malloc_usable_size () from /lib/libc.so.6
#7 0x08081e7a in directory_handle_command (conn=0x92049e0) at directory.c:1727
#8 0x080825bd in connection_dir_process_inbuf (conn=0x92049e0) at directory.c:1336
#9 0x0806a758 in connection_process_inbuf (conn=Variable "conn" is not available.
) at connection.c:2284
#10 0x0806c942 in connection_handle_read (conn=0x92049e0) at connection.c:1514
#11 0x08093838 in conn_read_callback (fd=68, event=2, _conn=0x92049e0) at main.c:428
#12 0x400862f0 in event_base_loop () from /usr/lib/libevent-1.3b.so.1
#13 0x00000001 in ?? ()
#14 0x4007c298 in ?? ()
#15 0xbffffaf0 in ?? ()
#16 0x081096b8 in ?? ()
#17 0xbffffafa in ?? ()
#18 0x0810968c in ?? ()
#19 0xbffffaf0 in ?? ()
#20 0x00000000 in ?? ()
#21 0x00000000 in ?? ()
#22 0x40095034 in selectops () from /usr/lib/libevent-1.3b.so.1
#23 0x08109698 in ?? ()
#24 0x00014194 in ?? ()
#25 0x40081a38 in ?? () from /usr/lib/libevent-1.3b.so.1
#26 0x4009515c in ?? () from /usr/lib/libevent-1.3b.so.1
#27 0x462786bc in ?? ()
#28 0x0008e3dc in ?? ()
#29 0x00000000 in ?? ()
#30 0x000f4237 in ?? ()
#31 0x00000000 in ?? ()
#32 0x4009515c in ?? () from /usr/lib/libevent-1.3b.so.1
#33 0x00000000 in ?? ()
#34 0x4001aca0 in _dl_argv_internal () from /lib/ld-linux.so.2
#35 0xbffffca8 in ?? ()
#36 0x40086597 in event_loop () from /usr/lib/libevent-1.3b.so.1
#37 0x00000000 in ?? ()
#38 0x4009515c in ?? () from /usr/lib/libevent-1.3b.so.1
#39 0x400865bb in event_dispatch () from /usr/lib/libevent-1.3b.so.1
#40 0x400865a6 in event_dispatch () from /usr/lib/libevent-1.3b.so.1
#41 0x08093397 in tor_main (argc=0, argv=0x852) at main.c:1276
Previous frame inner to this frame (corrupt stack?)
(gdb)
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: xiando
https://gitlab.torproject.org/legacy/trac/-/issues/417
[err] routerlist.c:4488: routerlist_assert_ok: Assertion r == r2 failed; abor...
2020-06-13T13:57:54Z
weasel (Peter Palfrader)
[err] routerlist.c:4488: routerlist_assert_ok: Assertion r == r2 failed; aborting.
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d10885 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d12002 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x080afe48 in routerlist_assert_ok (rl=0x8144788) at routerlist.c:4504
#...
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d10885 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d12002 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x080afe48 in routerlist_assert_ok (rl=0x8144788) at routerlist.c:4504
#4 0x080ab058 in routerlist_remove_old_routers () at routerlist.c:2227
#5 0x080af2f8 in update_router_have_minimum_dir_info () at routerlist.c:4211
#6 0x080af23d in router_have_minimum_dir_info () at routerlist.c:4182
#7 0x080942a5 in run_scheduled_events (now=1177084855) at main.c:932
#8 0x08094873 in second_elapsed_callback (fd=-1, event=1, args=0x0) at main.c:1064
#9 0xb7e1fc79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
#10 0xb7e1ff65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#11 0xb7e1fdcb in event_loop () from /usr/lib/libevent-1.1a.so.1
#12 0xb7e1fcb0 in event_dispatch () from /usr/lib/libevent-1.1a.so.1
#13 0x08094d3b in do_main_loop () at main.c:1267
#14 0x08095dcd in tor_main (argc=0, argv=0x0) at main.c:2494
#15 0x080b943b in main (argc=0, argv=0x0) at tor_main.c:22
#16 0xb7cfd970 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#17 0x0804c7f1 in _start () at ../sysdeps/i386/elf/start.S:102
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/418
Option to prevent Tor from opening circuits on its own at startup
2020-06-13T13:57:54Z
Trac
Option to prevent Tor from opening circuits on its own at startup
When Tor is started, it immediately opens some circuits. These circuits cannot be closed via the ControlPort with CLOSECIRCUIT. If you try to close such a circuit, a new one is created immediately. I'd like to have an Option, that, when ...
When Tor is started, it immediately opens some circuits. These circuits cannot be closed via the ControlPort with CLOSECIRCUIT. If you try to close such a circuit, a new one is created immediately. I'd like to have an Option, that, when it is set, has the effect that Tor doesn't open any circuits by itself, letting me - and only me - create circuits manually.
This feature would be handy, if you want Tor to only connect to servers in specific countries or even only specific servers you choose. Because if there are only the circuits you created, all traffic will have to be routed through them, and there will be no chance the traffic is routed through other circuits Tor created itself. Additionally this option would have the effect that you don't need to use ATTACHSTREAM to route every single request through a specific circuit.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: chm
Roger Dingledine
Roger Dingledine
https://gitlab.torproject.org/legacy/trac/-/issues/419
begin_dir broken on 0.1.2.13?
2020-06-13T13:57:55Z
Roger Dingledine
begin_dir broken on 0.1.2.13?
I finally got tunneled connections working correctly for clients.
It works great when connecting to 0.2.0.x servers.
But when connecting to 0.1.2.13, it fetches a lot of directory
info over the TLS connection, but it gets an EOF early:
...
I finally got tunneled connections working correctly for clients.
It works great when connecting to 0.2.0.x servers.
But when connecting to 0.1.2.13, it fetches a lot of directory
info over the TLS connection, but it gets an EOF early:
Apr 27 06:28:38.980 [debug] fetch_from_buf_http(): headerlen 141, bodylen 151383
.
Apr 27 06:28:38.981 [debug] connection_dir_client_reached_eof(): Received respon
se from directory server '86.59.21.38:443': 200 "OK"
Apr 27 06:28:38.981 [debug] connection_dir_client_reached_eof(): Time on receive
d directory is within tolerance; we are -9 seconds skewed. (That's okay.)
Apr 27 06:28:38.997 [info] tor_gzip_uncompress(): possible truncated or corrupt
zlib data
Apr 27 06:28:38.997 [info] connection_dir_client_reached_eof(): Unable to decomp
ress HTTP body (server '86.59.21.38:443').
Apr 27 06:28:38.998 [debug] conn_close_if_marked(): Cleaning up connection (fd -
1).
Apr 27 06:28:38.998 [info] connection_dir_request_failed(): Giving up on directo
ry server at '86.59.21.38'; retrying
Whereas on moria, it works:
Apr 27 06:29:36.305 [debug] fetch_from_buf_http(): headerlen 141, bodylen 471545
.
Apr 27 06:29:36.306 [debug] connection_dir_client_reached_eof(): Received respon
se from directory server '18.244.0.114:443': 200 "OK"
Apr 27 06:29:36.306 [debug] connection_dir_client_reached_eof(): Time on receive
d directory is within tolerance; we are -9 seconds skewed. (That's okay.)
Apr 27 06:29:36.352 [info] connection_dir_client_reached_eof(): Received network
status objects (size 1063662) from server '18.244.0.114:443'
Apr 27 06:29:36.417 [debug] check_directory_signature(): Signed directory hash s
tarts F2FF957E
Is this a bug with 0.2.0's linked connections? Or a bug with 0.1.2.13's handling
of begin_dir?
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/420
funny-looking uname on win98
2020-06-13T13:57:55Z
Roger Dingledine
funny-looking uname on win98
Apr 29 00:45:04.532 [notice] Publication time for router with nickname 'Unnamed'
is too far (34760 minutes) in the past. Not adding (Contact , Platform "Tor 0.1
.1.26 on Windows 98 A ")
Is this " A " a real string from something, or i...
Apr 29 00:45:04.532 [notice] Publication time for router with nickname 'Unnamed'
is too far (34760 minutes) in the past. Not adding (Contact , Platform "Tor 0.1
.1.26 on Windows 98 A ")
Is this " A " a real string from something, or is it a clobbered buffer, or what?
[Automatically added by flyspray2trac: Operating System: All]
Andrew Lewman
Andrew Lewman
https://gitlab.torproject.org/legacy/trac/-/issues/421
micro-revision code doesn't like my svk
2020-06-13T13:57:55Z
Roger Dingledine
micro-revision code doesn't like my svk
Building the tarball hangs for me on my shiny new etch. It turns out:
arma@last-request:~/tor-0.2.0.0-alpha-dev/src/or$ svk info ../..
Repository /home/arma/.svk/local does not exist, create? (y/n)
and the little bash script waits and ...
Building the tarball hangs for me on my shiny new etch. It turns out:
arma@last-request:~/tor-0.2.0.0-alpha-dev/src/or$ svk info ../..
Repository /home/arma/.svk/local does not exist, create? (y/n)
and the little bash script waits and waits. Now, I could answer
it, and I suspect it would work for me in the future. But it won't
work for the next non-svk-using shmo.
[Automatically added by flyspray2trac: Operating System: All]
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/legacy/trac/-/issues/422
Need to back off better when oldest networkstatus isn't downloading right
2020-06-13T13:57:55Z
Roger Dingledine
Need to back off better when oldest networkstatus isn't downloading right
dizum hasn't published a new networkstatus in the past five days. So
clients are rightly calling dizum the oldest, and trying to fetch a
new version. But there isn't a new enough one, so they keep trying,
once per minute.
May 05 01:36:4...
dizum hasn't published a new networkstatus in the past five days. So
clients are rightly calling dizum the oldest, and trying to fetch a
new version. But there isn't a new enough one, so they keep trying,
once per minute.
May 05 01:36:47.708 [info] router_set_networkstatus(): Not replacing
network-status from directory server "dizum" at 194.109.206.212:80
(published 2007-05-01 19:33:17); we have a newer one (published
2007-05-01 19:34:23) for this authority.
http://74.98.7.159:16012/Chatty_Tor.zip has more details. We need
to make clients remember that the networkstatus they're about to
fetch is the same one they fetched last time, and back off if it
keeps failing.
The other piece of this bug is that apparently the network isn't
converging on a single networkstatus from dizum. The fellow who
reported this bug has one from "2007-05-01 19:34:23", but moria2
is currently serving one from "2007-05-01 19:33:17". Is this
because moria2 only asks dizum for updates, and dizum is down,
whereas some dir mirrors ask other places? For completeness:
tor26 is serving one from "2007-05-01 19:31:33", moria1 is serving
one from "2007-05-01 19:30:30", and lefkada has one from
"2007-05-01 19:29:54".
Presumably a few lucky dir mirrors got the latest one from dizum
before it croaked, but the dir mirrors are only asking the dir
authorities, so it's not spreading.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/423
segfault in routerlist_remove_old/digestmap_remove
2020-06-13T13:57:56Z
weasel (Peter Palfrader)
segfault in routerlist_remove_old/digestmap_remove
r10094 on tor26:
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 digestmap_remove (map=0x814cef0, key=0xb7483e4c <Address 0xb7483e4c out of bounds>) at container.c:850
#1 0x080ab70d in routerlist_remove_old (rl=0x81...
r10094 on tor26:
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 digestmap_remove (map=0x814cef0, key=0xb7483e4c <Address 0xb7483e4c out of bounds>) at container.c:850
#1 0x080ab70d in routerlist_remove_old (rl=0x814c658, sd=0xb7483e18, idx=2215) at routerlist.c:1869
#2 0x080acf75 in routerlist_remove_old_routers () at routerlist.c:2441
#3 0x080b12b8 in update_router_have_minimum_dir_info () at routerlist.c:4497
#4 0x080b11fd in router_have_minimum_dir_info () at routerlist.c:4468
#5 0x08093205 in run_scheduled_events (now=1178534900) at main.c:1006
#6 0x08093813 in second_elapsed_callback (fd=-1, event=1, args=0x0) at main.c:1145
#7 0xb7fbcc79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
#8 0xb7fbcf65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#9 0xb7fbcdcb in event_loop () from /usr/lib/libevent-1.1a.so.1
#10 0x08093d53 in do_main_loop () at main.c:1357
#11 0x08094dfd in tor_main (argc=-1220002228, argv=0xb7483e4c) at main.c:2584
#12 0x080bca3b in main (argc=-1220002228, argv=0xb7483e4c) at tor_main.c:28
possibly related to 404/417
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/424
Seg fault on r10125 authority
2020-06-13T13:57:58Z
Roger Dingledine
Seg fault on r10125 authority
#0 0x0000002a95e93cf5 in strcasecmp () from /lib/libc.so.6
#1 0x000000000043a2b6 in dirserv_orconn_tls_done (
address=0x9f0a00 "66.23.214.241", or_port=443,
digest_rcvd=0x7fbffff4a0 "1ÛL\fÛZó@á L\033Q-ÁrE\207ÿ\a", as_advertised...
#0 0x0000002a95e93cf5 in strcasecmp () from /lib/libc.so.6
#1 0x000000000043a2b6 in dirserv_orconn_tls_done (
address=0x9f0a00 "66.23.214.241", or_port=443,
digest_rcvd=0x7fbffff4a0 "1ÛL\fÛZó@á L\033Q-ÁrE\207ÿ\a", as_advertised=1)
at dirserv.c:2023
#2 0x00000000004295c6 in connection_or_check_valid_handshake (conn=0x3f937e0,
started_here=1, digest_rcvd=0x7fbffff4a0 "1ÛL\fÛZó@á L\033Q-ÁrE\207ÿ\a")
at connection_or.c:683
#3 0x000000000042988c in connection_tls_finish_handshake (conn=0x3f937e0)
at connection_or.c:710
#4 0x00000000004202ce in connection_read_to_buf (conn=0x3f937e0,
max_to_read=0x7fbffff554) at connection.c:1649
#5 0x000000000041fc15 in connection_handle_read (conn=0x3f937e0)
at connection.c:1554
#6 0x00000000004412e3 in conn_read_callback (fd=10422784, event=0,
_conn=0x2a95f207a0) at main.c:482
#7 0x0000002a9578482d in event_base_priority_init ()
from /usr/lib/libevent-1.1a.so.1
#8 0x0000002a95784a72 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#9 0x0000002a957848e5 in event_loop () from /usr/lib/libevent-1.1a.so.1
#10 0x0000000000442be1 in do_main_loop () at main.c:1358
#11 0x00000000004438fa in tor_main (argc=10422784, argv=0x0) at main.c:2585
#12 0x0000002a95e31441 in __libc_start_main () from /lib/libc.so.6
(gdb) up
#1 0x000000000043a2b6 in dirserv_orconn_tls_done (
address=0x9f0a00 "66.23.214.241", or_port=443,
digest_rcvd=0x7fbffff4a0 "1ÛL\fÛZó@á L\033Q-ÁrE\207ÿ\a", as_advertised=1)
at dirserv.c:2023
2023 SMARTLIST_FOREACH(rl->routers, routerinfo_t *, ri, {
(gdb) print address
$1 = 0x9f0a00 "66.23.214.241"
(gdb) print ri->address
$2 = 0x0
(gdb) print *ri
$3 = {cache_info = {signed_descriptor_body = 0x97332d0 "(",
signed_descriptor_len = 182905534440,
signed_descriptor_digest = "\026A&\002Tç!^XØ%\n`\2074}\022ÓÖ*g",
identity_digest = "q®xoY@4,[§\227(þVõØsF7\005", published_on = 1178746494,
extra_info_digest = '\0' <repeats 19 times>,
saved_location = SAVED_IN_JOURNAL, saved_offset = 16290,
do_not_cache = 0}, address = 0x0, nickname = 0x0, addr = 200508994,
or_port = 9001, dir_port = 0, onion_pkey = 0x2cf56c0,
identity_pkey = 0x40faf90, platform = 0x0, bandwidthrate = 3145728,
bandwidthburst = 6291456, bandwidthcapacity = 0, exit_policy = 0x1938090,
uptime = 442, declared_family = 0x0, contact_info = 0x0, is_hibernating = 0,
has_old_dnsworkers = 0, caches_extra_info = 0, is_running = 0, is_valid = 1,
is_named = 0, is_fast = 0, is_stable = 0, is_possible_guard = 0,
is_exit = 0, is_bad_exit = 0, purpose = 0 '\0', last_reachable = 0,
testing_since = 0, num_unreachable_notifications = 240, routerlist_index = 0}
(gdb) up
#2 0x00000000004295c6 in connection_or_check_valid_handshake (conn=0x3f937e0,
started_here=1, digest_rcvd=0x7fbffff4a0 "1ÛL\fÛZó@á L\033Q-ÁrE\207ÿ\a")
at connection_or.c:683
683 dirserv_orconn_tls_done(conn->_base.address, conn->_base.port,
(gdb) print *conn
$4 = {_base = {magic = 2100428547, type = 4 '\004', state = 4 '\004',
purpose = 0 '\0', read_blocked_on_bw = 0, write_blocked_on_bw = 0,
hold_open_until_flushed = 0, inbuf_reached_eof = 0, edge_has_sent_end = 0,
edge_blocked_on_circ = 0, or_is_obsolete = 0, chosen_exit_optional = 0,
s = 1348, conn_array_index = 141, read_event = 0x7bc7260,
write_event = 0x65ded60, inbuf = 0x5861120, outbuf = 0x1e78920,
outbuf_flushlen = 0, timestamp_lastread = 1178746732,
timestamp_lastwritten = 1178746730, timestamp_created = 1178746730,
addr = 1108858609, port = 443, marked_for_close = 0,
marked_for_close_file = 0x0, address = 0x9f0a00 "66.23.214.241",
linked_conn = 0x0, linked = 0, reading_from_linked_conn = 0,
writing_to_linked_conn = 0, active_on_link = 0},
identity_digest = "1ÛL\fÛZó@á L\033Q-ÁrE\207ÿ\a",
nickname = 0x1d155c0 "madrigal", tls = 0x4acdb30, tls_error = 0,
client_used = 0 '\0', timestamp_lastempty = 1178746731,
bandwidthrate = 3145728, bandwidthburst = 6291456, read_bucket = 6291456,
n_circuits = 0, active_circuits = 0x0, next_with_same_id = 0x0,
circ_id_type = CIRC_ID_TYPE_HIGHER, next_circ_id = 20489}
The broken routerinfo_t had an uptime of 442. I found a descriptor that
matched that in cached-routers.new, which alas looks ordinary enough:
router rexy 11.243.134.66 9001 0 0
platform Tor 0.1.2.13 on Windows XP Service Pack 2 [workstation] {terminal servi
ces, single user}
published 2007-05-09 21:34:54
opt fingerprint 71AE 786F 5940 342C 5BA7 9728 FE56 F5D8 7346 3705
uptime 442
bandwidth 3145728 6291456 0
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMCt5iI8puWc6NrsbYkrl2CeAfUV51HoXbyRnHbPSy0IGnZJdLJC0JNl
nI33sbBqUpLbqxYWUpoO61o1PVrtCQo8Q/mY26/c6+oQfWgjAhUGm4opkxf0TAr5
4rnMGBoBaW7mv27z/yii/3bCdyw8Ewrf6CxojA1QZ9dnd7Fzn95zAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAORD3KG4cCqyjLAZshO3tSMjzuhttbZ6Jfgcam9QipAhI+V5vNgRN8Xr
5cnLHtAOsYjW3LYI/ONXTMYbr7fe/3fWBhRd7J70tLEoGc14QhNhCIQO10x7FXSk
4ueJgwyZ/G6mgk5E9K1eqljaSdJ3/n9PHQEgICFAfi6rnNQ9OnclAgMBAAE=
-----END RSA PUBLIC KEY-----
opt write-history 2007-05-09 21:23:13 (900 s) 105472,53248,38912,57344,71680,686
08,50176,61440,40960,57344,53248,23552,73728,25600,63488,38912,26624,70656,38912
,63488,57344,390144,43008,28672,0,47104,696320,194560,0,0,0,0,0,13312,112640,228
352
opt read-history 2007-05-09 21:23:13 (900 s) 1949696,531456,592896,528384,608256
,537600,592896,530432,583680,525312,588800,505856,608256,516096,619520,539648,59
1872,542720,607232,542720,622592,1421312,1927168,21504,0,1931264,2076672,1075200
,0,0,0,0,0,1027072,1467392,2020352
contact leucamarian at yahoo dot com
reject 0.0.0.0/8:*
reject 169.254.0.0/16:*
reject 127.0.0.0/8:*
reject 192.168.0.0/16:*
reject 10.0.0.0/8:*
reject 172.16.0.0/12:*
reject *:25
reject *:119
reject *:135-139
reject *:445
reject *:465
reject *:563
reject *:587
reject *:1214
reject *:4661-4666
reject *:6346-6429
reject *:6699
reject *:6881-6999
accept *:*
router-signature
-----BEGIN SIGNATURE-----
E/e7KfpNra2+fz+4yx923vmpfOrrFDM9i4QSNkVUzC7KJV7ojJ9dxwkc0PjbV0Gm
zqkFPHe7gYqyjHa4XDQbaAQK7eMmxNgg8z4ndcpc6uZrVC8UAhX35FjYWJEVnj+7
mnOLPsokJlmcEH/+3Ln3BmKx4lfcpqAVa5/0ATDIsCY=
-----END SIGNATURE-----
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/425
circuitlist.c:1076 assert failure 0.1.2.12-rc
2020-06-13T13:57:59Z
seeess
circuitlist.c:1076 assert failure 0.1.2.12-rc
0.1.2.12-rc bombed out on my OR
from the log
May 08 05:03:07.903 [info] conn_close_if_marked(): Conn (addr [scrubbed], fd 61, type Directory, state 6) marked, but wants to flush 18336 bytes. (Marked at main.c:641)
May 08 05:03:07.903 [i...
0.1.2.12-rc bombed out on my OR
from the log
May 08 05:03:07.903 [info] conn_close_if_marked(): Conn (addr [scrubbed], fd 61, type Directory, state 6) marked, but wants to flush 18336 bytes. (Marked at main.c:641)
May 08 05:03:07.903 [info] conn_close_if_marked(): We stalled too much while trying to write 15416 bytes to addr [scrubbed]. If this happens a lot, either something is wrong with your network connection, or something is wrong with theirs. (fd 61, type Directory, state 6, marked at main.c:641).
May 08 05:03:09.895 [warn] Failing because we have 991 connections already. Please raise your ulimit -n.
May 08 05:03:09.985 [info] connection_exit_connect_dir(): Opening dir bridge
May 08 05:03:09.985 [warn] Failing because we have 991 connections already. Please raise your ulimit -n.
May 08 05:03:10.210 [err] circuitlist.c:1076: assert_circuit_ok: Assertion conn->_base.type == CONN_TYPE_EXIT failed; aborting.
my ulimit -n is 1024
gdb bt
Core was generated by `tor -f /var/lib/tor/data.pub/torrc'.
Program terminated with signal 6, Aborted.
#0 0xb7f9d410 in ?? ()
(gdb) bt
#0 0xb7f9d410 in ?? ()
#1 0xbfdd992c in ?? ()
#2 0x00000006 in ?? ()
#3 0x00006d6c in ?? ()
#4 0xb7ced771 in raise () from /lib/libc.so.6
#5 0xb7ceeea8 in abort () from /lib/libc.so.6
#6 0x080581ae in assert_circuit_ok (c=0xa6ae020) at circuitlist.c:1049
#7 0x08072f3d in connection_exit_begin_conn (cell=0xbfdd9c80, circ=0xa6ae020)
at connection_edge.c:2099
#8 0x0809a8f5 in connection_edge_process_relay_cell (cell=0xbfdd9c80,
circ=0xa6ae020, conn=0x0, layer_hint=0x0) at relay.c:1019
#9 0x0809b0a0 in circuit_receive_relay_cell (cell=0xbfdd9c80, circ=0xa6ae020,
cell_direction=2) at relay.c:169
#10 0x0805d05b in command_process_cell (cell=0xbfdd9c80, conn=0x8472d18)
at command.c:327
#11 0x0807552e in connection_or_process_inbuf (conn=0x8472d18)
at connection_or.c:768
#12 0x080694c6 in connection_process_inbuf (conn=0x6d6c, package_partial=1)
at connection.c:2242
#13 0x0806c513 in connection_handle_read (conn=0x8472d18) at connection.c:1452
#14 0x08095bb8 in conn_read_callback (fd=152, event=2, _conn=0x8472d18)
at main.c:422
#15 0xb7df2332 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#16 0xb7df2549 in event_loop () from /usr/lib/libevent-1.1a.so.1
#17 0xb7df256e in event_dispatch () from /usr/lib/libevent-1.1a.so.1
#18 0x08095717 in tor_main (argc=3, argv=0xbfdda424) at main.c:1267
#19 0x080b8ee2 in main (argc=Cannot access memory at address 0x6d6c
) at tor_main.c:22
note: I did already upgrade to .13 (running on another instance) on that box, and had to recompile .12 to get a bt, i dunno if that matters at all but fyi
so let me know what to type in to gdb or what info you need
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/426
infinite directory information retrieval loop
2020-06-13T13:58:00Z
Trac
infinite directory information retrieval loop
After upgrading from version 0.1.1.26 to version 0.1.2.13
(Debian package version 0.1.2.13-3 from mirror.noreply.org),
tor fails to initialise. It seems to be stuck in an infinite loop:
May 12 00:59:19.239 [notice] I learned some more d...
After upgrading from version 0.1.1.26 to version 0.1.2.13
(Debian package version 0.1.2.13-3 from mirror.noreply.org),
tor fails to initialise. It seems to be stuck in an infinite loop:
May 12 00:59:19.239 [notice] I learned some more directory information, but not enough to build a circuit.
May 12 00:59:19.272 [notice] I learned some more directory information, but not enough to build a circuit.
May 12 00:59:19.305 [notice] I learned some more directory information, but not enough to build a circuit.
...and so on
It seems to bombard the directory servers with new connections at
the same rate.
...
tcp 0 0 192.168.0.164:37919 86.59.21.38:80 ESTABLISHED103 6329904 27340/tor
tcp 0 0 192.168.0.164:37914 86.59.21.38:80 ESTABLISHED103 6329896 27340/tor
tcp 199 0 192.168.0.164:37893 86.59.21.38:80 CLOSE_WAIT 103 6329866 27340/tor
...
My tor router runs behind a NAT-firewall, with the listener ports
9001 and 9030 forwarded to the right host and 'Address' in torrc
set to a FQDN pointing to the external IP address.
The daemon runs in a Xen-domU, but I don't think this problem is
related to that.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: erikbosman
https://gitlab.torproject.org/legacy/trac/-/issues/427
circuituse.c:540: circuit_detach_stream: Assertion 0 failed
2020-06-13T13:58:02Z
Trac
circuituse.c:540: circuit_detach_stream: Assertion 0 failed
Tor crashed, died.
Checked out revision 10167.
/var/log/tor/tor.log
May 15 03:59:59.726 [warn] eventdns rejected address [scrubbed]: error 1.
May 15 03:59:59.726 [err] circuit_detach_stream(): Bug: edge conn not in circuit's list?
May ...
Tor crashed, died.
Checked out revision 10167.
/var/log/tor/tor.log
May 15 03:59:59.726 [warn] eventdns rejected address [scrubbed]: error 1.
May 15 03:59:59.726 [err] circuit_detach_stream(): Bug: edge conn not in circuit's list?
May 15 03:59:59.726 [err] Bug: circuituse.c:540: circuit_detach_stream: Assertion 0 failed; aborting.
(gdb) bt
#0 0x40254c91 in kill () from /lib/libc.so.6
#1 0x401dec85 in pthread_kill () from /lib/libpthread.so.0
#2 0x401decc6 in raise () from /lib/libpthread.so.0
#3 0x40254a64 in raise () from /lib/libc.so.6
#4 0x40255f9c in abort () from /lib/libc.so.6
#5 0x0805bc68 in circuit_detach_stream (circ=0x80dcb4c, conn=0x6) at circuituse.c:489
#6 0x0808d6f8 in dns_cancel_pending_resolve (
address=0x8ed6398 "g378727577666a797e78687a6769756e747e337a6a6e6a72737371457a68726a337772776a77w7ixtnei.palengam.com") at dns.c:835
#7 0x0808e45b in dns_resolve (exitconn=0x8bffd58) at dns.c:1239
#8 0x08074ab2 in connection_exit_begin_conn (cell=0xbffff5c0, circ=0x8cf1880) at connection_edge.c:2235
#9 0x0809c7ef in connection_edge_process_relay_cell (cell=0xbffff5c0, circ=0x8cf1880, conn=0x0, layer_hint=0x0) at relay.c:1028
#10 0x0809cfb0 in circuit_receive_relay_cell (cell=0xbffff5c0, circ=0x8cf1880, cell_direction=2) at relay.c:171
#11 0x0805e04d in command_process_cell (cell=0xbffff5c0, conn=0x87a5e00) at command.c:331
#12 0x080770ae in connection_or_process_inbuf (conn=0x87a5e00) at connection_or.c:780
#13 0x0806c4a6 in connection_process_inbuf (conn=Variable "conn" is not available.
) at connection.c:2394
#14 0x0806ebd9 in connection_handle_read (conn=0x87a5e00) at connection.c:1579
#15 0x08095d68 in conn_read_callback (fd=166, event=2, _conn=0x87a5e00) at main.c:482
#16 0x400442f0 in event_base_loop () from /usr/lib/libevent-1.3b.so.1
#17 0x4003e000 in ?? ()
#18 0x4003e000 in ?? ()
#19 0x03b67565 in ?? ()
#20 0x08110408 in ?? ()
#21 0xbffffb0a in ?? ()
#22 0x081103dc in ?? ()
#23 0xbffffb00 in ?? ()
#24 0x00000000 in ?? ()
#25 0x00000000 in ?? ()
#26 0x40053034 in selectops () from /usr/lib/libevent-1.3b.so.1
#27 0x081103e8 in ?? ()
#28 0x00000001 in ?? ()
#29 0x00000000 in ?? ()
#30 0x0804a228 in ?? ()
#31 0x4649141f in ?? ()
#32 0x000afc9a in ?? ()
#33 0x00000000 in ?? ()
#34 0x000f4238 in ?? ()
#35 0x00000001 in ?? ()
#36 0x4005315c in ?? () from /usr/lib/libevent-1.3b.so.1
#37 0x00000000 in ?? ()
#38 0x40348f80 in ?? ()
#39 0xbffffca8 in ?? ()
#40 0x40044597 in event_loop () from /usr/lib/libevent-1.3b.so.1
#41 0x00000000 in ?? ()
#42 0x00000000 in ?? ()
#43 0x080958bb in tor_main (argc=50, argv=0xa0012) at main.c:1359
Previous frame inner to this frame (corrupt stack?)
(gdb)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: xiando
Roger Dingledine
Roger Dingledine
https://gitlab.torproject.org/legacy/trac/-/issues/428
r10217 seg fault, buf malloc
2020-06-13T13:58:04Z
Roger Dingledine
r10217 seg fault, buf malloc
#0 0x0000002a95e8c514 in mallopt () from /lib/libc.so.6
#1 0x0000002a95e8bd80 in mallopt () from /lib/libc.so.6
#2 0x0000002a95e8aff7 in malloc () from /lib/libc.so.6
#3 0x0000002a9567494e in zcalloc () from /usr/lib/libz.so.1
#4 0x...
#0 0x0000002a95e8c514 in mallopt () from /lib/libc.so.6
#1 0x0000002a95e8bd80 in mallopt () from /lib/libc.so.6
#2 0x0000002a95e8aff7 in malloc () from /lib/libc.so.6
#3 0x0000002a9567494e in zcalloc () from /usr/lib/libz.so.1
#4 0x0000002a9567075c in deflateInit2_ () from /usr/lib/libz.so.1
#5 0x0000000000477999 in tor_zlib_new (compress=1, method=GZIP_METHOD)
at torgzip.c:57
#6 0x0000000000435dc9 in directory_handle_command_get (conn=0x84db30,
headers=0x5b6706c "", body=0x5b6ba90 "\026(;Odz\221©A", body_len=10944416)
at directory.c:1839
#7 0x000000000043663c in directory_handle_command (conn=0x84db30)
at directory.c:2045
#8 0x0000000000435139 in connection_dir_process_inbuf (conn=0x84db30)
at directory.c:1430
#9 0x00000000004204bf in connection_handle_read (conn=0x84db30)
at connection.c:1595
#10 0x0000000000441f23 in conn_read_callback (fd=10944544, event=0,
_conn=0x5b6ba90) at main.c:482
#11 0x0000002a9578482d in event_base_priority_init ()
from /usr/lib/libevent-1.1a.so.1
#12 0x0000002a95784a72 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#13 0x0000002a957848e5 in event_loop () from /usr/lib/libevent-1.1a.so.1
#14 0x0000000000443841 in do_main_loop () at main.c:1365
#15 0x000000000044456a in tor_main (argc=10944544, argv=0xa70000)
at main.c:2592
#16 0x0000002a95e31441 in __libc_start_main () from /lib/libc.so.6
#17 0x00000000004062ea in _start () at ../sysdeps/x86_64/elf/start.S:96
(gdb) up
#6 0x0000000000435dc9 in directory_handle_command_get (conn=0x84db30,
headers=0x5b6706c "", body=0x5b6ba90 "\026(;Odz\221©A", body_len=10944416)
at directory.c:1839
1839 conn->zlib_state = tor_zlib_new(1, ZLIB_METHOD);
(gdb) print *conn
$1 = {_base = {magic = 2575892462, type = 9 '\t', state = 6 '\006',
purpose = 10 '\n', read_blocked_on_bw = 0, write_blocked_on_bw = 0,
hold_open_until_flushed = 0, inbuf_reached_eof = 0, edge_has_sent_end = 0,
edge_blocked_on_circ = 0, or_is_obsolete = 0, chosen_exit_optional = 0,
s = 83, conn_array_index = 1777, read_event = 0x2f1f1c0,
write_event = 0x2f1f790, inbuf = 0x29c4920, outbuf = 0x5b040e0,
outbuf_flushlen = 175, timestamp_lastread = 1179561790,
timestamp_lastwritten = 1179561790, timestamp_created = 1179561790,
addr = 1418132278, port = 1568, marked_for_close = 0,
marked_for_close_file = 0x0, address = 0x6509f0 "84.134.251.54",
linked_conn = 0x0, linked = 0, reading_from_linked_conn = 0,
writing_to_linked_conn = 0, active_on_link = 0}, requested_resource = 0x0,
dirconn_direct = 0, dir_spool_src = DIR_SPOOL_SERVER_BY_DIGEST,
fingerprint_stack = 0x29c4dd0, cached_dir = 0x0, cached_dir_offset = 0,
zlib_state = 0x0, rend_query = '\0' <repeats 16 times>,
identity_digest = '\0' <repeats 19 times>}
(gdb) up
#7 0x000000000043663c in directory_handle_command (conn=0x84db30)
at directory.c:2045
2045 r = directory_handle_command_get(conn, headers, body, body_len);
(gdb) print headers
$3 = 0x5763910 "GET /tor/server/d/C079F0F9E0E36569650BB18E333B0B1D6C37E59E+196F1544419BAA1FBB554D81DC568FF0F1255AAE+3F3E59CBB2AFA7B339CF99CA9040362AC72702A9+F4CB70F7FFEBCCA0520F00D88ED8E7FAC3D01208+E201ACE150813CED8E"...
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/429
routerlist.c:1565: signed_descriptor_get_body: Assertion !memcmp("router ", r...
2020-06-13T13:58:08Z
weasel (Peter Palfrader)
routerlist.c:1565: signed_descriptor_get_body: Assertion !memcmp("router ", r, 7) || !memcmp("extra-
May 19 12:56:05.449 [notice] We now have enough directory information to build circuits.
May 19 12:56:34.620 [err] Bug: routerlist.c:1565: signed_descriptor_get_body: Assertion !memcmp("router ", r, 7) || !memcmp("extra-info ", r, 11) fa...
May 19 12:56:05.449 [notice] We now have enough directory information to build circuits.
May 19 12:56:34.620 [err] Bug: routerlist.c:1565: signed_descriptor_get_body: Assertion !memcmp("router ", r, 7) || !memcmp("extra-info ", r, 11) failed; aborting.
on r10217
the bt:
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7c99885 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7c9b002 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x080abc44 in signed_descriptor_get_body (desc=0x6) at routerlist.c:1572
#4 0x080a9799 in router_rebuild_store (force=0, extrainfo=157592432) at routerlist.c:404
#5 0x080aea0d in router_load_extrainfo_from_string (s=0xd64a7e8 "", saved_location=20, requested_fingerprints=0x86eead8) at routerlist.c:2673
#6 0x08082e81 in connection_dir_client_reached_eof (conn=0x884bec0) at directory.c:1251
#7 0x08083e6f in connection_dir_reached_eof (conn=0x884bec0) at directory.c:1400
#8 0x0806b68c in connection_handle_read (conn=0x884bec0) at connection.c:1604
#9 0x08093089 in conn_read_callback (fd=40, event=2, _conn=0x884bec0) at main.c:482
#10 0xb7eebc79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
#11 0xb7eebf65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#12 0xb7eebdcb in event_loop () from /usr/lib/libevent-1.1a.so.1
#13 0x08094cf3 in do_main_loop () at main.c:1365
#14 0x08095d9d in tor_main (argc=0, argv=0x0) at main.c:2592
#15 0x080be9cb in main (argc=0, argv=0x0) at tor_main.c:28
however, the state looks quite broken:
(at #3)
(gdb) p desc
$3 = (signed_descriptor_t *) 0x6
(gdb) p len
$4 = 0
(gdb) p r
$5 = 0x80f7d60 "!memcmp(\"router \", r, 7) || !memcmp(\"extra-info \", r, 11)"
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/430
segfault in assert_connection_ok (conn=0x464edc2b, now=1179573236) at connect...
2020-06-13T13:58:09Z
weasel (Peter Palfrader)
segfault in assert_connection_ok (conn=0x464edc2b, now=1179573236) at connection.c:2562
r10217
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 assert_connection_ok (conn=0x464edc2b, now=1179573236) at connection.c:2562
#1 0x08093081 in conn_read_callback (fd=1235, event=3, _conn=0x464edc2b) at main.c:4...
r10217
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 assert_connection_ok (conn=0x464edc2b, now=1179573236) at connection.c:2562
#1 0x08093081 in conn_read_callback (fd=1235, event=3, _conn=0x464edc2b) at main.c:480
#2 0xb7f5ac79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
#3 0xb7f5af65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#4 0xb7f5adcb in event_loop () from /usr/lib/libevent-1.1a.so.1
#5 0x08094cf3 in do_main_loop () at main.c:1365
#6 0x08095d9d in tor_main (argc=1179573236, argv=0x464edbf4) at main.c:2592
#7 0x080be9cb in main (argc=1179573236, argv=0x464edbf4) at tor_main.c:28
(gdb) p routerlist->mmap_descriptors->data
$1 = 0xb65f5000 <Address 0xb65f5000 out of bounds>
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/431
Bug: routerlist.c:5048: routerlist_assert_ok: Assertion sd failed; aborting.
2020-06-13T13:58:10Z
weasel (Peter Palfrader)
Bug: routerlist.c:5048: routerlist_assert_ok: Assertion sd failed; aborting.
[notice] Your Tor server's identity key fingerprint is 'tor26 847B 1F85 0344 D787 6491 A548 92F9 0493 4E4E B85D'
[err] Bug: routerlist.c:5048: routerlist_assert_ok: Assertion sd failed; aborting.
r10221
(gdb) bt
#0 0xffffe410 in __ker...
[notice] Your Tor server's identity key fingerprint is 'tor26 847B 1F85 0344 D787 6491 A548 92F9 0493 4E4E B85D'
[err] Bug: routerlist.c:5048: routerlist_assert_ok: Assertion sd failed; aborting.
r10221
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7cab885 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7cad002 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x080b3a14 in routerlist_assert_ok (rl=0x81583e8) at routerlist.c:5014
#4 0x080ac542 in extrainfo_insert (rl=0x81583e8, ei=0x84f6820) at routerlist.c:1818
#5 0x080adcb3 in router_add_extrainfo_to_routerlist (ei=0x84f6820, msg=0xbfd4dabc, from_cache=1, from_fetch=0) at routerlist.c:2338
#6 0x080aeac6 in router_load_extrainfo_from_string (s=0xb7c81c2e <Address 0xb7c81c2e out of bounds>, saved_location=SAVED_IN_CACHE, requested_fingerprints=0x0) at routerlist.c:2696
#7 0x080a99a4 in router_reload_router_list_impl (extrainfo=1) at routerlist.c:442
#8 0x080a9b0d in router_reload_router_list () at routerlist.c:485
#9 0x08094bdb in do_main_loop () at main.c:1326
#10 0x08095d7d in tor_main (argc=0, argv=0x0) at main.c:2592
#11 0x080bee1b in main (argc=0, argv=0x0) at tor_main.c:28
#3 0x080b3a14 in routerlist_assert_ok (rl=0x81583e8) at routerlist.c:5014
(gdb) p *(extrainfo_t *)_ei
$1 = {cache_info = {signed_descriptor_body = 0x0, signed_descriptor_len = 416, signed_descriptor_digest = "\221\033YQyg&\211\032P)íywÅî\201ÄÂÐ", identity_digest = "ÿËFÛ\0239Ú\204gLp×ËXd4Ä7\004A",
published_on = 1178768642, extra_info_digest = '\0' <repeats 19 times>, ei_dl_status = {next_attempt_at = 0, n_download_failures = 0 '\0'}, saved_location = SAVED_IN_CACHE, saved_offset = 0, do_not_cache = 0},
nickname = "moria1", '\0' <repeats 13 times>, bad_sig = 0, pending_sig = 0x0, pending_sig_len = 0}
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/432
trunk can't be built with -O0
2020-06-13T13:58:10Z
weasel (Peter Palfrader)
trunk can't be built with -O0
r10221 can't be built with -O0. I guess the extern INLINE confuses gcc 3.3.5.
../common/libor-crypto.a(crypto.o)(.text+0x4df6): In function `smartlist_shuffle':
/home/weasel/projects/tor/tor-trunk/src/common/crypto.c:1691: undefined re...
r10221 can't be built with -O0. I guess the extern INLINE confuses gcc 3.3.5.
../common/libor-crypto.a(crypto.o)(.text+0x4df6): In function `smartlist_shuffle':
/home/weasel/projects/tor/tor-trunk/src/common/crypto.c:1691: undefined reference to `smartlist_swap'
collect2: ld returned 1 exit status
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/433
Tor 0.1.2.13 - Error initializing dns subsystem
2020-06-13T13:58:11Z
Trac
Tor 0.1.2.13 - Error initializing dns subsystem
I just upgraded to Tor 0.1.2.13 on Solaris 8 (Generic_117350-46) and now the service dies out complaing
it cannot read resolv.conf. I even attempted to set the ServerDNSResolvConfFile to another (new)
resolv.conf using my ISP DNS rathe...
I just upgraded to Tor 0.1.2.13 on Solaris 8 (Generic_117350-46) and now the service dies out complaing
it cannot read resolv.conf. I even attempted to set the ServerDNSResolvConfFile to another (new)
resolv.conf using my ISP DNS rather than my internal DNS servers thinking the private net and the loopback
might be causing issues. For some reason, the log output at 00:29:59.165 (below) shows tor adding 127.0.0.l
as a DNS server (which there is) but its not defined in the new resolv conf and I even took it out of the
system resolv.conf for one round of testing.
I've poked around and tried running this as mu tor user and then root to rule out permissions issues with
no change. Googling shows the code changes around this, but I'm no coder and unfortunately cant see any
obvious problems.
Debug log Output (running as root for testing):
> /opt/csw/bin/tor -f /opt/csw/etc/tor/torrc
May 21 00:29:59.123 [notice] Tor v0.1.2.13. This is experimental software. Do not rely on it for strong anonymity.
May 21 00:29:59.137 [notice] Initialized libevent version 1.1a using method devpoll. Good.
May 21 00:29:59.138 [notice] Opening OR listener on 0.0.0.0:49001
May 21 00:29:59.139 [notice] Opening Socks listener on 127.0.0.1:9050
May 21 00:29:59.140 [notice] Opening Socks listener on 10.15.20.10:9100
May 21 00:29:59.140 [notice] Opening Control listener on 127.0.0.1:9051
[root@lapetus:tor, 00:29:59]> May 21 00:29:59.142 [notice] Tor 0.1.2.13 opening log file.
May 21 00:29:59.143 [debug] parse_dir_server_line(): Trusted dirserver at 18.244.0.188:9031 (46DB)
May 21 00:29:59.143 [debug] parse_dir_server_line(): Trusted dirserver at 18.244.0.114:80 (E45D)
May 21 00:29:59.143 [debug] parse_dir_server_line(): Trusted dirserver at 86.59.21.38:80 (1F85)
May 21 00:29:59.144 [debug] parse_dir_server_line(): Trusted dirserver at 140.247.60.64:80 (F5FC)
May 21 00:29:59.144 [debug] parse_dir_server_line(): Trusted dirserver at 194.109.206.212:80 (EAD6)
May 21 00:29:59.145 [info] or_state_load(): Loaded state from "/opt/csw/var/lib/tor/state"
May 21 00:29:59.147 [debug] parse_addr_policy(): Adding new entry 'accept 10.15.20.0/24'
May 21 00:29:59.147 [debug] parse_addr_policy(): Adding new entry 'accept 127.0.0.1'
May 21 00:29:59.147 [debug] parse_addr_policy(): Adding new entry 'reject *'
May 21 00:29:59.147 [warn] You are running Tor as root. You don't need to, and you probably shouldn't.
May 21 00:29:59.162 [info] crypto_seed_rng(): Seeding RNG from "/dev/urandom"
May 21 00:29:59.164 [info] configure_nameservers(): Parsing resolver configuration in '/etc/resolv.conf'
May 21 00:29:59.164 [info] eventdns: Parsing resolv.conf file /etc/resolv.conf
May 21 00:29:59.165 [info] eventdns: Added nameserver 127.0.0.1
May 21 00:29:59.165 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf'
May 21 00:29:59.172 [err] Error initializing dns subsystem; exiting
May 21 00:29:59.233 [info] or_state_save(): Saved state to "/opt/csw/var/lib/tor/state"
May 21 00:29:59.234 [debug] _connection_free(): closing fd 5.
May 21 00:29:59.234 [debug] _connection_free(): closing fd 8.
May 21 00:29:59.235 [debug] _connection_free(): closing fd 9.
May 21 00:29:59.235 [debug] _connection_free(): closing fd 10.
[Automatically added by flyspray2trac: Operating System: Solaris]
**Trac**:
**Username**: geekcq
https://gitlab.torproject.org/legacy/trac/-/issues/434
bw history does not recover from bad clock
2020-06-13T13:58:11Z
weasel (Peter Palfrader)
bw history does not recover from bad clock
consider the case of the router Chahf1or.
On 2007-03-30 13:33:56 all was well. It uploaded a descriptor that was ok:
| platform Tor 0.1.1.26 on Linux i686
| published 2007-03-30 14:35:13
| opt write-history 2007-03-30 14:34:34 (900 s) ...
consider the case of the router Chahf1or.
On 2007-03-30 13:33:56 all was well. It uploaded a descriptor that was ok:
| platform Tor 0.1.1.26 on Linux i686
| published 2007-03-30 14:35:13
| opt write-history 2007-03-30 14:34:34 (900 s) 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,135784,1677901,5858264,19367946,8275640,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,90167,23801,4620560
| opt read-history 2007-03-30 14:34:34 (900 s) 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2754204,630370,679589,4017341,2312131,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3186242,555644,677757
then its clock went bad and it tried to upload a few descriptors, from 2009-06-02 14:11:04, 2009-06-03 14:11:01, and 2035-08-28 14:13:14.
Ever since its bandwidth history is broken:
| platform Tor 0.1.1.26 on Linux i686
| published 2007-03-30 14:40:21
| opt write-history 2035-08-28 14:04:34 (900 s) 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
| opt read-history 2009-06-03 14:04:34 (900 s) 1396,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
or
| platform Tor 0.1.2.13 on Linux i686
| published 2007-05-24 13:48:58
| opt write-history 2035-08-28 14:04:34 (900 s) 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
| opt read-history 2009-06-03 14:04:34 (900 s) 1024,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
Tor should probably try to recover from broken accounting info like that.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/435
0.1.2.14 compile broken on FreeBSD box
2020-06-13T13:58:11Z
Trac
0.1.2.14 compile broken on FreeBSD box
There should be a semicolon at the end of line 3905 of src/or/config.c.
Seems nobody has tested the compiling on a FreeBSD box :(
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: Kurapica
There should be a semicolon at the end of line 3905 of src/or/config.c.
Seems nobody has tested the compiling on a FreeBSD box :(
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: Kurapica
https://gitlab.torproject.org/legacy/trac/-/issues/436
memory clobbered in tor_snprintf?
2020-06-13T13:58:12Z
Roger Dingledine
memory clobbered in tor_snprintf?
My dir auths seg fault:
#0 0x00002b79edb335b0 in strlen () from /lib/libc.so.6
#1 0x00002b79edb054bc in vfprintf () from /lib/libc.so.6
#2 0x00002b79edb2572a in vsnprintf () from /lib/libc.so.6
#3 0x0000000000471d33 in tor_vsnprintf...
My dir auths seg fault:
#0 0x00002b79edb335b0 in strlen () from /lib/libc.so.6
#1 0x00002b79edb054bc in vfprintf () from /lib/libc.so.6
#2 0x00002b79edb2572a in vsnprintf () from /lib/libc.so.6
#3 0x0000000000471d33 in tor_vsnprintf (str=0x7fffbd8f3ad0 "HTTP/1.0 200 ",
size=4788951, format=0x7fffbd8f3a01 ":\217½ÿ\177", args=0x3)
at compat.c:322
#4 0x0000000000471dd1 in tor_snprintf (str=0x5 <Address 0x5 out of bounds>,
size=4788951, format=0x7fffbd8f3a01 ":\217½ÿ\177") at compat.c:302
#5 0x0000000000434863 in write_http_status_line (conn=0x95b930, status=3,
reason_phrase=0x0) at directory.c:1458
#6 0x0000000000436d49 in directory_handle_command (conn=0x95b930)
at directory.c:1997
#7 0x00000000004378d5 in connection_dir_process_inbuf (conn=0x5)
at directory.c:1430
#8 0x0000000000423d0b in connection_handle_read (conn=0x95b930)
at connection.c:1597
#9 0x0000000000447670 in conn_read_callback (fd=<value optimized out>,
event=<value optimized out>, _conn=<value optimized out>) at main.c:467
#10 0x00002b79ed3e70e2 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#11 0x00000000004472de in tor_main (argc=<value optimized out>,
argv=<value optimized out>) at main.c:1349
#12 0x00002b79edadd4ca in __libc_start_main () from /lib/libc.so.6
#13 0x000000000040634a in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb) up
#4 0x0000000000471dd1 in tor_snprintf (str=0x5 <Address 0x5 out of bounds>,
size=4788951, format=0x7fffbd8f3a01 ":\217½ÿ\177") at compat.c:302
302 r = tor_vsnprintf(str,size,format,ap);
(gdb) up
#5 0x0000000000434863 in write_http_status_line (conn=0x95b930, status=3,
reason_phrase=0x0) at directory.c:1458
1458 if (tor_snprintf(buf, sizeof(buf), "HTTP/1.0 %d %s\r\n\r\n",
(gdb) up
#6 0x0000000000436d49 in directory_handle_command (conn=0x95b930)
at directory.c:1997
1997 write_http_status_line(conn, 200, "Service descriptor stored");
If I set an assert inside write_http_status_line to make sure that
reason_phrase is non-null, it always is. It's getting clobbered
somewhere inside. Whenever this happens it always ends up with str=0x5
and status=3. So it's a deterministic clobbering, whatever it is.
I've gone hunting in a variety of places; I'll try to document them here
as I remember and re-check them.
One hint: it happens in r10233, but not in r10100. (It's harder to test the
ones in between because they trigger on the other bugs we were hunting.)
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/437
Tor tries to connect to a TrackHostExits host/exit pair indefinitely
2020-06-13T13:58:13Z
Trac
Tor tries to connect to a TrackHostExits host/exit pair indefinitely
When TrackHostExits is used and an exit is chosen for the site that's being connected to, if the exit fails to connect
to the site but is still running, Tor will attempt to connect to the site through that exit node through different
cir...
When TrackHostExits is used and an exit is chosen for the site that's being connected to, if the exit fails to connect
to the site but is still running, Tor will attempt to connect to the site through that exit node through different
circuits and continue to fail to connect into all of eternity, until it finally does manage to make a connection, or
until the stream is closed.
Tor should be able to determine that the exit node is no longer capable of making a connection to the specified site,
and forget the current exit and use another after failing it's connection attempts for some extended period of time.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: SnowKate709
0.2.0.x-rc
Roger Dingledine
Roger Dingledine
https://gitlab.torproject.org/legacy/trac/-/issues/438
Not checking families in all cases
2020-06-13T13:58:13Z
Roger Dingledine
Not checking families in all cases
circuit_find_to_cannibalize() compares keys when deciding if two routers
are the same, but it doesn't check families.
This calls maybe for a "is r1 the same router or same family as
r2" function, plus a code audit for everywhere we comp...
circuit_find_to_cannibalize() compares keys when deciding if two routers
are the same, but it doesn't check families.
This calls maybe for a "is r1 the same router or same family as
r2" function, plus a code audit for everywhere we compare routers
for equality and/or add them to smartlists.
[Automatically added by flyspray2trac: Operating System: All]
post 0.2.0.x
https://gitlab.torproject.org/legacy/trac/-/issues/439
directory_handle_command_post: Assertion msg failed
2020-06-13T13:58:14Z
weasel (Peter Palfrader)
directory_handle_command_post: Assertion msg failed
r10393
May 29 20:28:37.551 [err] Bug: directory.c:1971: directory_handle_command_post: Assertion msg failed; aborting.
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d21885 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb...
r10393
May 29 20:28:37.551 [err] Bug: directory.c:1971: directory_handle_command_post: Assertion msg failed; aborting.
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d21885 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d23002 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x08086080 in directory_handle_command_post (conn=0x907a5b0, headers=0x0,
body=0xd9e18e0 "quit\r\n\r\n", body_len=8) at directory.c:1962
#4 0x0808616c in directory_handle_command (conn=0x907a5b0) at directory.c:2050
#5 0x080848bd in connection_dir_process_inbuf (conn=0x907a5b0)
at directory.c:1436
#6 0x0806bb65 in connection_handle_read (conn=0x907a5b0) at connection.c:1613
#7 0x080948a9 in conn_read_callback (fd=1803, event=2, _conn=0x907a5b0)
at main.c:475
#8 0xb7f73c79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/440
Guard nodes not weighted by bandwidth
2020-06-13T13:58:14Z
Mike Perry
Guard nodes not weighted by bandwidth
Tor clients are currently selecting guard nodes uniformly. The add_an_entry_guard call passes in
a NULL state to choose_good_entry_server, which causes it to call router_choose_random_node with
need_capacity=0.
I marked severity as Hi...
Tor clients are currently selecting guard nodes uniformly. The add_an_entry_guard call passes in
a NULL state to choose_good_entry_server, which causes it to call router_choose_random_node with
need_capacity=0.
I marked severity as High because this is obviously screwing with load balancing of the network
and probably has a large negative impact on user experience. Also, a backport of the fix is
essential since it really won't have any effect until most clients start using it.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/441
Tor v0.2.0.1-alpha on IRIX crashes shortly after startup
2020-06-13T13:58:14Z
Trac
Tor v0.2.0.1-alpha on IRIX crashes shortly after startup
Tor v0.2.0.1-alpha on IRIX crashes shortly after startup. Log snippet and backtrace attached below.
Jun 01 20:47:45.602 [notice] Tor v0.2.0.1-alpha. This is experimental software. Do not rely on it for strong anonymity. (Running on IRIX...
Tor v0.2.0.1-alpha on IRIX crashes shortly after startup. Log snippet and backtrace attached below.
Jun 01 20:47:45.602 [notice] Tor v0.2.0.1-alpha. This is experimental software. Do not rely on it for strong anonymity. (Running on IRIX64 IP30)
[...]
Jun 01 20:47:54.161 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'whowantstoknow'
Jun 01 20:47:54.162 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'peleion'
Jun 01 20:47:54.162 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'gondortor'
Jun 01 20:47:54.163 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'splunk'
Jun 01 20:47:54.163 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'opgdev'
Jun 01 20:47:54.164 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router '2Wire6726'
Jun 01 20:47:54.164 [info] routerlist_remove_old_routers(): Forgetting obsolete (too old) routerinfo for router 'homer'
Jun 01 20:47:54.165 [err] Bug: routerlist.c:5179: routerlist_assert_ok: Assertion !memcmp(sd->extra_info_digest, d, DIGEST_LEN) failed; aborting.
routerlist.c:5179 routerlist_assert_ok: Assertion !memcmp(sd->extra_info_digest, d, DIGEST_LEN) failed; aborting.
Abort (core dumped)
---
dbx version 7.3.4 (86441_Nov11 MR) Nov 11 2002 11:31:55
Core from signal SIGABRT: Abort (see abort(3c))
(dbx) where
Thread 0x10000
> 0 _prctl(0x15, 0x4, 0xffff, 0x0, 0x0, 0x118, 0x2c0, 0x1a0) ["/xlv41/6.5.30m/work/irix/lib/libc/libc_n32_M4/proc/prctl.s":15, 0xfa4ac28]
1 pthread_kill(0x15, 0x6, 0xffff, 0x0, 0x0, 0x118, 0x2c0, 0x1a0) ["/xlv41/6.5.30m/work/eoe/lib/libpthread/libpthread_n32_M3/sig.c":150, 0xc0900c4]
2 _SGIPT_libc_raise(0x15, 0x4, 0xffff, 0x0, 0x0, 0x118, 0x2c0, 0x1a0) ["/xlv41/6.5.30m/work/eoe/lib/libpthread/libpthread_n32_M3/sig.c":660, 0xc0910d8]
3 _raise(0x15, 0x4, 0xffff, 0x0, 0x0, 0x118, 0x2c0, 0x1a0) ["/xlv41/6.5.30m/work/irix/lib/libc/libc_n32_M4/signal/raise.c":26, 0xfad1f3c]
4 abort(0x15, 0x4, 0xffff, 0x0, 0x0, 0x118, 0x2c0, 0x1a0) ["/xlv41/6.5.30m/work/irix/lib/libc/libc_n32_M4/gen/abort.c":52, 0xfa6f6b0]
5 routerlist_assert_ok(rl = 0x1012ebc0) ["/usr/people/jm/tmp/xxx/tor/src/or/routerlist.c":5179, 0x100b2714]
6 routerlist_remove_old_routers() ["/usr/people/jm/tmp/xxx/tor/src/or/routerlist.c":2670, 0x100a979c]
7 update_router_have_minimum_dir_info() ["/usr/people/jm/tmp/xxx/tor/src/or/routerlist.c":4826, 0x100b08ec]
8 router_have_minimum_dir_info() ["/usr/people/jm/tmp/xxx/tor/src/or/routerlist.c":4797, 0x100b086c]
9 directory_info_has_arrived(now = 1180723673, from_cache = 1) ["/usr/people/jm/tmp/xxx/tor/src/or/main.c":676, 0x1007fc94]
10 do_main_loop() ["/usr/people/jm/tmp/xxx/tor/src/or/main.c":1345, 0x10081808]
11 tor_main(argc = 3, argv = 0x7fff2f64) ["/usr/people/jm/tmp/xxx/tor/src/or/main.c":2610, 0x10083280]
12 main(argc = 3, argv = 0x7fff2f64) ["/usr/people/jm/tmp/xxx/tor/src/or/tor_main.c":28, 0x100c53dc]
13 __start() ["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177, 0x10014318]
(dbx) up 5
routerlist_assert_ok:5179 tor_assert(!memcmp(sd->extra_info_digest, d, DIGEST_LEN));
(dbx) p *sd
struct signed_descriptor_t {
signed_descriptor_body = 0x10201860 = ""
signed_descriptor_len = 1296911693
signed_descriptor_digest = ""
identity_digest = "MMMMMMMMMMMMMMMMMMMM"
published_on = 1296911693
extra_info_digest = "MMMMMMMMMMMMMMMMMMMM"
ei_dl_status = struct download_status_t {
next_attempt_at = 1296911693
n_download_failures = 'M'
}
saved_location = 1296911693
saved_offset = 5570193308531903821
do_not_cache = 0
is_extrainfo = 1
}
(dbx) p d
0x1023f214 = ""
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: jm
https://gitlab.torproject.org/legacy/trac/-/issues/442
[err] Bug: routerlist.c:5179
2020-06-13T13:58:15Z
Trac
[err] Bug: routerlist.c:5179
Latest svn builds are dying after a few minutes:
May 29 06:40:02.099 [notice] Tor 0.2.0.0-alpha-dev (r10386) opening log file.
May 29 06:41:56.503 [err] Bug: routerlist.c:5144: routerlist_assert_ok: Assertion !memcmp(sd->extra_info_dige...
Latest svn builds are dying after a few minutes:
May 29 06:40:02.099 [notice] Tor 0.2.0.0-alpha-dev (r10386) opening log file.
May 29 06:41:56.503 [err] Bug: routerlist.c:5144: routerlist_assert_ok: Assertion !memcmp(sd->extra_info_digest, d, DIGEST_LEN) failed; aborting.
May 29 20:40:35.883 [notice] Tor 0.2.0.0-alpha-dev (r10403) opening log file.
May 29 20:41:16.716 [err] Bug: routerlist.c:5179: routerlist_assert_ok: Assertion !memcmp(sd->extra_info_digest, d, DIGEST_LEN) failed; aborting.
Jun 01 17:06:20.127 [notice] Tor 0.2.0.1-alpha (r10442) opening log file.
Jun 01 17:07:00.140 [err] Bug: routerlist.c:5179: routerlist_assert_ok: Assertion !memcmp(sd->extra_info_digest, d, DIGEST_LEN) failed; aborting.
Jun 01 17:51:49.405 [notice] Tor 0.2.0.1-alpha (r10442) opening log file.
Jun 01 17:52:31.211 [err] Bug: routerlist.c:5179: routerlist_assert_ok: Assertion !memcmp(sd->extra_info_digest, d, DIGEST_LEN) failed; aborting.
debug backtrace:
clarity 130 -> gdb /usr/local/bin/tor tor.core
GNU gdb 5.3nb1
Core was generated by `tor'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/pkg/lib/libz.so.1...done.
Loaded symbols for /usr/pkg/lib/libz.so.1
Reading symbols from /usr/pkg/lib/libevent-1.3b.so.1...done.
Loaded symbols for /usr/pkg/lib/libevent-1.3b.so.1
Reading symbols from /usr/lib/libssl.so.3...done.
Loaded symbols for /usr/lib/libssl.so.3
Reading symbols from /usr/lib/libcrypto.so.2...done.
Loaded symbols for /usr/lib/libcrypto.so.2
Reading symbols from /usr/lib/libpthread.so.0...done.
Loaded symbols for /usr/lib/libpthread.so.0
Reading symbols from /usr/lib/libc.so.12...done.
Loaded symbols for /usr/lib/libc.so.12
Reading symbols from /lib/libcrypt.so.0...done.
Loaded symbols for /lib/libcrypt.so.0
Reading symbols from /usr/libexec/ld.elf_so...done.
Loaded symbols for /usr/libexec/ld.elf_so
#0 0xbd9f40fb in kill () from /usr/lib/libc.so.12
(gdb) bt
#0 0xbd9f40fb in kill () from /usr/lib/libc.so.12
#1 0xbda7517f in abort () from /usr/lib/libc.so.12
#2 0x080a0764 in routerlist_assert_ok (rl=0x8116240) at routerlist.c:5160
#3 0x0809bd10 in routerlist_remove_old_routers () at routerlist.c:2670
#4 0x0809fbfd in update_router_have_minimum_dir_info () at routerlist.c:4826
#5 0x0809fb5b in router_have_minimum_dir_info () at routerlist.c:4797
#6 0x080861a3 in directory_info_has_arrived (now=1180734750, from_cache=1)
at main.c:676
#7 0x08087211 in do_main_loop () at main.c:1345
#8 0x08087fed in tor_main (argc=7, argv=0xbfbfed1c) at main.c:2610
#9 0x080aa1bb in main (argc=7, argv=0xbfbfed1c) at tor_main.c:28
#10 0x0804ca66 in ___start ()
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: yancm
https://gitlab.torproject.org/legacy/trac/-/issues/443
niutil and nidump are no longer existant in 10.5 leopard, so you should use d...
2020-06-13T13:58:16Z
Trac
niutil and nidump are no longer existant in 10.5 leopard, so you should use dscl instead
as the niutil tool does not exist in osx 10.5 leopard installation of tor fails,
because the user _tor is not created.
instead of nidump you could maybe create the user via dscl
[Automatically added by flyspray2trac: Operating System...
as the niutil tool does not exist in osx 10.5 leopard installation of tor fails,
because the user _tor is not created.
instead of nidump you could maybe create the user via dscl
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: dave
0.1.2.15
Andrew Lewman
Andrew Lewman
https://gitlab.torproject.org/legacy/trac/-/issues/444
connecting to a hidden service port that does not exist kills existing connec...
2020-06-13T13:58:16Z
weasel (Peter Palfrader)
connecting to a hidden service port that does not exist kills existing connections
This is either a bug in the hidden service, or in the client code, I don't know which.
Symptoms: If you have a connection established to a hidden service on some port,
and then open a new connection to a port that it does not listen on...
This is either a bug in the hidden service, or in the client code, I don't know which.
Symptoms: If you have a connection established to a hidden service on some port,
and then open a new connection to a port that it does not listen on your already
existing connection is torn down.
e.g.:
socat TCP4-LISTEN:4242,fork SOCKS4A:localhost:37lnq2veifl4kar7.onion:6667,socksport=9050 &
telnet to localhost 4242, log on to IRC.
socat TCP4-LISTEN:4343,fork SOCKS4A:localhost:37lnq2veifl4kar7.onion:80,socksport=9050
telnet localhost 4343 -> irc connection dies.
[Automatically added by flyspray2trac: Operating System: All]
Roger Dingledine
Roger Dingledine
https://gitlab.torproject.org/legacy/trac/-/issues/445
tor-gencert should create files with proper permissions
2020-06-13T13:58:17Z
weasel (Peter Palfrader)
tor-gencert should create files with proper permissions
tor-gencert creates files with the default mode. It should probably ensure that the
private key files are created in such a way that they are not world or group readable
[Automatically added by flyspray2trac: Operating System: All]
tor-gencert creates files with the default mode. It should probably ensure that the
private key files are created in such a way that they are not world or group readable
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/446
we don't check which hop a cell is from well enough
2020-06-13T13:58:17Z
Roger Dingledine
we don't check which hop a cell is from well enough
If the streamid of one stream on our circuit collides with the streamid of another
stream (say, because they exit at different hops), this goes bad. There may also be
an attack here where intermediate hops can try to inject cells into st...
If the streamid of one stream on our circuit collides with the streamid of another
stream (say, because they exit at different hops), this goes bad. There may also be
an attack here where intermediate hops can try to inject cells into streams that
are supposed to be at different hops.
(Somebody should look at this harder before we blindly put the patch in.)
Patch from lodger:
--- relay.c Fri May 25 06:51:40 2007
+++ relay.c Tue Jun 5 07:30:38 2007
@@ -18,5 +18,5 @@
crypt_path_t **layer_hint, char *recognized);
static edge_connection_t *relay_lookup_conn(circuit_t *circ, cell_t *cell,
- int cell_direction);
+ int cell_direction, crypt_path_t *layer_hint);
static int
@@ -163,5 +163,6 @@
if (recognized) {
- edge_connection_t *conn = relay_lookup_conn(circ, cell, cell_direction);
+ edge_connection_t *conn = relay_lookup_conn(circ, cell, cell_direction,
+ layer_hint);
if (cell_direction == CELL_DIRECTION_OUT) {
++stats_n_relay_cells_delivered;
@@ -373,5 +374,6 @@
*/
static edge_connection_t *
-relay_lookup_conn(circuit_t *circ, cell_t *cell, int cell_direction)
+relay_lookup_conn(circuit_t *circ, cell_t *cell, int cell_direction,
+ crypt_path_t *layer_hint)
{
edge_connection_t *tmpconn;
@@ -391,5 +393,6 @@
tmpconn=tmpconn->next_stream) {
if (rh.stream_id == tmpconn->stream_id &&
- !tmpconn->_base.marked_for_close) {
+ !tmpconn->_base.marked_for_close &&
+ tmpconn->cpath_layer == layer_hint) {
log_debug(LD_APP,"found conn for stream %d.", rh.stream_id);
return tmpconn;
[Automatically added by flyspray2trac: Operating System: All]
Roger Dingledine
Roger Dingledine
https://gitlab.torproject.org/legacy/trac/-/issues/447
Directory information not kept up to date
2020-06-13T13:58:18Z
Trac
Directory information not kept up to date
Jun 05 23:14:10.928 [notice] Tor 0.1.2.14 opening log file.
Jun 05 23:14:11.096 [notice] Your Tor server's identity key fingerprint is 'dragon E710 B7B1 BCC6 5FEC E5BA 345C EC8B 81BE A216 318F'
Jun 05 23:14:11.526 [notice] I learned some...
Jun 05 23:14:10.928 [notice] Tor 0.1.2.14 opening log file.
Jun 05 23:14:11.096 [notice] Your Tor server's identity key fingerprint is 'dragon E710 B7B1 BCC6 5FEC E5BA 345C EC8B 81BE A216 318F'
Jun 05 23:14:11.526 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:14:15.555 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jun 05 23:14:24.607 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:14:54.738 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:03.791 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:08.821 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:09.798 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:09.805 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:13.852 [notice] We now have enough directory information to build circuits.
Jun 05 23:15:18.839 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jun 05 23:15:40.795 [notice] Performing bandwidth self-test...done.
Jun 07 19:51:15.879 [notice] Our directory information is no longer up-to-date enough to build circuits.
Jun 07 19:55:29.929 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 20:25:53.705 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 20:56:31.611 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 21:26:57.203 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 21:57:27.637 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 22:27:53.741 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 22:58:24.316 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:28:55.848 [notice] I learned some more directory information, but not enough to build a circuit.
It stays stuck here until I poke it:
Jun 07 23:51:32.901 [notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
Jun 07 23:51:46.292 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:52:17.430 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:52:31.504 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:52:32.514 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:52:33.512 [notice] We now have enough directory information to build circuits.
Restarting works too. The time delay is usually about the same, just under 2 days. I don't know when this started happening, so I can't tell you if it's due to 0.1.2.14 or not.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: taral
0.2.1.x-final
https://gitlab.torproject.org/legacy/trac/-/issues/448
We discard old guards before getting new networkstatuses
2020-06-13T13:58:18Z
Roger Dingledine
We discard old guards before getting new networkstatuses
Jun 09 01:23:05.146 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "moria1" at 128.31.0.34:9031 (published 2007-05-09 06:
29:03)
Jun 09 01:23:05.174 [info] networkstatus_list_update_recent(): Netw...
Jun 09 01:23:05.146 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "moria1" at 128.31.0.34:9031 (published 2007-05-09 06:
29:03)
Jun 09 01:23:05.174 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "moria1" at 128.31.0.34:9031 (published 2007-05-09 06:29:03)
is now "recent"
Jun 09 01:23:05.189 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "tor26" at 86.59.21.38:80 (published 2007-05-09 06:26:
56)
Jun 09 01:23:05.217 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "tor26" at 86.59.21.38:80 (published 2007-05-09 06:26:56) is
now "recent"
Jun 09 01:23:05.232 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "dizum" at 194.109.206.212:80 (published 2007-05-09 06
:27:03)
Jun 09 01:23:05.261 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "dizum" at 194.109.206.212:80 (published 2007-05-09 06:27:03)
is now "recent"
Jun 09 01:23:05.276 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "moria2" at 128.31.0.34:9032 (published 2007-05-09 06:
27:13)
Jun 09 01:23:05.304 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "moria2" at 128.31.0.34:9032 (published 2007-05-09 06:27:13)
is now "recent"
Jun 09 01:23:05.304 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "tor26" at 86.59.21.38:80 (published 2007-05-09 06:26:56) is
no longer "recent"
Jun 09 01:23:05.319 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "lefkada" at 140.247.60.64:80 (published 2007-05-09 06
:27:01)
Jun 09 01:23:05.348 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/847B1F850344D7876491A54892F904934E4EB85D
Jun 09 01:23:05.348 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/FFCB46DB1339DA84674C70D7CB586434C4370441
Jun 09 01:23:05.349 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/719BE45DE224B607C53707D0E2143E2D423E74CF
Jun 09 01:23:05.349 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/7EA6EAD6FD83083C538F44038BBFA077587DD755
Jun 09 01:23:05.349 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/38D4F5FCF7B1023228B895EA56EDE7D5CCDCAF32
Jun 09 01:23:05.350 [info] routerstatus_list_update_from_networkstatus(): Not en
ough statuses to update router status list. (0/5)
Jun 09 01:23:05.350 [info] entry_guards_compute_status(): Summary: Entry 'h76066
2' is reachable, unusable and not live.
Jun 09 01:23:05.350 [info] remove_dead_entries(): Entry guard 'h760662' (554EC78
2556A47590FB5B4DEFF56A5B52DB9CD59) has been down or unlisted since 2007-05-08 05
:39:00 local time; removing.
The problem is that routers_update_all_from_networkstatus() calls
entry_guards_compute_status() even if there aren't enough statuses
around yet.
[Automatically added by flyspray2trac: Operating System: All]
0.2.0.x-final
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/legacy/trac/-/issues/449
dns failures prevent legitimate options being set
2020-06-13T13:58:19Z
Robert Hogan
dns failures prevent legitimate options being set
Outright hostname lookup failures for previously configured hidden services prevent other options being set
while DNS is down.
For example, I configure a hidden service redirecting to google.com while DNS is working. DNS subsequently s...
Outright hostname lookup failures for previously configured hidden services prevent other options being set
while DNS is down.
For example, I configure a hidden service redirecting to google.com while DNS is working. DNS subsequently stops working,
e.g. nameserver becomes completely unreachable. If I then attempt to set a config option using the controller, it will
not get set as long as tor cannot resolve the hidden service name.
Rejection of hidden service configurations (and hence any subsequent or unrelated config change) made while tor is running
needs to be more tolerant of lookup failures.
The following attempts to validate the hidden service config currently in use (and previously validated when DNS was working).
If the validation fails, it must be because DNS is down, so the existing config is retained. If the user was attempting to add
a new hidden service config, then it doesn't get added.
```
Index: src/or/config.c
===================================================================
--- src/or/config.c (revision 10545)
+++ src/or/config.c (working copy)
@@ -963,10 +963,15 @@
}
}
- if (running_tor && rend_config_services(options, 0)<0) {
- log_warn(LD_BUG,
- "Previously validated hidden services line could not be added!");
- return -1;
+ if (running_tor && rend_config_services(options, 1)<0) {
+ log_warn(LD_CONFIG,
+ "Previously validated hidden services line no longer valid! Retaining existing hidden services config if there is one.");
+ }else{
+ if (rend_config_services(options, 0)<0){
+ log_warn(LD_BUG,
+ "Previously validated hidden services line could not be added!");
+ return -1;
+ }
}
if (running_tor) {
@@ -2920,9 +2925,10 @@
}
}
+/*
if (rend_config_services(options, 1) < 0)
REJECT("Failed to configure rendezvous options. See logs for details.");
-
+*/
if (parse_virtual_addr_network(options->VirtualAddrNetwork, 1, NULL)<0)
return -1;
```
[Automatically added by flyspray2trac: Operating System: All]
Tor: unspecified
https://gitlab.torproject.org/legacy/trac/-/issues/450
routerlist_assert_ok: Assertion !memcmp(r->cache_info.identity_digest, d, DIG...
2020-06-13T13:58:20Z
weasel (Peter Palfrader)
routerlist_assert_ok: Assertion !memcmp(r->cache_info.identity_digest, d, DIGEST_LEN) failed
* r10564
Jun 13 05:41:37.038 [err] Bug: routerlist.c:5197: routerlist_assert_ok: Assertion !memcmp(r->cache_info.identity_digest, d, DIGEST_LEN) failed; aborting.
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d2a885 in raise () from ...
* r10564
Jun 13 05:41:37.038 [err] Bug: routerlist.c:5197: routerlist_assert_ok: Assertion !memcmp(r->cache_info.identity_digest, d, DIGEST_LEN) failed; aborting.
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d2a885 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d2c002 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x080c6b92 in routerlist_assert_ok (rl=0x8167808) at routerlist.c:5197
#4 0x080be709 in routerlist_remove (rl=0x8167808, ri=0x86344e0, idx=52, make_old=1) at routerlist.c:2064
#5 0x080c04c2 in routerlist_remove_old_routers () at routerlist.c:2679
#6 0x080c5756 in update_router_have_minimum_dir_info () at routerlist.c:4858
#7 0x080c56f0 in router_have_minimum_dir_info () at routerlist.c:4829
#8 0x080a2329 in run_scheduled_events (now=1181706097) at main.c:1024
#9 0x080a274d in second_elapsed_callback (fd=-1, event=1, args=0x0) at main.c:1163
(gdb)
#3 0x080c6b92 in routerlist_assert_ok (rl=0x8167808) at routerlist.c:5197
5197 tor_assert(!memcmp(r->cache_info.identity_digest, d, DIGEST_LEN));
(gdb) p r
$1 = (routerinfo_t *) 0x86344e0
(gdb) p iter
$2 = (digestmap_iter_t *) 0x85b8524
(gdb) p d
$3 = 0x8b9f4bc "nzxß\235\035/W\b5ë£\222bàwñä\016½("
(gdb) p *r
$4 = {cache_info = {signed_descriptor_body = 0x86340e8 "(", signed_descriptor_len = 3085125992, signed_descriptor_digest = 'M' <repeats 20 times>,
identity_digest = 'M' <repeats 20 times>, published_on = 1296911693, extra_info_digest = 'M' <repeats 20 times>, ei_dl_status = {next_attempt_at = 1296911693,
n_download_failures = 77 'M'}, saved_location = 1296911693, saved_offset = 5570193308531903821, do_not_cache = 1, is_extrainfo = 0},
address = 0x4d4d4d4d <Address 0x4d4d4d4d out of bounds>, nickname = 0x4d4d4d4d <Address 0x4d4d4d4d out of bounds>, addr = 1296911693, or_port = 19789,
dir_port = 19789, onion_pkey = 0x4d4d4d4d, identity_pkey = 0x4d4d4d4d, platform = 0x4d4d4d4d <Address 0x4d4d4d4d out of bounds>, bandwidthrate = 1296911693,
bandwidthburst = 1296911693, bandwidthcapacity = 1296911693, exit_policy = 0x4d4d4d4d, uptime = 1296911693, declared_family = 0x4d4d4d4d,
contact_info = 0x4d4d4d4d <Address 0x4d4d4d4d out of bounds>, is_hibernating = 1, has_old_dnsworkers = 0, caches_extra_info = 1, is_running = 1, is_valid = 0,
is_named = 0, is_fast = 1, is_stable = 0, is_possible_guard = 1, is_exit = 0, is_bad_exit = 1, purpose = 77 'M', last_reachable = 1296911693,
testing_since = 1296911693, num_unreachable_notifications = 1296911693, routerlist_index = 176}
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/451
Bug: main.c:367: connection_stop_writing: Assertion conn->write_event failed;...
2020-06-13T13:58:24Z
weasel (Peter Palfrader)
Bug: main.c:367: connection_stop_writing: Assertion conn->write_event failed; aborting
On tor26, after running for about 2 weeks, I get:
[err] Bug: main.c:367: connection_stop_writing: Assertion conn->write_event failed; aborting.
tor26 is:
* r10579
-O0
../../patch-debian-rules-DDEBUG_ROUTERLIST+INSTRUMENTDOWNLOADS...
On tor26, after running for about 2 weeks, I get:
[err] Bug: main.c:367: connection_stop_writing: Assertion conn->write_event failed; aborting.
tor26 is:
* r10579
-O0
../../patch-debian-rules-DDEBUG_ROUTERLIST+INSTRUMENTDOWNLOADS
../../patch-tor-docs
../../patch-routerlist--two-asserts # just assert pointers added to the rl->routers list are even (%2==0)
../../patch-routerlist--shouldrebuildstore # rebuild store iff stats->journal_len > (5000)
../../patch-routerlist--writeoutforeach # in routerlist_assert_ok write out the first instance of the SMARTLIST_FOREACH makro
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d04885 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d06002 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x080a0c0f in connection_stop_writing (conn=0xed58948) at main.c:367
#4 0x0807b8f4 in connection_or_finished_flushing (conn=0xed58948) at connection_or.c:283
#5 0x08071afe in connection_finished_flushing (conn=0xed58948) at connection.c:2601
#6 0x08070ad1 in connection_handle_write (conn=0xed58948, force=0) at connection.c:2144
#7 0x080a14a5 in conn_write_callback (fd=241, events=4, _conn=0xed58948) at main.c:525
(gdb) p *conn
$1 = {magic = 2100428547, type = 4 '\004', state = 5 '\005', purpose = 0 '\0',
read_blocked_on_bw = 0, write_blocked_on_bw = 0,
hold_open_until_flushed = 0, inbuf_reached_eof = 0, edge_has_sent_end = 0,
edge_blocked_on_circ = 0, or_is_obsolete = 0, chosen_exit_optional = 0,
s = -1, conn_array_index = 561, read_event = 0x0, write_event = 0x0,
inbuf = 0xae38088, outbuf = 0xa0ee8a0, outbuf_flushlen = 0,
timestamp_lastread = 1182903016, timestamp_lastwritten = 1182903023,
timestamp_created = 1182869105, socket_family = 2, addr = 2331677697,
port = 41178, marked_for_close = 2087,
marked_for_close_file = 0x80fb026 "connection.c",
address = 0x8c44208 "138.250.148.1", linked_conn = 0x0, linked = 0,
reading_from_linked_conn = 0, writing_to_linked_conn = 0,
active_on_link = 0, dns_server_port = 0x0}
Let me know if there's any more info you might want to have.
[Automatically added by flyspray2trac: Operating System: All]
0.2.0.x-final
https://gitlab.torproject.org/legacy/trac/-/issues/452
libevent call with win32 failed: No buffer space available [WSAENOBUFS ] [10055]
2020-06-13T13:58:24Z
Trac
libevent call with win32 failed: No buffer space available [WSAENOBUFS ] [10055]
This is occurring frequently, It stops tor server.
jun 30 13:39:03.011 [Fout] libevent call with win32 failed: No buffer space available [WSAENOBUFS ] [10055]
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**T...
This is occurring frequently, It stops tor server.
jun 30 13:39:03.011 [Fout] libevent call with win32 failed: No buffer space available [WSAENOBUFS ] [10055]
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: pjzzz
https://gitlab.torproject.org/legacy/trac/-/issues/453
main.c:367 connection_stop_writing
2020-06-13T13:58:24Z
Trac
main.c:367 connection_stop_writing
My server has been running for weeks fine and it ended recently with the following error: ERR: main.c:367 connection_stop_writing.
I will reply to this message if it happens again. I will also enable error logs this time for more details...
My server has been running for weeks fine and it ended recently with the following error: ERR: main.c:367 connection_stop_writing.
I will reply to this message if it happens again. I will also enable error logs this time for more details.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: johndoe32102002
https://gitlab.torproject.org/legacy/trac/-/issues/454
streams never reaching SocksTimeout
2020-06-13T13:58:25Z
Roger Dingledine
streams never reaching SocksTimeout
Reported by lodger:
<lodger> arma: i found the endless attempt to change circuit at
connection_edge.c; connection_ap_expire_beginning(); There is no limit to the
number of attempts to replace circuit, if the expectation it is more than ...
Reported by lodger:
<lodger> arma: i found the endless attempt to change circuit at
connection_edge.c; connection_ap_expire_beginning(); There is no limit to the
number of attempts to replace circuit, if the expectation it is more than 15
seconds of answer to cell RELAY_COMAND_BEGIN. If the application of user does
not have a time out of expectation, and the process of constructing the new
circuits is always successful, but the address inquired by user is not
accessible, then the process of changing
the circuits is infinite.
<lodger> hang up on the stream after only if no new circuit
> see connection_ap_handshake_attach_circuit() in circuituse.c
> hm. or maybe not that. hang on. :)
> hm. that was where it used to be. it appears to be in
+connection_ap_expire_beginning() now, you're right.
> i wonder why the timeout got moved from attach-circuit to expire-beginning.
> probably because not everything was hitting attach-circuit. e.g. controller
connections don't.
> but maybe we should put a check in both places?
> lodger: have you actually experienced this, or you just think it might
happen?
<lodger> i have that situation in practice
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/455
tor segfaults on 64k-aligned cached-routers file
2020-06-13T13:58:26Z
Trac
tor segfaults on 64k-aligned cached-routers file
This bug is for svn and the 0.1.2.x tree, which are both affected.
When Tor gets to the end of an 4k-aligned file (page size?), it segfaults in eat_whitespace()
The problem is imminent at routerparse.c:899 when both end and eos are out...
This bug is for svn and the 0.1.2.x tree, which are both affected.
When Tor gets to the end of an 4k-aligned file (page size?), it segfaults in eat_whitespace()
The problem is imminent at routerparse.c:899 when both end and eos are out of bounds. (eos is (always?) out of bounds when the mmap is page-aligned.)
Execution then enters router_parse_entry_from_string(), which calls tokenize_string(s, end...) with end out of bounds. That calls eat_whitespace, which is not safe for non-null-terminated strings (as it has no end pointer or length specifier).
Steps to reproduce:
1. minimal torrc with RunAsDaemon 0, DataDirectory /some/path/ which points to...
2. A valid 4096-byte (I've only tested with 2!^x * 4096-byte files) cached-routers file (below, or take an existing cached-routers file and chop it, then duplicate/remove/modify exit policy entries until you get to an appropriate size)
I've collected sample cached-routers files of the obvious sizes that seems to trigger the bug on both my x86 and x86-64 machines.
http://70.242.110.86/svn/cr/
The crashes I get are in eat_whitespace(), but the original reporter on IRC was seeing segfaults in 0.1.2.14, routerparse.c:679 -- on PPC.
A representative backtrace from his PPC is at http://www.pastebin.ca/608408
One with a segfault in eat_whitespace (on x86-64) is at http://www.pastebin.ca/608454
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: croup
https://gitlab.torproject.org/legacy/trac/-/issues/456
sometimes dir mirrors answer 503 busy when they should say 404
2020-06-13T13:58:27Z
Roger Dingledine
sometimes dir mirrors answer 503 busy when they should say 404
In dirserv_estimate_data_size() we estimate the size assuming we have a descriptor
for every server we're asked about. This results in cases like
Jul 12 20:03:56.471 [info] connection_dir_client_reached_eof(): Received http status code ...
In dirserv_estimate_data_size() we estimate the size assuming we have a descriptor
for every server we're asked about. This results in cases like
Jul 12 20:03:56.471 [info] connection_dir_client_reached_eof(): Received http status code 404 ("Servers unavailable") from server '161.53.160.104:9091' while fetching "/tor/server/d/15EB28E14A7983129CD78FC6DEA20FD21098A7EF+161342319749ADD4116CE0427DB328F5C4BE1629+165BAFDA7253DFEC1DE0A3C548F21DDEAEF52F9E+1692BCEEC6431120B7AEC3A1685C8FD0EEC5F5A9+16D6BEE79128246B32EE1C565B2C2DBCB9AB41D3+16E162BE70678D6BFD5CF63F86B9188FE771B31F+16E567D955496CA338D3432B097F157DF35DE8BC+1715CD5D98964C7E31B36B66C52E14DDA7816EA9+1723E44E2245391BEC1B483126B5FAA870444B7C+1731772EE54F2A51E6749F25F9EE6BFB65FB6858+1759016C497AC642B5A50130AFCCF1BB6B643A02+17AEAC0A87BB35E4F2EA041FDA24F5DBC3A792AB+17B881474EA0A2F64F989263A7AD30A0DCE6377D+183528CAC37D3FA3EF18281C948DD213CF08D087+184C7E375ACB1CC1AF908DD957A180C93AA4227E+1869C3BA669EF6264614A3888D5E9B43C5FE3884+1874E43C98993E8285DBC3752920D02C6C951663+18965516ED4CF01866788451421C9EDF1E6BD1AA+190A1DF5C543AC6BB9AB72FE8C4C7CDCAE86D2B0+197F9E91C8D2FED74C36FBD4DA00C5D632144468+19A126F8CC87F339F2B16A273F1CD0A247F2FA4A+19C704F44ECB6BF79170E09C634790B98C8D8544+19E487A6A3A272A04EF882FB07A2EE90895090CE+1A720FCD4A2849C83A2701CDD0D39D8FFD2E314D+1AA750EE5B7FED285F368B6FEB4428DF92C2BB31+1AB2DABF6007241131C5E443CDC60394761816AC+1AF2B7488D10BFDCFE6CA79D56FB83656F4ADC8D+1AF69AAD27DFB6AA63D1072FA5AED92B468540DE+1B6D306CA8E0C693FAD3FFAAFC59F653DEFB1491+1BA661163B8A14B9AFB98AA9D12B18A24CBE562A+1BC0D0980C5EB734AAD02B9E70CCFCC898CB315A+1BDDBDA5C4E6DB9B3443D979352A7BC9A9576FE1+1BE953E3BB58CE9B6EE261BF441C7F9B3BDA752D+1C0E414654093BA94EE84764C711449B0ED5704F+1C11365A76C3A583E708C040E6A3307F9043D02F+1C1CC7E04750FB2A0CADD6B2C70FFF50CC31C632+1C34CC4FEA875DBDDCF419DEB6A9DB48DDA652F9+1C7DFC2A6F38DC9EB1B3FCB6C2F865EBA6D19F74+1CB80E88CBE0573EE7E856797E0A7B32ECE7B4B7+1CF9F520154EA3C12A3AA42AE79C75F1DE4B6309+1D2BC778F1CEC8A37C33A6EE2897C7597B7CD526+1D878DC7566F10B8303138B36971023038F6F36C+1DB1A4D87A94E8CC2838C8E83F411A8CF5FBA0AC+1DC7FE119A441AFBD18E821B56CAB844278F8AF3+1DED6B4805370219D52E1C14C52092789C7EB8D7+1E33A33694596F3D6121C92FDA8882E2EC3A76C4+1E67F16C391DAFBD830049A379DD691EBC22E6B1+1ED62D8D7DA9F76501B7F95D9D7DD7E002F93640+1F35B4C9F94020AE9893C7358D9FA6D15A0B6807+1FCCEC0102ABE5A8BA18B4D34CBA3F3300FDE5AE+1FDE4FBC452C5D2BECEAF0B3CB15F644380D2A75+1FF2733FC1812FBAD51FEBBDE259B06BE0921A59+204697B4DF76664425ADB9F3F8D0B1A3591CA695+209F6EFEE6FDE553FEE8748FA5A7BA70964965F9+20AC0F4CFC447C4C9C18F42356104CABDFBD0D20+21036C9FF860815C8C043597B39BC80AE40A3560+212474B60CC275F91F716F89C5751E4BB7A78B5F+213E8B394E0590A9EC9360BB415867E00A1978E7+214AE65A8196F9C6EFC4765F0488A3CE7FBC433A+2172560E8EE391D29C5218446A242F822F1E1AE1+21743952EB0C848BE0D513926C989AA79EEAA0AC+21976CED8984D0099810A17793F49585C2BE5DD0+21A3E413C450399FD8AE5A7CEE3624DF7953DF54+21CE269692672D3FED7435B6F1F5D7BC22D334BC.z". I'll try again soon.
Jul 12 20:03:58.430 [info] connection_dir_client_reached_eof(): Received server info (size 0) from server '213.239.207.67:9032'
Jul 12 20:03:58.430 [info] connection_dir_client_reached_eof(): Received http status code 404 ("Servers unavailable") from server '213.239.207.67:9032' while fetching "/tor/server/d/9CE4717E88E096DF81C1C4FF04F9ECBEC7CD3A5B+9CF6B523BEDDAF0BB9E0365F235A30FE9B773481+9D1A6720FBD2A10956C0EC3F9906DB05F73BD0D4+9D6755D980C8A0FDE344C8D9DC075EFB55C1E65A+9D9674E83A649A5DB589467AE1BFC5D8C788344F+9DFE225679B7D8D1695E2F86EB9D5E25D8EBAB34+9E1B301AD61B971FE4014F90834D86167DB010CF+9E3C0B1343829809EEF2232B8F8A147DF40EB489+9E7D917BFA42EFA9A2FD520905662700FF39B6A9+9EFD73CEE0CF4DC558813599D6192FD493543894+9F0C194B70D97C3CDFFD8567054434BC58D241F4+9F37436BFE30729AE1C0F950F33BFC9111EA1C73+9F3E0FB041996920B40459961F195B5CD6399DC6+9FFCA011607CA2D04E5203DB9D0E81895F44C3F3+A0069CAD4ECA76DCB8A65665320DA7E17FFC93AD+A0133D0C1179A17FAC6C330012EAACE88CC611B9+A06385CA613FB0FCA712B7A5A2D2C5295AEBABAF+A09C82BE0551B262534A5E86343641B4D6773F85+A0AB774DE5543FBF9F9E79D6EA1EA7CF661E4461+A0AE08580B0169C82DB5D7D10FDC943BF8EEA7D3+A0C9E180FEAC7560B0560FAB88BF501C4714661A+A11B9D281FEA020597B0446248768F87D49EFE7A+A1841B8634E7766CD45119C907BF277C81C94FDB+A229B8C784C10932F5DD54F015E25D04730253EE+A23AB6FA0D08881A364E0E2CB881D7E3B805440F+A28055279C866549A1A0F51640D664D4A6FB3B41+A2BD80D6BD0E0805AEB05DF56178F0C158935A5C+A2C78532A2681EC56FCBE7E45C02353769BC1D95+A2D1067D7018B5EC457FFBF300F8829CB75031D2+A2E18660748CD4E2889655C13C515D2DDBC41256+A310436DD2C0BB21D0F1D821F25CF306C0BB8C37+A3329045F8D856CE1FC53318AF5078A36AD2012D+A3B99B3F0FD34C724249BD96D22B19402F3D028C+A419E8229A5DA157D2A08B76D29812B20E4F4433+A42CDE78731DB4732D4081737159F04945FE1AF2+A62B099009D02859F8B6CEAC9EC7593565B39E2A+A647325F16245859ABE97A91589550580719BEA1+A64CB0CF7D84039AC62B94727BF652204EC6816A+A695737A181822C144918FF5F4E9442EBB1A1249+A6CFCF877338AEF9423682989BE59A47910C9AFB+A6D5D4F300AEC3D2547A8087BECB2DC4BB7C3522+A705D5C1A04E02FEC2B9C65268B6066C53A95F3C+A723F2CCA05D6DBD26AD94C3A944E32BFDC78CDD+A72E0D5CA9E9EA457DA4FE59E94D0A9196F2C1E3+A74F5A31716382AA22CDBE96B5802527B5E4060E+A79F558B7A04CDCC76F3B9D7F57B12A49CEDC1E7+A7A114CFB2FD516205398920C8FC736305D8FE45+A828AB492F31A601136DD88EA4FAF313CB6B1A8A+A86240001CFD23E8501EB2CEE9B7E4FB0BE975DE+A8659A991509E1C2F26CB365184A106862A5060B+A878DCD037042319797E8017710138E835BE13BE+A886F2F8922803AD86242E20BDF17DA28A176791+A8DA069ABD97A98F4B842657D712E294648B6255+A8E6040879A14E6201D07DB10EE7AEBF1AC594C9+A9A306117B642E064D6065682325FAB355808904+A9B2472A36D800F37D31C7FCFDBA9625168CC6E1+AAEC2FDD441EC9AB9BF7C9F61B8E1C187A0643D7+AB03995964674450EC79D4A88E79898639780404+AB05341E510E4915874FF2C8A678B3FD0BE0EA7A+AB29C2B963427F98B18D4D8CA8927B671990AFDC+AB40DAFA0B6E91C114DBD9A6DEC69DF9A10C4D4A+ABBBE14C5B168675FE13B129B8B3076A0E1DFB59.z". I'll try again soon.
Jul 12 20:03:59.267 [info] connection_dir_client_reached_eof(): Received http status code 503 ("Directory busy, try again later") from server '70.84.114.153:9030'. I'll try again soon.
where the client is inefficient at realizing that it's asking for descriptors
that aren't available anywhere. If we estimated a bit better (by checking if we
have an answer at all), we could help clients react quicker. This would require
figuring out what descriptors we're being asked about, which means doing more
work before we decide whether to 503.
[Automatically added by flyspray2trac: Operating System: All]
0.2.0.x-final
https://gitlab.torproject.org/legacy/trac/-/issues/457
Cookies aren't cleared with some option combos
2007-07-15T20:43:03Z
Mike Perry
Cookies aren't cleared with some option combos
I am having another problem in that the
cookies are not cleared when I toggle the torbutton.
It was working fine for a while, but now I login to a site while
torbutton is off, obtain some cookies and toggle the torbutton. The
cookies re...
I am having another problem in that the
cookies are not cleared when I toggle the torbutton.
It was working fine for a while, but now I login to a site while
torbutton is off, obtain some cookies and toggle the torbutton. The
cookies remain. I tried disabling torbutton, exiting firefox and
reenabling it. It corrected itself, i.e. it was clearing the cookies
when it is toggled, but after a while it stopped clearing the cookies
again.
I am running Firefox 2.0.0.4 on XP Pro with all updates.
The current torbutton settings are:
Everything is ticked under Dynamic content tab
Everything is ticked under History tab
First option is selected under Cache tab
First option is selected under Cookies tab
Clear cookies during any browser shotdown is selected under Shutdown tab
Everything is ticked under Headers tab
[Automatically added by flyspray2trac: Operating System: All]
Mike Perry
Mike Perry
https://gitlab.torproject.org/legacy/trac/-/issues/458
router_add_to_routerlist returns >=0 but ri gets freed
2020-06-13T13:58:28Z
Roger Dingledine
router_add_to_routerlist returns >=0 but ri gets freed
Running r10828 inside valgrind:
==21699== Invalid read of size 1
==21699== at 0x80C6C2D: routerlist_descriptors_added (routerlist.c:2752)
==21699== by 0x80C7169: router_load_routers_from_string (routerlist.c:2870)
==21699== by ...
Running r10828 inside valgrind:
==21699== Invalid read of size 1
==21699== at 0x80C6C2D: routerlist_descriptors_added (routerlist.c:2752)
==21699== by 0x80C7169: router_load_routers_from_string (routerlist.c:2870)
==21699== by 0x80C077D: router_reload_router_list_impl (routerlist.c:566)
==21699== by 0x80C0818: router_reload_router_list (routerlist.c:594)
==21699== by 0x80A7A2E: do_main_loop (main.c:1330)
==21699== by 0x80A8F26: tor_main (main.c:2606)
==21699== by 0x80DD9D9: main (tor_main.c:28)
==21699== Address 0x51EC212 is 154 bytes inside a block of size 172 free'd
==21699== at 0x401CFA5: free (vg_replace_malloc.c:233)
==21699== by 0x80C3992: routerinfo_free (routerlist.c:1761)
==21699== by 0x80C51FF: routerlist_replace (routerlist.c:2195)
==21699== by 0x80C6053: router_add_to_routerlist (routerlist.c:2484)
==21699== by 0x80C712F: router_load_routers_from_string (routerlist.c:2841)
==21699== by 0x80C077D: router_reload_router_list_impl (routerlist.c:566)
==21699== by 0x80C0818: router_reload_router_list (routerlist.c:594)
==21699== by 0x80A7A2E: do_main_loop (main.c:1330)
==21699== by 0x80A8F26: tor_main (main.c:2606)
==21699== by 0x80DD9D9: main (tor_main.c:28)
I only notice this now because I recently changed the call to
control_event_descriptors_changed() so we also look at the ri's when
we're not listening for certain controller events -- see
routerlist_descriptors_added().
I notice there are a few other places that call router_add_to_routerlist()
and expect ri to be usable if it doesn't fail -- including in dirserv.c,
which might explain some of these "routerlist has a freed routerinfo" bugs
we keep seeing on authorities.
So the first question is: what's the chain of events that causes
router_add_to_routerlist() to return >=0 yet to free the routerinfo?
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/459
Torbutton should have 2 sets of proxy settings
2007-07-23T02:34:56Z
Mike Perry
Torbutton should have 2 sets of proxy settings
For users in an environment where their non-tor browsing also requires proxy settings, it would
be nice if Torbutton had a way to specify this so these users would not need to muck around with
switchproxy or other extensions that may o...
For users in an environment where their non-tor browsing also requires proxy settings, it would
be nice if Torbutton had a way to specify this so these users would not need to muck around with
switchproxy or other extensions that may or may not end up randomly getting their Tor state
confused.
I'm thinking the best way to do this is to divvy up the proxy settings box into two tabs, Tor
and Non-Tor.
Tentatively marking this as 1.2, since it probably is a popular feature and I'm not sure
if we break when used in conjunction SwitchProxy or not.
[Automatically added by flyspray2trac: Operating System: All]
1.2
https://gitlab.torproject.org/legacy/trac/-/issues/460
Date hooks fail for meta-refresh?
2020-06-12T23:21:30Z
Mike Perry
Date hooks fail for meta-refresh?
It is possible that some meta-refresh based logins are able to cause the date hooking code to
believe that the hooks ran where as in fact they did not. This seemed to happen on one login
to my google summer of code mentor account, which ...
It is possible that some meta-refresh based logins are able to cause the date hooking code to
believe that the hooks ran where as in fact they did not. This seemed to happen on one login
to my google summer of code mentor account, which sets the TZ cookie to the number of minutes
you are offset from UTC.
The problem is this is very difficult to reproduce. It is likely not just a meta-refresh login,
but also a race condition that depends on the speed at which the meta-refresh reloads the page..
I will be adding some code to double check both directions of date hooks for all LocationChange
progress events to detect this bug and at least alert the user somehow if its occurence is detected.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/461
Torbutton is too verbose
2007-09-17T08:15:16Z
Mike Perry
Torbutton is too verbose
The alpha version of Torbutton dumps the Javascript error console with tons of messages at
full verbosity by default. The release version should either have this disabled, or have a much
higher threshhold (see about:config extensions.to...
The alpha version of Torbutton dumps the Javascript error console with tons of messages at
full verbosity by default. The release version should either have this disabled, or have a much
higher threshhold (see about:config extensions.torbutton.loglevel).
All log messages need to be reviewed to ensure their severity levels are sane also..
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/462
Auto Tor Toggle
2020-06-12T23:32:48Z
Mike Perry
Auto Tor Toggle
It has been requested that Torbutton provide the ability to either turn tor on for urls with
a particular prefix (ie tor:// or tors://), or to add the ability to specify certain bookmarks
are Tor-only.
The latter feature seems much mo...
It has been requested that Torbutton provide the ability to either turn tor on for urls with
a particular prefix (ie tor:// or tors://), or to add the ability to specify certain bookmarks
are Tor-only.
The latter feature seems much more interesting, but I'm not sure if the bookmarks engine allows
you to add on extra fields. Perhaps both features need to be implemented in tandem, so users
can then just bookmark tor:// urls.
The extension possibly should ask for confirmation also. Not sure I like the idea of tor state
sometimes magically toggling on just because a website had an img src="tor://" in there or something.
[Automatically added by flyspray2trac: Operating System: All]
1.4
https://gitlab.torproject.org/legacy/trac/-/issues/463
[notice] dns_cancel_pending_resolve(): Bug: Address [scrubbed] is not pending...
2020-06-13T13:58:28Z
Trac
[notice] dns_cancel_pending_resolve(): Bug: Address [scrubbed] is not pending. Dropping.
Been getting a bunch of those messages in my server log.
They seem to occur an hour or two after startup, and then in small bunches.
I set logging to debug level. Here follow three of the errors in context;
i can send the full 80MB log...
Been getting a bunch of those messages in my server log.
They seem to occur an hour or two after startup, and then in small bunches.
I set logging to debug level. Here follow three of the errors in context;
i can send the full 80MB log file if anyone needs it:
Jul 16 06:26:43.325 [debug] connection_exit_begin_conn(): Creating new exit connection.
Jul 16 06:26:43.325 [debug] buf_get_initial_mem(): Got buf mem from 4096-byte freelist. Freelist has 84 entries.
Jul 16 06:26:43.325 [debug] buf_get_initial_mem(): Got buf mem from 4096-byte freelist. Freelist has 83 entries.
Jul 16 06:26:43.325 [debug] connection_exit_begin_conn(): about to start the dns_resolve().
Jul 16 06:26:43.325 [info] Rejecting invalid destination address [scrubbed]
Jul 16 06:26:43.325 [notice] dns_cancel_pending_resolve(): Bug: Address [scrubbed] is not pending. Dropping.
Jul 16 06:26:43.325 [debug] add_buf_mem_to_freelist(): Add buf mem to 4096-byte freelist. Freelist has 84 entries.
Jul 16 06:26:43.325 [debug] add_buf_mem_to_freelist(): Add buf mem to 4096-byte freelist. Freelist has 85 entries.
Jul 16 06:26:43.325 [debug] relay_send_command_from_edge(): delivering 3 cell backward.
Jul 16 06:26:43.326 [debug] append_cell_to_circuit_queue(): Made a circuit active.
Jul 16 06:26:43.326 [debug] append_cell_to_circuit_queue(): Primed a buffer.
Jul 16 06:26:43.326 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Jul 16 06:26:43.326 [debug] connection_or_flush_from_first_active_circuit(): Made a circuit inactive.
Jul 16 06:26:43.326 [debug] connection_or_process_cells_from_inbuf(): 138: starting, inbuf_datalen 15360 (0 pending in tls object).
Jul 16 06:26:43.326 [debug] circuit_receive_relay_cell(): Sending away from origin.
Jul 16 06:26:43.326 [debug] connection_edge_process_relay_cell(): Now seen 199320 relay cells here.
Jul 16 06:26:43.326 [debug] connection_exit_begin_conn(): Creating new exit connection.
Jul 16 06:26:43.326 [debug] buf_get_initial_mem(): Got buf mem from 4096-byte freelist. Freelist has 84 entries.
Jul 16 06:26:43.326 [debug] buf_get_initial_mem(): Got buf mem from 4096-byte freelist. Freelist has 83 entries.
Jul 16 06:26:43.326 [debug] connection_exit_begin_conn(): about to start the dns_resolve().
Jul 16 06:26:43.326 [info] Rejecting invalid destination address [scrubbed]
Jul 16 06:26:43.326 [notice] dns_cancel_pending_resolve(): Bug: Address [scrubbed] is not pending. Dropping.
Jul 16 06:26:43.326 [debug] add_buf_mem_to_freelist(): Add buf mem to 4096-byte freelist. Freelist has 84 entries.
Jul 16 06:26:43.326 [debug] add_buf_mem_to_freelist(): Add buf mem to 4096-byte freelist. Freelist has 85 entries.
Jul 16 06:26:43.326 [debug] relay_send_command_from_edge(): delivering 3 cell backward.
Jul 16 06:26:43.326 [debug] append_cell_to_circuit_queue(): Made a circuit active.
Jul 16 06:26:43.326 [debug] connection_or_process_cells_from_inbuf(): 138: starting, inbuf_datalen 14848 (0 pending in tls object).
Jul 16 06:26:43.327 [debug] circuit_receive_relay_cell(): Sending away from origin.
Jul 16 06:26:43.327 [debug] connection_edge_process_relay_cell(): Now seen 199321 relay cells here.
Jul 16 06:26:43.327 [debug] connection_exit_begin_conn(): Creating new exit connection.
Jul 16 06:26:43.327 [debug] buf_get_initial_mem(): Got buf mem from 4096-byte freelist. Freelist has 84 entries.
Jul 16 06:26:43.327 [debug] buf_get_initial_mem(): Got buf mem from 4096-byte freelist. Freelist has 83 entries.
Jul 16 06:26:43.327 [debug] connection_exit_begin_conn(): about to start the dns_resolve().
Jul 16 06:26:43.327 [info] Rejecting invalid destination address [scrubbed]
Jul 16 06:26:43.327 [notice] dns_cancel_pending_resolve(): Bug: Address [scrubbed] is not pending. Dropping.
OS/Distro:
Xubuntu 7.04 fresh install
Tor 0.2.0.2-alpha from Debian Etch distro install
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: keb
https://gitlab.torproject.org/legacy/trac/-/issues/464
Torbutton 115 issues
2007-07-19T14:21:59Z
Andrew Lewman
Torbutton 115 issues
When torbutton is enabled, I switch tabs between sites, images, or text, and firefox 2.0.0.4 on linux
pops up Alert box with the text "False win hooking. Please report bug+website."
I've tried uninstalling every other add-on except to...
When torbutton is enabled, I switch tabs between sites, images, or text, and firefox 2.0.0.4 on linux
pops up Alert box with the text "False win hooking. Please report bug+website."
I've tried uninstalling every other add-on except torbutton and the problem still occurs.
I've left torbutton configuration at the default.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/465
More fine-grained read/write control of formfills
2020-06-16T01:27:27Z
Mike Perry
More fine-grained read/write control of formfills
Right now, all formfill history is tied to the "block history writes" setting in Tor. If this
setting is enabled, it disables both read and write of forms/logins, since this is all that
about:config settings are able to do. More fine-g...
Right now, all formfill history is tied to the "block history writes" setting in Tor. If this
setting is enabled, it disables both read and write of forms/logins, since this is all that
about:config settings are able to do. More fine-grained control may be achieved by implementing
a ton of interfaces. Possibly all the ones at:
http://www.xulplanet.com/references/xpcomref/group_Formfillin.html and then a couple more.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/466
Torbutton should maybe strip node.exit from http headers
2007-07-23T02:31:12Z
Mike Perry
Torbutton should maybe strip node.exit from http headers
In order to not break node-side caches, transparent proxies and sensitive virtualhost setups,
torbutton should stirp out node.exit from the HTTP headers of requests. This is probably possible,
but I have no idea what interface it would ...
In order to not break node-side caches, transparent proxies and sensitive virtualhost setups,
torbutton should stirp out node.exit from the HTTP headers of requests. This is probably possible,
but I have no idea what interface it would be. Since polipo doesn't want to modify http headers,
and since they can't for ssl even if they wanted to, this probably falls in torbutton's lap. But
since privoxy does it currently, it is not a high priority item.
[Automatically added by flyspray2trac: Operating System: All]
1.4
https://gitlab.torproject.org/legacy/trac/-/issues/467
r10895 suicide strlcpy.c:56, circuitbuild.c:1757
2020-06-13T13:58:29Z
Trac
r10895 suicide strlcpy.c:56, circuitbuild.c:1757
Checked out revision 10895.
gdb /usr/bin/tor /var/lib/tor/core.17532
GNU gdb Red Hat Linux (6.3.0.0-1.143.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are...
Checked out revision 10895.
gdb /usr/bin/tor /var/lib/tor/core.17532
GNU gdb Red Hat Linux (6.3.0.0-1.143.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
Core was generated by `/usr/bin/tor -f /etc/tor/torrc --pidfile /var/run/tor/tor.pid --log notice file'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libevent-1.3b.so.1...Reading symbols from /usr/lib/debug/usr/lib/libevent-1.3b.so.1.0.3.debug...done.
done.
Loaded symbols for /usr/lib/libevent-1.3b.so.1
Reading symbols from /lib/libssl.so.4...done.
Loaded symbols for /lib/libssl.so.4
Reading symbols from /lib/libcrypto.so.4...done.
Loaded symbols for /lib/libcrypto.so.4
Reading symbols from /lib/tls/libpthread.so.0...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/tls/libc.so.6...btdone.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /usr/lib/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /lib/libcom_err.so.2...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libk5crypto.so.3...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_dns.so.2...done.
Loaded symbols for /lib/libnss_dns.so.2
#0 strlcpy (dst=0xa80aff0 "", src=0x0, siz=42) at strlcpy.c:56
56 s++;
(gdb) bt
#0 strlcpy (dst=0xa80aff0 "", src=0x0, siz=42) at strlcpy.c:56
#1 0x080529e0 in extend_info_alloc (nickname=0x0, digest=0x9f559b0 "��\224~\215e\004�\001", onion_key=0x9c01520, addr=176205808, port=0)
at circuitbuild.c:1743
#2 0x08052a3b in extend_info_from_router (r=0x9f55980) at circuitbuild.c:1757
#3 0x080543e1 in circuit_establish_circuit (purpose=Variable "purpose" is not available.
) at circuitbuild.c:1398
#4 0x08059bc1 in circuit_get_open_circ_or_launch (conn=0xa76bf68, desired_circuit_purpose=5 '\005', circp=0xbfe572d8) at circuituse.c:1074
#5 0x0805a663 in connection_ap_handshake_attach_circuit (conn=0xa76bf68) at circuituse.c:1284
#6 0x0806bb19 in connection_ap_attach_pending () at connection_edge.c:443
#7 0x08059554 in circuit_build_needed_circs (now=1185051593) at circuituse.c:454
#8 0x0808b34f in second_elapsed_callback (fd=-1, event=1, args=0x0) at main.c:1035
#9 0x0032e62d in event_base_loop (base=0x9c01520, flags=Variable "flags" is not available.
) at event.c:315
#10 0x0032e6e0 in event_loop (flags=176205808) at event.c:366
#11 0x0808c7d1 in tor_main (argc=15, argv=0xbfe57994) at main.c:1369
#12 0x080b0ac3 in main (argc=15, argv=0xbfe57994) at tor_main.c:28
(gdb)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: xiando
https://gitlab.torproject.org/legacy/trac/-/issues/468
Tor Server excessive ram usage
2020-06-13T13:58:30Z
Andrew Lewman
Tor Server excessive ram usage
A number of people on or-talk are reporting very high memory usage (512MB to 1GB) for their servers. This entry is
to track the issues and provide feedback to those experiencing the problem.
See http://archives.seul.org/or/talk/Jul-20...
A number of people on or-talk are reporting very high memory usage (512MB to 1GB) for their servers. This entry is
to track the issues and provide feedback to those experiencing the problem.
See http://archives.seul.org/or/talk/Jul-2007/msg00135.html for the start of the thread.
If you are experiencing this problem, please list your operating system (uname -rmpio), tor version, zlib version,
openssl version, exit server or not, and virtual/resident memory usage of Tor.
Thanks!
[Automatically added by flyspray2trac: Operating System: Other Linux]
post 0.2.0.x
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/legacy/trac/-/issues/469
please limit connections by client
2020-06-13T13:58:31Z
weasel (Peter Palfrader)
please limit connections by client
I just had 213.26.168.50 perform a denial of service against Tor26. It opened over
5000 connections to tor26, which not only ate a bit of CPU, but also used up all
available file descriptors, causing tor26 to drop new connections:
Jul 2...
I just had 213.26.168.50 perform a denial of service against Tor26. It opened over
5000 connections to tor26, which not only ate a bit of CPU, but also used up all
available file descriptors, causing tor26 to drop new connections:
Jul 23 13:26:11.701 [notice] accept failed: Too many open files. Dropping incoming connection.
Please implement some limit of connections per clients. There are a few other
minor abusers too, which probably means this also could use some thinking at
the client:
sudo netstat -na | grep 86.59.21.38 > 38
cat 38 | grep ESTABLISHED | awk '{print $5}' | sed -e 's/:.*//' | sort | uniq -c | sort -n | tail
[..]
11 61.60.x.y [slightly anonymized]
13 212.249.x.y
16 59.120.x.y
19 81.120.x.y
25 65.122.x.y
31 202.185.x.y
32 125.16.x.y
5649 213.26.x.y
cheers,
[Automatically added by flyspray2trac: Operating System: All]
Tor: unspecified
https://gitlab.torproject.org/legacy/trac/-/issues/470
segfault and Round-off error in computing bandwidth
2020-06-13T13:58:32Z
weasel (Peter Palfrader)
segfault and Round-off error in computing bandwidth
On tor26 on r10939:
Jul 27 03:05:49.897 [notice] We now have enough directory information to build circuits.
Jul 27 03:06:23.138 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server des...
On tor26 on r10939:
Jul 27 03:05:49.897 [notice] We now have enough directory information to build circuits.
Jul 27 03:06:23.138 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jul 27 03:06:23.923 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jul 27 03:06:27.332 [warn] smartlist_choose_by_bandwidth(): Bug: Round-off error in computing bandwidth had an effect on which router we chose. Please tell the developers.
[it also segfaults real soon after that, see bug #471]
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/471
segfault while choosing nodes
2020-06-13T13:58:35Z
weasel (Peter Palfrader)
segfault while choosing nodes
On tor26 on r10939 within seconds of starting Tor segfaults.
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 0xb7d992de in mallopt () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7...
On tor26 on r10939 within seconds of starting Tor segfaults.
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 0xb7d992de in mallopt () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7d98b1d in mallopt () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d9950a in mallopt () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7d98135 in realloc () from /lib/tls/i686/cmov/libc.so.6
#4 0x080c9fa8 in _tor_realloc (ptr=0x11, size=17) at util.c:149
#5 0x080d129e in smartlist_add (sl=0xb7e57f5c, element=0x15d2a318) at container.c:92
#6 0x08054501 in compute_preferred_testing_list (answer=0x9319d58 "") at circuitbuild.c:1533
#7 0x08054684 in choose_good_middle_server (purpose=17 '\021', state=0x8844378, head=0x8ee2b08, cur_len=0) at circuitbuild.c:1582
#8 0x08054ab4 in onion_extend_cpath (circ=0x87688e0) at circuitbuild.c:1693
#9 0x08051358 in onion_populate_cpath (circ=0x87688e0) at circuitbuild.c:269
#10 0x0805144c in circuit_establish_circuit (purpose=17 '\021', onehop_tunnel=17, exit=0x11, need_uptime=17, need_capacity=17, internal=17) at circuitbuild.c:315
#11 0x0805ca5e in circuit_launch_by_router (purpose=17 '\021', onehop_tunnel=17, exit=0x11, need_uptime=17, need_capacity=17, internal=17) at circuituse.c:809
#12 0x080ae71b in consider_testing_reachability (test_or=1, test_dir=1) at router.c:602
#13 0x08085b99 in connection_dir_client_reached_eof (conn=0x91f41e8) at directory.c:1306
#14 0x080865cf in connection_dir_reached_eof (conn=0x91f41e8) at directory.c:1476
#15 0x0806cd1c in connection_handle_read (conn=0x91f41e8) at connection.c:1817
#16 0x0809a779 in conn_read_callback (fd=1009, event=2, _conn=0x91f41e8) at main.c:498
#17 0xb7fa0c79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
#18 0xb7fa0f65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#19 0xb7fa0dcb in event_loop () from /usr/lib/libevent-1.1a.so.1
...
In this particular instance it had said 'smartlist_choose_by_bandwidth(): Bug:
Round-off error in computing bandwidth had an effect on which router we
chose.' (see bug #470) first, but it does not do this all the time.
After committing r1940 (the found=0 compile time warning), I got two different
backtraces:
(gdb) bt
#0 0xb7d372de in mallopt () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7d36b1d in mallopt () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d3750a in mallopt () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7d36135 in realloc () from /lib/tls/i686/cmov/libc.so.6
#4 0x080c9fb8 in _tor_realloc (ptr=0xb7df69e8, size=3084872168) at util.c:149
#5 0x080d12ae in smartlist_add (sl=0xb7df5f5c, element=0x2209b030) at container.c:92
#6 0x080b2ac0 in router_add_running_routers_to_smartlist (sl=0x875caa0, allow_invalid=0, need_uptime=1, need_capacity=1, need_guard=0) at routerlist.c:1103
#7 0x080b3232 in router_choose_random_node (preferred=0x0, excluded=0x0, excludedsmartlist=0x82cebe0, need_uptime=1, need_capacity=1, need_guard=0, allow_invalid=0, strict=0,
weight_for_exit=0) at routerlist.c:1412
#8 0x0805488b in choose_good_entry_server (purpose=5 '\005', state=0x87effa8) at circuitbuild.c:1642
#9 0x080549e5 in onion_extend_cpath (circ=0x85c2288) at circuitbuild.c:1689
#10 0x08051358 in onion_populate_cpath (circ=0x85c2288) at circuitbuild.c:269
#11 0x0805144c in circuit_establish_circuit (purpose=5 '\005', onehop_tunnel=-1210095128, exit=0xb7df69e8, need_uptime=-1210095128, need_capacity=-1210095128,
internal=-1210095128) at circuitbuild.c:315
#12 0x0805ca5e in circuit_launch_by_router (purpose=5 '\005', onehop_tunnel=-1210095128, exit=0xb7df69e8, need_uptime=-1210095128, need_capacity=-1210095128,
internal=-1210095128) at circuituse.c:809
#13 0x0805bebe in circuit_predict_and_launch_new () at circuituse.c:408
#14 0x0809ba11 in run_scheduled_events (now=1185498960) at main.c:1041
#15 0x0809bf03 in second_elapsed_callback (fd=-1, event=1, args=0x0) at main.c:1178
#16 0xb7f3ec79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
#17 0xb7f3ef65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#18 0xb7f3edcb in event_loop () from /usr/lib/libevent-1.1a.so.1
#19 0x0809c453 in do_main_loop () at main.c:1379
#20 0x0809d57d in tor_main (argc=-1210095128, argv=0xb7df69e8) at main.c:2622
#21 0x080c90fb in main (argc=-1210095128, argv=0xb7df69e8) at tor_main.c:28
and one with a broken stack frame:
(gdb) bt
#0 0xb7cc42de in mallopt () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7cc3b1d in mallopt () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7cc2e83 in malloc () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7dc648f in default_malloc_ex () from /usr/lib/i686/cmov/libcrypto.so.0.9.7
#4 0x000002c0 in ?? ()
#5 0x00000002 in ?? ()
#6 0xb7e93d24 in __JCR_LIST__ () from /usr/lib/i686/cmov/libcrypto.so.0.9.7
#7 0xb7dc60c3 in CRYPTO_malloc () from /usr/lib/i686/cmov/libcrypto.so.0.9.7
#8 0x000002c0 in ?? ()
[...]
#22 0x00000049 in ?? ()
#23 0xbfdf5fe8 in ?? ()
#24 0xb7cc2e83 in malloc () from /lib/tls/i686/cmov/libc.so.6
Previous frame inner to this frame (corrupt stack?)
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/472
space in SOURCE_ADDR in stream event
2020-06-13T13:58:35Z
Roger Dingledine
space in SOURCE_ADDR in stream event
650 STREAM 232 NEW 0 128.31.0.34.$4C17FB532E20B2A8AC199441ECD2B0177B39E4B1.exit:9009 SOURCE_ADDR=(local link):0
We don't quite define an Address as something that has no spaces in it, but
something may still be wrong here. :)
How / whe...
650 STREAM 232 NEW 0 128.31.0.34.$4C17FB532E20B2A8AC199441ECD2B0177B39E4B1.exit:9009 SOURCE_ADDR=(local link):0
We don't quite define an Address as something that has no spaces in it, but
something may still be wrong here. :)
How / whether to fix?
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/473
buffers.c:1606: assert_buf_ok: Assertion buf->cur < buf->mem+buf->len failed;...
2020-06-13T13:58:36Z
weasel (Peter Palfrader)
buffers.c:1606: assert_buf_ok: Assertion buf->cur < buf->mem+buf->len failed; aborting
on tor26, r11001, soon after starting:
Jul 31 04:21:03.510 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jul 31 04:21:06.991 [notice] Performing bandwidth self-test.....
on tor26, r11001, soon after starting:
Jul 31 04:21:03.510 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jul 31 04:21:06.991 [notice] Performing bandwidth self-test...done.
Jul 31 04:21:09.585 [notice] Rejected router descriptor or extra-info from 64.62.190.36.
Jul 31 04:21:41.598 [notice] Rejected router descriptor or extra-info from 86.59.21.38.
Jul 31 04:21:41.638 [warn] http status 400 ("Extrainfo published time did not match routerdesc") response from dirserver '86.59.21.38:80'. Please correct.
Jul 31 04:25:24.936 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Jul 31 04:29:18.359 [err] Bug: buffers.c:1606: assert_buf_ok: Assertion buf->cur < buf->mem+buf->len failed; aborting.
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d3f885 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d41002 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x0805038c in assert_buf_ok (buf=0x6) at buffers.c:1622
#4 0x080707ab in assert_connection_ok (conn=0xbea0da8, now=1185848958) at connection.c:2803
#5 0x0809bc09 in conn_write_callback (fd=372, events=4, _conn=0xbea0da8) at main.c:528
#6 0xb7f91c79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
#7 0xb7f91f65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#8 0xb7f91dcb in event_loop () from /usr/lib/libevent-1.1a.so.1
#9 0x0809d733 in do_main_loop () at main.c:1386
#10 0x0809e86d in tor_main (argc=0, argv=0x0) at main.c:2635
#11 0x080caa1b in main (argc=0, argv=0x0) at tor_main.c:28
#4 0x080707ab in assert_connection_ok (conn=0xbea0da8, now=1185848958) at connection.c:2803
2803 assert_buf_ok(conn->inbuf);
(gdb) p *conn
$1 = {magic = 2100428547, type = 4 '\004', state = 5 '\005', purpose = 0 '\0',
read_blocked_on_bw = 0, write_blocked_on_bw = 0,
hold_open_until_flushed = 0, inbuf_reached_eof = 0, edge_has_sent_end = 0,
edge_blocked_on_circ = 0, or_is_obsolete = 0, chosen_exit_optional = 0,
s = 372, conn_array_index = 260, read_event = 0x8796480,
write_event = 0x8796240, inbuf = 0x8795d68, outbuf = 0xb039370,
outbuf_flushlen = 512, timestamp_lastread = 1185848956,
timestamp_lastwritten = 1185848955, timestamp_created = 1185848571,
socket_family = 2, addr = 2620942612, port = 9001, marked_for_close = 0,
marked_for_close_file = 0x0, address = 0x9f00720 "156.56.105.20",
linked_conn = 0x0, linked = 0, reading_from_linked_conn = 0,
writing_to_linked_conn = 0, active_on_link = 0, dns_server_port = 0x0}
(gdb) p *conn->inbuf
$2 = {magic = 2969563922,
mem = 0x9ae7458 "[..cut by weasel...]",
cur = 0x9ae9458 "[..cut by weasel...] ", highwater = 0, len = 8192, memsize = 8192,
datalen = 0}
weasel@intrepid:~$ bc
ibase=16
9AE9458-9AE7458
8192
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/474
Disabling Tor makes Firefox save passwords
2007-08-02T10:42:04Z
Trac
Disabling Tor makes Firefox save passwords
My Firefox is configured to never save forms or passwords on any site.
After enabling Tor usage with Torbutton 1.1.6 everything is fine but after disabling Tor,
Firefox asks me whether to save a password on every login.
In the Firefox s...
My Firefox is configured to never save forms or passwords on any site.
After enabling Tor usage with Torbutton 1.1.6 everything is fine but after disabling Tor,
Firefox asks me whether to save a password on every login.
In the Firefox settings the options "Save passwords" and "Save data I enter on webpages" are both enabled.
I'm using Windows XP SP2 Pro (german) and Firefox 2.0.0.6
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: knappo
Mike Perry
Mike Perry
https://gitlab.torproject.org/legacy/trac/-/issues/475
version comparison
2020-06-13T13:58:37Z
weasel (Peter Palfrader)
version comparison
changed recommendedversions on tor26 to only recommend 0.1.2.16 and 0.2.0.4:
Fri 00:06:31 <weasel> it made tor's notice message change too:
Fri 00:06:41 <weasel> from: Aug 02 07:08:58.368 [notice] This version of Tor (0.2.0.3-alpha-dev)...
changed recommendedversions on tor26 to only recommend 0.1.2.16 and 0.2.0.4:
Fri 00:06:31 <weasel> it made tor's notice message change too:
Fri 00:06:41 <weasel> from: Aug 02 07:08:58.368 [notice] This version of Tor (0.2.0.3-alpha-dev) is newer than any recommended version, according to
3/3 version-listing network statuses. Versions recommended by more than 1 authority are: 0.1.1.26, 0.1.2.13, 0.1.2.14, 0.1.2.15,
0.2.0.2-alpha, 0.2.0.3-alpha
Fri 00:07:00 <weasel> to Aug 02 19:41:32.354 [warn] Please upgrade! This version of Tor (0.2.0.3-alpha-dev) is not recommended, according to 3/3
version-listing network statuses. Versions recommended by at least 1 authority are: 0.1.1.26, 0.1.2.13, 0.1.2.14, 0.1.2.15,
0.2.0.2-alpha, 0.2.0.3-alpha
Fri 00:07:22 <weasel> which was kinda funny. please upgrade: here is a list of older versions that are recommended
[Automatically added by flyspray2trac: Operating System: All]
0.2.0.x-final
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/legacy/trac/-/issues/476
Missing </a> on https://tor.eff.org/download.html
2020-06-13T17:18:15Z
Trac
Missing </a> on https://tor.eff.org/download.html
Line 115 on https://tor.eff.org/download.html (and translations) is missing an end tasg for A.
It should be:
<td><a href="download-windows.html.de">Downloadseite für Windows</a></td>
instead of:
<td><a href="download-windows.html.de"...
Line 115 on https://tor.eff.org/download.html (and translations) is missing an end tasg for A.
It should be:
<td><a href="download-windows.html.de">Downloadseite für Windows</a></td>
instead of:
<td><a href="download-windows.html.de">Downloadseite für Windows</td>
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Athaba
https://gitlab.torproject.org/legacy/trac/-/issues/477
tor.eff.org/documentation.html.de has a <li> instead of </li>
2020-06-13T17:18:15Z
Trac
tor.eff.org/documentation.html.de has a <li> instead of </li>
Line 165 of https://tor.eff.org/documentation.html.de:
mit der Information.<li>
should be:
mit der Information.</li>
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Athaba
Line 165 of https://tor.eff.org/documentation.html.de:
mit der Information.<li>
should be:
mit der Information.</li>
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Athaba
https://gitlab.torproject.org/legacy/trac/-/issues/478
Wrong SVN link in documentation.html.it
2020-06-13T17:18:16Z
Trac
Wrong SVN link in documentation.html.it
Line 183 of https://tor.eff.org/documentation.html.it:
<li><a href="<svnandbox>">SVN sandbox aggiornato regolarmente</a></li>
should be:
<li><a href="svn/trunk/">SVN sandbox aggiornato regolarmente/a></li>
[Automatically adde...
Line 183 of https://tor.eff.org/documentation.html.it:
<li><a href="<svnandbox>">SVN sandbox aggiornato regolarmente</a></li>
should be:
<li><a href="svn/trunk/">SVN sandbox aggiornato regolarmente/a></li>
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Athaba
https://gitlab.torproject.org/legacy/trac/-/issues/479
Errors in documentation.html.se
2020-06-13T17:18:16Z
Trac
Errors in documentation.html.se
There are errors in:
https://tor.eff.org/documentation.html.se
Line 113 and 114:
Se också <ahref="http://freehaven.net/~arma/slides-23c3.pdf">bilder</a> och
<ahref="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v">video</a>
...
There are errors in:
https://tor.eff.org/documentation.html.se
Line 113 and 114:
Se också <ahref="http://freehaven.net/~arma/slides-23c3.pdf">bilder</a> och
<ahref="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v">video</a>
should be:
Se också <a href="http://freehaven.net/~arma/slides-23c3.pdf">bilder</a> och
<a href="http://freehaven.net/~arma/23C3-1444-en-tor_and_china.m4v">video</a>
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Athaba
https://gitlab.torproject.org/legacy/trac/-/issues/480
Torbutton 1.1.6alpha doesnt work at all
2007-08-15T17:13:31Z
Trac
Torbutton 1.1.6alpha doesnt work at all
I love the security options/ideas, they are amazing, great work, for some reason this isnt working for
Swiftfox 2.0.0.6 and Firefox 2.0.0.6, it installs fine and runs fine without error but does not change
the settings to connect to Tor ...
I love the security options/ideas, they are amazing, great work, for some reason this isnt working for
Swiftfox 2.0.0.6 and Firefox 2.0.0.6, it installs fine and runs fine without error but does not change
the settings to connect to Tor and Privoxy, I have checked my settings and what ports I have tor and
privoxy installed and everything is set up correctly, also it just lets me connect to the internet
without going through tor/privoxy with it enabled and all ports specified
I am very interested/excited about this addon, im willing to help as much as I can,
let me know
defcon
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: defcon
https://gitlab.torproject.org/legacy/trac/-/issues/481
Tor server complains about too less directory information, even if we are a s...
2020-06-13T13:58:37Z
Trac
Tor server complains about too less directory information, even if we are a server
Tor server complains about too less directory information to build a circuit, even if we are a server.
It is possible that you over read real problems because of this.
[Automatically added by flyspray2trac: Operating System: All]
**Tra...
Tor server complains about too less directory information to build a circuit, even if we are a server.
It is possible that you over read real problems because of this.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Athaba
0.2.0.x-final
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/legacy/trac/-/issues/482
MSVC build failed since r10880
2020-06-13T13:58:38Z
Trac
MSVC build failed since r10880
MSVC build failed since r10880 because there's no s6_addr16 and s6_addr32 in MS Platform SDK.
structure details in MSDN:
http://msdn2.microsoft.com/en-us/library/ms738664.aspx
[Automatically added by flyspray2trac: Operating System: Wi...
MSVC build failed since r10880 because there's no s6_addr16 and s6_addr32 in MS Platform SDK.
structure details in MSDN:
http://msdn2.microsoft.com/en-us/library/ms738664.aspx
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: roytam1
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/legacy/trac/-/issues/483
Mac OS X connection.c:932
2020-06-13T13:58:38Z
Trac
Mac OS X connection.c:932
Here's the error from the log file.
I've only seen it once.
Aug 19 11:14:30.640 [Error] Bug: connection.c:932: connection_handle_listener_read: Assertion ((struct sockaddr*)addrbuf)->sa_family == conn->socket_family failed; aborting.
I...
Here's the error from the log file.
I've only seen it once.
Aug 19 11:14:30.640 [Error] Bug: connection.c:932: connection_handle_listener_read: Assertion ((struct sockaddr*)addrbuf)->sa_family == conn->socket_family failed; aborting.
It was preceded by quite a few of the following errors::
Aug 19 10:43:50.838 [Notice] dns_cancel_pending_resolve(): Bug: Address [scrubbed] is not pending (state 3). Dropping.
And quite possibly this was the start of the problems.
Aug 18 19:13:49.046 [Warning] eventdns: All nameservers have failed
Aug 18 19:13:51.912 [Notice] eventdns: Nameserver xxx.xxx.xxx.xxx is back up
Everything has been running smootly since.
I am running Tor 0.2.0.4-alpha (r11023)
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: user6362
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/legacy/trac/-/issues/484
not freeing an mmap
2020-06-13T13:58:38Z
Roger Dingledine
not freeing an mmap
==26396== 12 bytes in 1 blocks are definitely lost in loss record 4 of 10
==26396== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==26396== by 0x80E6C0C: _tor_malloc (util.c:119)
==26396== by 0x80E6C64: _tor_malloc_zero (util.c...
==26396== 12 bytes in 1 blocks are definitely lost in loss record 4 of 10
==26396== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==26396== by 0x80E6C0C: _tor_malloc (util.c:119)
==26396== by 0x80E6C64: _tor_malloc_zero (util.c:138)
==26396== by 0x80EDA36: tor_mmap_file (compat.c:172)
==26396== by 0x80C79E2: router_rebuild_store (routerlist.c:591)
==26396== by 0x80C7F88: router_reload_router_list_impl (routerlist.c:694)
==26396== by 0x80C7FCE: router_reload_router_list (routerlist.c:712)
==26396== by 0x80ADAE2: do_main_loop (main.c:1366)
==26396== by 0x80AF05A: tor_main (main.c:2660)
==26396== by 0x80E5C55: main (tor_main.c:28)
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/485
should catch socket errors
2007-08-28T20:02:58Z
weasel (Peter Palfrader)
should catch socket errors
Aug 22 10:09:51.031 +0200 [FATAL] Exception while running server
Aug 22 10:09:51.091 +0200 [FATAL] Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/mixminion/server/ServerMain.py", line 1214, in runServer
...
Aug 22 10:09:51.031 +0200 [FATAL] Exception while running server
Aug 22 10:09:51.091 +0200 [FATAL] Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/mixminion/server/ServerMain.py", line 1214, in runServer
server.run()
File "/usr/lib/python2.3/site-packages/mixminion/server/ServerMain.py", line 881, in run
self.mmtpServer.process(TICK_INTERVAL)
File "/usr/lib/python2.3/site-packages/mixminion/server/MMTPServer.py", line 824, in process
AsyncServer.process(self, timeout)
File "/usr/lib/python2.3/site-packages/mixminion/server/MMTPServer.py", line 234, in process
cap)
File "/usr/lib/python2.3/site-packages/mixminion/server/MMTPServer.py", line 325, in process
self.connectionFactory(con)
File "/usr/lib/python2.3/site-packages/mixminion/server/MMTPServer.py", line 660, in _newMMTPConnection
addr, port = sock.getpeername()
File "<string>", line 1, in getpeername
error: (107, 'Transport endpoint is not connected')
Aug 22 10:09:51.091 +0200 [FATAL] Shutting down because of exception: socket.error
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/legacy/trac/-/issues/486
Allow non-admin users to install OS-X
2009-01-06T17:28:50Z
Trac
Allow non-admin users to install OS-X
Most applications allow the option to install for current user or all users. I only install applications
as a non-admin user for security reasons. Would it be possible to all non-admin users to install vidalia?
[Automatically added by f...
Most applications allow the option to install for current user or all users. I only install applications
as a non-admin user for security reasons. Would it be possible to all non-admin users to install vidalia?
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: Dodger
0.2.1.x-final
Andrew Lewman
Andrew Lewman
https://gitlab.torproject.org/legacy/trac/-/issues/487
OSX Universal package includes PowerPC-only privoxy
2008-02-08T21:37:47Z
Trac
OSX Universal package includes PowerPC-only privoxy
If you install the universal binary version of the Tor package on Mac OS X, you end up running a PowerPC version of privoxy.
This has been the case for a while now, since I first started testing UB versions on the mac.
It can be confirme...
If you install the universal binary version of the Tor package on Mac OS X, you end up running a PowerPC version of privoxy.
This has been the case for a while now, since I first started testing UB versions on the mac.
It can be confirmed by running Activity Monitor and looking in the Kind column.
Also the 'file' command reports:
$ file /Library/Privoxy/privoxy
/Library/Privoxy/privoxy: Mach-O executable ppc
compare to the tor executable:
$ file /Library/Tor/tor
/Library/Tor/tor: Mach-O universal binary with 2 architectures
/Library/Tor/tor (for architecture i386): Mach-O executable i386
/Library/Tor/tor (for architecture ppc): Mach-O executable ppc
I have just installed 0.1.2.17 and confirmed that it is still the case.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: evansj
Andrew Lewman
Andrew Lewman
https://gitlab.torproject.org/legacy/trac/-/issues/488
Connection problems with Tor
2020-06-13T13:58:39Z
Trac
Connection problems with Tor
Aug 31 22:01:45.137 [Notice] Tor v0.1.2.16. This is experimental software. Do not rely on it for strong anonymity.
Aug 31 22:01:45.167 [Notice] Initialized libevent version 1.3b using method win32. Good.
Aug 31 22:01:45.177 [Notice] Open...
Aug 31 22:01:45.137 [Notice] Tor v0.1.2.16. This is experimental software. Do not rely on it for strong anonymity.
Aug 31 22:01:45.167 [Notice] Initialized libevent version 1.3b using method win32. Good.
Aug 31 22:01:45.177 [Notice] Opening Socks listener on 127.0.0.1:9050
Aug 31 22:01:45.177 [Notice] Opening Control listener on 127.0.0.1:9051
Aug 31 22:02:35.920 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
Aug 31 22:03:05.753 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
Aug 31 22:04:35.171 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:05:05.255 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:06:46.150 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
Aug 31 22:06:47.021 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
Aug 31 22:08:05.544 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:08:46.593 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:08:47.594 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:18:08.992 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:18:58.543 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
Aug 31 22:20:58.505 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:26:40.968 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
This is from vidalia message log. Before this i had the problem of tor crashing over and over again due to insufficient memory.
Frustrated, i reinstalled the entire vidalia bundle and this error popped out when i tried to use tor. Can you please help me? Thank you.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: watisit
Andrew Lewman
Andrew Lewman
https://gitlab.torproject.org/legacy/trac/-/issues/489
Torbutton 1.1.6 on Mac OS X triggers web page logging
2007-09-12T04:04:24Z
Trac
Torbutton 1.1.6 on Mac OS X triggers web page logging
Using Firefox 2.0.0.6 on a Mac with OS X 10.4.10 installed, the installation of Torbutton 1.1.6 with its default settings, appears to trigger the recording of complete web page listings within the Mac OS X Console Log: Library/logs/Conso...
Using Firefox 2.0.0.6 on a Mac with OS X 10.4.10 installed, the installation of Torbutton 1.1.6 with its default settings, appears to trigger the recording of complete web page listings within the Mac OS X Console Log: Library/logs/Console/501/console.log.
e.g
ContentLocation: http://bugs.noreply.org/flyspray/favicon.ico
ContentLocation: http://bugs.noreply.org/flyspray/themes/Bluey/theme.css
ContentLocation: http://bugs.noreply.org/flyspray/includes/functions.js
This behaviour occurs both when default settings for Firefox Preferences are used, and when Javascript, Java, History etc are all switched off within Firefox Preferences.
This behaviour does not occur whilst using the stable version of Torbutton 1.0.4.01.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: compton
1.1
Mike Perry
Mike Perry
https://gitlab.torproject.org/legacy/trac/-/issues/490
Additional headers for outgoing messages
2019-06-17T19:06:58Z
Trac
Additional headers for outgoing messages
For better acceptance with users mixminion should allow arbitrary headers in
outgoing messages, e.g. "Newsgroups" or "X-Hashcash" for posting to Newsgroups.
Exit remailer operators could then allow an arbitrary subset of those headers
an...
For better acceptance with users mixminion should allow arbitrary headers in
outgoing messages, e.g. "Newsgroups" or "X-Hashcash" for posting to Newsgroups.
Exit remailer operators could then allow an arbitrary subset of those headers
and discard the others.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: tcr
https://gitlab.torproject.org/legacy/trac/-/issues/491
Remove "BEGIN TYPE III" wrapping
2019-06-17T19:06:58Z
Trac
Remove "BEGIN TYPE III" wrapping
For increasing user acceptance outgoing mixminion messages should not be wrapped
with the "-----BEGIN TYPE III ANONYMOUS MESSAGE-----" type disclaimer, especially
as it munges PGP messages.
In my opinion this should definitely go away wi...
For increasing user acceptance outgoing mixminion messages should not be wrapped
with the "-----BEGIN TYPE III ANONYMOUS MESSAGE-----" type disclaimer, especially
as it munges PGP messages.
In my opinion this should definitely go away with the next version and not wait
until mixminion leaves alpha.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: tcr
https://gitlab.torproject.org/legacy/trac/-/issues/492
Generation of dummy messages
2019-06-17T19:06:58Z
Trac
Generation of dummy messages
For an increase in cover traffic mixminion should automatically generate
dummy messages, similar to mixmaster's INDUMMYP and OUTDUMMYP.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: tcr
For an increase in cover traffic mixminion should automatically generate
dummy messages, similar to mixmaster's INDUMMYP and OUTDUMMYP.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: tcr
https://gitlab.torproject.org/legacy/trac/-/issues/493
.exit TLD does not behave transparently
2020-06-13T13:58:39Z
Trac
.exit TLD does not behave transparently
The .exit TLD does not work like the ExitNodes config option. Whatever it does, it does not simply ask a particular exit node to cleanly request a particular URL.
For example, http://en.wikipedia.org.bostonucompsci.exit/ returns a very ...
The .exit TLD does not work like the ExitNodes config option. Whatever it does, it does not simply ask a particular exit node to cleanly request a particular URL.
For example, http://en.wikipedia.org.bostonucompsci.exit/ returns a very different result than http://en.wikipedia.org/ with a "ExitNodes bostonucompsci" config. I can't say why, but try it. Don't go asking the Wikipedia folks what the difference is; they'll just flip out and start blocking all the newer nodes again.
I chose that exit node because it's running 0.1.2.17, but any node will give the same results, including those running 0.2.0.6-alpha. I'm running 0.1.2.17 on win2k.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Dodger
https://gitlab.torproject.org/legacy/trac/-/issues/494
Toggle JavaScript?
2020-06-13T00:12:09Z
Trac
Toggle JavaScript?
Bonne soirée,
Is there a reason you choose not to toggle JavaScript along with Java when Tor is in use?
It was my understanding that JavaScript can comprise anonymity just like Java. Presently
I toggle JavaScript manually but I would ...
Bonne soirée,
Is there a reason you choose not to toggle JavaScript along with Java when Tor is in use?
It was my understanding that JavaScript can comprise anonymity just like Java. Presently
I toggle JavaScript manually but I would like to see this feature in TorButton. New users
and those unaware of JavaScript dangers may not manually toggle JavaScript to their detriment.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Sid
https://gitlab.torproject.org/legacy/trac/-/issues/495
Memory leaks in torbutton
2007-09-12T04:31:48Z
Trac
Memory leaks in torbutton
Hi,
I noticed some memory leaks in torbutton.
So, I tested with development branch, and they were still here. Those leaks come
from pref observer not being removed during window unloading. When you use
just one window, that's not a big...
Hi,
I noticed some memory leaks in torbutton.
So, I tested with development branch, and they were still here. Those leaks come
from pref observer not being removed during window unloading. When you use
just one window, that's not a big deal, but if you use multiple, some
javascripts objects are leaked each time.
Here is a patch to apply against last version
(http://torbutton.torproject.org/dev/torbutton-current-alpha.xpi 1.1.6 30 Jul 2007)
PS: I noticed those leaks with leak monitor, a nice tool for xul developers:
http://dbaron.org/mozilla/leak-monitor/
--- torbutton.js 2007-09-06 23:29:18.000000000 +0200
+++ /home/arno/.mozilla/firefox/qrp98gfd.tes/extensions/{e0204bd5-9d31-402b-a99d-a6aa8ffebdca}/chrome/content/torbutton.js 2007-09-06 23:31:59.000000000 +0200
@@ -20,7 +20,7 @@
unregister: function()
{
if (!this._branch) return;
- this._branch.removeOberver("", this);
+ this._branch.removeObserver("", this);
},
// topic: what event occurred
@@ -838,6 +838,10 @@
Components.interfaces.nsIWebProgress.NOTIFY_LOCATION);
}
+function torbutton_close_window(event) {
+ torbutton_pref_observer.unregister();
+}
+
// Technique courtesy of:
// http://xulsolutions.blogspot.com/2006/07/creating-uninstall-script-for.html
const TORBUTTON_EXTENSION_UUID = "{E0204BD5-9D31-402B-A99D-A6AA8FFEBDCA}";
@@ -884,6 +888,7 @@
}
window.addEventListener('load',torbutton_new_window,false);
+window.addEventListener('unload', torbutton_close_window, false);
getBrowser().addEventListener("TabOpen", torbutton_new_tab, false);
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: arno
Mike Perry
Mike Perry
https://gitlab.torproject.org/legacy/trac/-/issues/496
Tor Button 1.1.6 uses http (not https) and does not work on Firefox 3 trunk b...
2007-09-17T08:14:28Z
Trac
Tor Button 1.1.6 uses http (not https) and does not work on Firefox 3 trunk builds
Firefox 3 requires that add-ons update and install via https. Because of this, Tor Button cannot be
installed on the Firefox 3 trunk builds. The Update url in install.rdf is http.
[Automatically added by flyspray2trac: Operating System:...
Firefox 3 requires that add-ons update and install via https. Because of this, Tor Button cannot be
installed on the Firefox 3 trunk builds. The Update url in install.rdf is http.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: albill
https://gitlab.torproject.org/legacy/trac/-/issues/497
exception in torbutton_restore_nontor_settings
2007-09-12T04:31:15Z
Trac
exception in torbutton_restore_nontor_settings
Hi
when you disable or remove torbutton, and therefore, torbutton_restore_nontor_settings throws in exception and therefore, this.unregister is not called (in torbutton_uninstall_observer object).
exception is triggered by line:
sav...
Hi
when you disable or remove torbutton, and therefore, torbutton_restore_nontor_settings throws in exception and therefore, this.unregister is not called (in torbutton_uninstall_observer object).
exception is triggered by line:
savprefs.setIntPref('socks_version', liveprefs.getIntPref('socks_version'));
by the way, adding a line for extensions.torbutton.saved.socks_version in defaults/preferences/preferences.js seems to fix that.a
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: arno
Mike Perry
Mike Perry
https://gitlab.torproject.org/legacy/trac/-/issues/498
Proof-of-work for exit remailers
2019-06-17T19:06:58Z
Trac
Proof-of-work for exit remailers
To prevent spam and/or floods originating from the mixminion network it might be
sensible to require (adjustable by the exit remailer operator) some proof-of-work,
e.g. hashcash before relaying the message. Dummy messages would not be af...
To prevent spam and/or floods originating from the mixminion network it might be
sensible to require (adjustable by the exit remailer operator) some proof-of-work,
e.g. hashcash before relaying the message. Dummy messages would not be affected
because those don't leave the network anyway.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: tcr
https://gitlab.torproject.org/legacy/trac/-/issues/499
Win32 - duplicate state file created
2020-06-13T13:58:40Z
Trac
Win32 - duplicate state file created
Tor v0.1.2.17 under Win32 (maybe others?)
When using the DataDirectory setting in my torrc file (same setting as in Vidalia) a duplicate 'state' file
is created in '%APPDATA%\tor', regardless of the setting. The rest of the files (cach...
Tor v0.1.2.17 under Win32 (maybe others?)
When using the DataDirectory setting in my torrc file (same setting as in Vidalia) a duplicate 'state' file
is created in '%APPDATA%\tor', regardless of the setting. The rest of the files (cachedstatus, etc.) are
saved to the specified directory along with another copy of the 'state' file.
Does the Vidalia setting take precedence over the torrc setting anyway?
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: wraithdu
https://gitlab.torproject.org/legacy/trac/-/issues/500
Allow user-definable proxy settings for "disabled" state
2007-09-13T09:18:33Z
Trac
Allow user-definable proxy settings for "disabled" state
Currently, the "disabled" state of Torbutton is hardcoded to "Directly connect to the Internet".
Many installations however use proxy auto detection, a specified auto detection script or manually specified proxies.
Torbutton should let ...
Currently, the "disabled" state of Torbutton is hardcoded to "Directly connect to the Internet".
Many installations however use proxy auto detection, a specified auto detection script or manually specified proxies.
Torbutton should let the user specify what connection settings they want for the disabled state. At the very least, it
should not hardcode "directly connect" but instead save the previous state and switch back to that.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: cybasheep
https://gitlab.torproject.org/legacy/trac/-/issues/501
DataDirectory setting still leaves a remnant in the default DataDirectory
2020-06-13T13:58:40Z
Trac
DataDirectory setting still leaves a remnant in the default DataDirectory
If Tor is started, even with a DataDirectory specified, a file called "state" is created in a folder named "tor" in the Application Directory. This file should not be created if the DataDirectory is set somewhere else. To replicate the b...
If Tor is started, even with a DataDirectory specified, a file called "state" is created in a folder named "tor" in the Application Directory. This file should not be created if the DataDirectory is set somewhere else. To replicate the bug, set a DataDirectory to a location, and check for remnants in the system's Application Data directory.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Silivrenion