The Tor Project issues
https://gitlab.torproject.org/groups/tpo/-/issues
2020-06-27T14:11:02Z
https://gitlab.torproject.org/tpo/core/tor/-/issues/231
dirserver still serves descriptor that it ignored
2020-06-27T14:11:02Z
weasel (Peter Palfrader)
dirserver still serves descriptor that it ignored
Hi,
I sent a HUP to tor for some reason, which made it (among other things)
rebuild its descriptor. It never properly accepted that descriptor:
Jan 08 03:15:06.692 [info] dirserv_add_descriptor(): Not replacing descriptor from 'tor26';...
Hi,
I sent a HUP to tor for some reason, which made it (among other things)
rebuild its descriptor. It never properly accepted that descriptor:
Jan 08 03:15:06.692 [info] dirserv_add_descriptor(): Not replacing descriptor from 'tor26'; differences are cosmetic.
And it also doesn't use it in network status documents:
| r tor26 hHsfhQNE14dkkaVIkvkEk05OuF0 1EU6pTJz9JND73PS0w6UXAJiChw 2006-01-07 23:01:14 86.59.21.38 443 80
(the status was published 02:26:57 UTC)
However, it still serves that new and ignored descriptor when fetching SD by identity key:
http://tor.noreply.org/tor/server/fp/847B1F850344D7876491A54892F904934E4EB85D had a
descriptor published 02:15:03 UTC.
Bug?
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/232
authorities are quick to declare nodes as down
2020-06-27T14:11:02Z
weasel (Peter Palfrader)
authorities are quick to declare nodes as down
Dirservers probably shouldn't be so quick to declare nodes as not running.
For instance yesterday moria1 and moria2 repeatedly declared tor26 as down
even tho it was just fine.
<arma2> the reachability bug is for me, though. i'm still ...
Dirservers probably shouldn't be so quick to declare nodes as not running.
For instance yesterday moria1 and moria2 repeatedly declared tor26 as down
even tho it was just fine.
<arma2> the reachability bug is for me, though. i'm still pondering it.
i'll sit down and test more once i have a free hour.
[Automatically added by flyspray2trac: Operating System: All]
0.1.1.11-alpha
Roger Dingledine
Roger Dingledine
https://gitlab.torproject.org/tpo/core/tor/-/issues/233
directories push a great many bytes, clients too greedy?
2020-06-27T14:11:02Z
weasel (Peter Palfrader)
directories push a great many bytes, clients too greedy?
Something makes a lot of directory requests to (v2?) dirservers.
For instance right now tor26 reads about 4Mbit/s but pushes 8 which
probably means that there are 4MBit/s of directory information going
out constantly.
[Automatically ad...
Something makes a lot of directory requests to (v2?) dirservers.
For instance right now tor26 reads about 4Mbit/s but pushes 8 which
probably means that there are 4MBit/s of directory information going
out constantly.
[Automatically added by flyspray2trac: Operating System: All]
0.1.1.11-alpha
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/tpo/core/tor/-/issues/234
Mysterious crash on 0.1.1.9 and 0.1.1.10 servers
2020-06-27T14:11:02Z
weasel (Peter Palfrader)
Mysterious crash on 0.1.1.9 and 0.1.1.10 servers
Busy servers usually mysteriously crash after a day or two of uptime.
Possibly related to src/common/crypto's crypto_seed_rng() or some other openssl state.
Please fix.
[Automatically added by flyspray2trac: Operating System: All]
Busy servers usually mysteriously crash after a day or two of uptime.
Possibly related to src/common/crypto's crypto_seed_rng() or some other openssl state.
Please fix.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/235
Servers and ReachableAddresses
2020-06-27T14:11:02Z
weasel (Peter Palfrader)
Servers and ReachableAddresses
A server operator did set FascistFirewall because he filtered
incoming connections. Maybe Tor should do something, like warn
or not let you be a server, when you have a restrictive
ReachableAddresses list.
<weasel> should Tor allow you...
A server operator did set FascistFirewall because he filtered
incoming connections. Maybe Tor should do something, like warn
or not let you be a server, when you have a restrictive
ReachableAddresses list.
<weasel> should Tor allow you to be a server when you have
FascistFirewall set?
<nickm> weasel: Probably not. But it's hard to enforce, since it's
reasonable to allow servers when ReachableAddresses is set.
<nickm> And FascistFirewall aliases to that./
<weasel> is it reasonable?
<nickm> Sure
<weasel> ok :)
<nickm> If I say "all ports 1024-65535 are reachable", I'm a fine
server.
<weasel> this specific config would mean you can only access one of
the auth directory servers
<nickm> well, that would suck.
<nickm> actually...
<nickm> okay, adding proposed rule to TODO.
<weasel> maybe Tor should warn if your ReachableAddresses prevents you
from reaching one of the dirservers?
<nickm> let me know what you think
<nickm> If you're a directory cache, you need to be able to reach all
the directory authorities.
<nickm> If you're an OR, you should be able to reach (oh, say) 85% of
the other ORs.
<weasel> and you need to be able to reach at least one directory
authority.
<nickm> hm, true, to bootstrap.
<nickm> I suspect this is not an earthshaking problem as it is: you'll
either bootstrap or you wont; you'll either be able to build a
connection to yourself or
<weasel> you're right, it's not. it would just be nice to give the
operator some feedback that what he's doing is probably not a
good idea :)
<weasel> as it turned out in this case the user didn't realize
FascistFirewall was for outgoing, not incoming connections.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/236
cache network status of unknown authorities
2020-06-27T14:11:01Z
weasel (Peter Palfrader)
cache network status of unknown authorities
<nickm> arma: We should think about what will happen when we add new
directories.
<nickm> directory authorities, that is.
<arma2> you mean anonymity attacks?
<nickm> Well, that too.
<nickm> But I meant in terms of everything work...
<nickm> arma: We should think about what will happen when we add new
directories.
<nickm> directory authorities, that is.
<arma2> you mean anonymity attacks?
<nickm> Well, that too.
<nickm> But I meant in terms of everything working.
<nickm> I looked over the code, and I see that it's only an info (not a warn)
to be given a network-status you don't recognize: that's good, since
caches will ask authorities for "everybody!", and older ones will get
authorities they won't recognize.
<nickm> OTOH, would it be a good idea to cache (if not use!) network-status
docs from unrecognized authorities?
<nickm> that way directory caches don't become less useful when we add new dir
authorities.
<arma2> yes, i guess that would be useful to cache them.
<arma2> tho we want to not cache too many.
<nickm> right.
<arma2> and we want to not use them (right?)
<nickm> and again, right.
<arma2> that should get fixed for 0.1.1.11-alpha if we are smart
<nickm> I say cap it at 16 unrecognized authority identities.
<arma2> is it easy to fix?
<nickm> dunno
<arma2> ok.
<nickm> let me check.
[Automatically added by flyspray2trac: Operating System: All]
0.1.1.11-alpha
https://gitlab.torproject.org/tpo/core/tor/-/issues/237
Allow fetching descriptors using the controller interface
2020-06-27T14:11:01Z
weasel (Peter Palfrader)
Allow fetching descriptors using the controller interface
<goodell> I also don't get exit policy this way
<goodell> without fetching individual descriptors wholesale
<arma2> which i'm about to allow via the controller
<arma2> getinfo desc/id/all
<goodell> for 0.1.1.11-alpha?
<arma2> yes
<arma2...
<goodell> I also don't get exit policy this way
<goodell> without fetching individual descriptors wholesale
<arma2> which i'm about to allow via the controller
<arma2> getinfo desc/id/all
<goodell> for 0.1.1.11-alpha?
<arma2> yes
<arma2> but first i must heat up some food or i will cease to be
[Automatically added by flyspray2trac: Operating System: All]
0.1.1.11-alpha
https://gitlab.torproject.org/tpo/core/tor/-/issues/238
Fix for "HUP clears default log target" is ugly
2020-06-27T14:11:01Z
weasel (Peter Palfrader)
Fix for "HUP clears default log target" is ugly
Fixing the problem where "setconf log" always appended the default log line
broke tor so that a HUP now removes the default log target if none
is specified in torrc.
[Automatically added by flyspray2trac: Operating System: All]
Fixing the problem where "setconf log" always appended the default log line
broke tor so that a HUP now removes the default log target if none
is specified in torrc.
[Automatically added by flyspray2trac: Operating System: All]
post 0.1.2.x
https://gitlab.torproject.org/tpo/core/tor/-/issues/239
Specifying HiddenServiceNodes without defining Hidden Services causes unrelat...
2020-06-27T14:11:01Z
Trac
Specifying HiddenServiceNodes without defining Hidden Services causes unrelated error.
Jan 08 20:06:57.285 [warn] HiddenServicePort with no preceding HiddenServiceDir
directive.
This warning is given, and Tor closes, if HiddenServiceNodes is defined but HiddenServicePort and HiddenServiceDir are not defined.
Some users ...
Jan 08 20:06:57.285 [warn] HiddenServicePort with no preceding HiddenServiceDir
directive.
This warning is given, and Tor closes, if HiddenServiceNodes is defined but HiddenServicePort and HiddenServiceDir are not defined.
Some users may want to temporarily comment out their HiddenServiceDir and HiddenServicePorts but not lose their list of HiddenServiceNodes.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: HexMaster
https://gitlab.torproject.org/tpo/core/tor/-/issues/240
when dumping state, we write description even if we don't write the state value
2020-06-27T14:11:01Z
Roger Dingledine
when dumping state, we write description even if we don't write the state value
# How many bytes have we written in this accounting period?
AccountingBytesWrittenInInterval 0
# How many bytes did we expect to use per minute? (0 for no estimate.)
AccountingExpectedUsage 0
# When did this accounting period begin?
# Ho...
# How many bytes have we written in this accounting period?
AccountingBytesWrittenInInterval 0
# How many bytes did we expect to use per minute? (0 for no estimate.)
AccountingExpectedUsage 0
# When did this accounting period begin?
# How long have we been awake in this period?
AccountingSecondsActive 0
In this case, AccountingIntervalStart is not written, yet its description is.
[Automatically added by flyspray2trac: Operating System: All]
0.1.1.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/241
segfaults with HW acceleration
2020-06-27T14:11:01Z
weasel (Peter Palfrader)
segfaults with HW acceleration
as reported in #tor, Tor 0.1.1.12 (from the RPM) crashes when HW
crypto engines are available. OpenSSL was probably at 0.9.7.
Jan 16 11:22:48.845 [notice] Using OpenSSL engine Aep hardware engine support [aep] for RSA ...
as reported in #tor, Tor 0.1.1.12 (from the RPM) crashes when HW
crypto engines are available. OpenSSL was probably at 0.9.7.
Jan 16 11:22:48.845 [notice] Using OpenSSL engine Aep hardware engine support [aep] for RSA
Jan 16 11:22:48.845 [notice] Using OpenSSL engine Aep hardware engine support [aep] for DH
Jan 16 11:22:48.846 [notice] Using OpenSSL engine Aep hardware engine support [aep] for RAND
Core was generated by `tor -f /etc/tor/torrc'.
(gdb) bt
#0 0x00828480 in ?? ()
#1 0x02f5affe in ENGINE_load_aep () from /lib/libcrypto.so.4
legacy/trac#2 0x02f5aadb in ENGINE_load_aep () from /lib/libcrypto.so.4
legacy/trac#3 0x02f48082 in RSA_blinding_on () from /lib/libcrypto.so.4
legacy/trac#4 0x02f460a4 in RSA_PKCS1_SSLeay () from /lib/libcrypto.so.4
legacy/trac#5 0x02f46531 in RSA_PKCS1_SSLeay () from /lib/libcrypto.so.4
legacy/trac#6 0x02f47e9e in RSA_private_encrypt () from /lib/libcrypto.so.4
legacy/trac#7 0x02f486c6 in RSA_sign () from /lib/libcrypto.so.4
legacy/trac#8 0x02f75393 in EVP_SignFinal () from /lib/libcrypto.so.4
legacy/trac#9 0x02f7de9d in ASN1_item_sign () from /lib/libcrypto.so.4
legacy/trac#10 0x02f9c74e in X509_sign () from /lib/libcrypto.so.4
legacy/trac#11 0x080b122a in tor_tls_create_certificate ()
legacy/trac#12 0x080b14fc in tor_tls_context_new ()
legacy/trac#13 0x097ba2f0 in ?? ()
legacy/trac#14 0x080ba9cf in command_c_id ()
legacy/trac#15 0xbfeea670 in ?? ()
legacy/trac#16 0x43cc17af in ?? ()
legacy/trac#17 0xffffffff in ?? ()
legacy/trac#18 0xbfeea668 in ?? ()
legacy/trac#19 0x02f22e1d in CRYPTO_free () from /lib/libcrypto.so.4
Previous frame inner to this frame (corrupt stack?)
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/242
"closing wedged cpuworker"
2020-06-27T14:11:01Z
Trac
"closing wedged cpuworker"
Jan 16 17:35:42.229 [notice] cull_wedged_cpuworkers(): Bug: closing wedged cpuworker. Can somebody find the bug?
Using libevent-1.1a on a Linux i586 system, the above message appears in my log. Tor server does not seem to crash; servic...
Jan 16 17:35:42.229 [notice] cull_wedged_cpuworkers(): Bug: closing wedged cpuworker. Can somebody find the bug?
Using libevent-1.1a on a Linux i586 system, the above message appears in my log. Tor server does not seem to crash; service remains viable.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: jtesta
Roger Dingledine
Roger Dingledine
https://gitlab.torproject.org/tpo/core/tor/-/issues/244
please detect your Tor server's IP address through NAT too
2020-06-27T14:11:01Z
weasel (Peter Palfrader)
please detect your Tor server's IP address through NAT too
A user wrote:
One request is the ability of tor to
discover by himself the public IP when natted without me edit the torrc or
the /etc/hosts...maybe some functions that run every once that check and
maybe change the address...this is us...
A user wrote:
One request is the ability of tor to
discover by himself the public IP when natted without me edit the torrc or
the /etc/hosts...maybe some functions that run every once that check and
maybe change the address...this is useful if you have the server running all
day but the connection is not so reliable.
[Automatically added by flyspray2trac: Operating System: All]
0.2.0.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/245
tcp connection rollover still buggy
2020-06-27T14:11:01Z
weasel (Peter Palfrader)
tcp connection rollover still buggy
<weasel> hmm, weird
<weasel> tor26 uses 2500 FDs, but there are only 600 connections to its ORPort
<arma> dir connections?
<arma> kill -usr1 it and see what they are? :)
<weasel> no, those are well below 50
<weasel> netstat suggests ther...
<weasel> hmm, weird
<weasel> tor26 uses 2500 FDs, but there are only 600 connections to its ORPort
<arma> dir connections?
<arma> kill -usr1 it and see what they are? :)
<weasel> no, those are well below 50
<weasel> netstat suggests there are about 1700 connections from tor26 to other nodes
<arma> 600 + 1700 + 50 + fudge = 2500
<weasel> yes, only 1700 is a bit much, isn't it?
<weasel> there aren't that many routers :)
<weasel> ouch
<arma> ?
<weasel> there's over 90 connections just to 140.247.62.121:9001
<weasel> (rodos)
<weasel> bug?
<arma> does each connection have a circuit open?
<arma> or are all the circuits clustered on one or a few connections?
* weasel USR1s tor
<arma> were they all born around the same time, or are they spaced evenly?
<weasel> grr
<weasel> they are all [scrubbed] :)
<weasel> | Jan 22 22:37:26.798 [info] OR rodos [DFF1D66324E1CD02DC7A594EB7DC5F573CDDBDE0]: 93/93 good connections; uptime 118912/118912 sec (100.00%)
<weasel> (it seems it never expired a single one of them tho)
<arma> exciting.
<weasel> there are several that don't have any connections,
<arma> i keep oscillating between fixing this bug and creating new ones.
<weasel> and also several that have connections
<arma> you mean circuits
<weasel> yes
<arma> Jan 22 16:43:46.483 [notice] Average bandwidth: 288565965253/426289 = 676925 byt
<arma> es/sec reading
<arma> Jan 22 16:43:46.483 [notice] Average bandwidth: 377444609668/426289 = 885419 byt
<arma> es/sec writing
<arma> Jan 22 16:43:46.483 [notice] --------------- Dumping memory information:
<arma> Jan 22 16:43:46.483 [notice] In buffers: 8255274 used/86016000 allocated (5803 c
<arma> onns).
<arma> Jan 22 16:43:46.483 [notice] In rephist: 4579240 used by 62619 Tors.
<arma> Jan 22 16:43:46.483 [notice] In 605 live descriptors: 1485855 bytes. In 2247 ol
<arma> d descriptors: 5706345 bytes.
<weasel> 59 without circuits. 32 with circuits
<weasel> most circuits any connection has is 17. then 11, 10, 8, 4, 4, 4, 4, 3, 3, 3, 3, 2, 2, 2, and the rest has 1 or 0
<arma> moria2 has 5803 conns open.
[Automatically added by flyspray2trac: Operating System: All]
0.1.1.13-alpha
https://gitlab.torproject.org/tpo/core/tor/-/issues/246
segfault after upgrade to Openssl-0.9.8
2020-06-27T14:11:00Z
Trac
segfault after upgrade to Openssl-0.9.8
After upgrading to Openssl-0.9.8, tor SegFaults when trying to establish a TLSv3 session.
This bug exists in both current-stable, and .11-alpha and .12-alpha.
Relevent debug info :
(tor compiled with --enable-debug)
Jan 25 10:32:02.287...
After upgrading to Openssl-0.9.8, tor SegFaults when trying to establish a TLSv3 session.
This bug exists in both current-stable, and .11-alpha and .12-alpha.
Relevent debug info :
(tor compiled with --enable-debug)
Jan 25 10:32:02.287 [debug] connection_or_finished_connecting(): OR connect() to router at 82.165.233.43:9001 finished.
Jan 25 10:32:02.287 [debug] connection_tls_start_handshake(): starting TLS handshake on fd 7
Jan 25 10:32:02.287 [debug] connection_tls_continue_handshake(): wanted read
Jan 25 10:32:02.287 [debug] connection_tls_continue_handshake(): wanted read
Jan 25 10:32:02.501 [debug] conn_read_callback(): socket 7 wants to read.
Segmentation fault (core dumped)
stack backtrace :
legacy/trac#268 0x40066fd0 in ?? () from /usr/lib/libssl.so.0
legacy/trac#269 0x082a4a78 in ?? ()
legacy/trac#270 0x081c2120 in ?? ()
legacy/trac#271 0xbfdd26a8 in ?? ()
legacy/trac#272 0x4005485a in SSL_connect () from /usr/lib/libssl.so.0
legacy/trac#273 0x082a4a78 in ?? ()
legacy/trac#274 0x0825bbe8 in ?? ()
legacy/trac#275 0x082d5fe0 in ?? ()
legacy/trac#276 0x080be2eb in tor_tls_handshake (tls=0xbfdd23c4) at tortls.c:556
Previous frame inner to this frame (corrupt stack?)
OpenSSL version info :
OpenSSL 0.9.8a 11 Oct 2005
built on: Tue Jan 24 14:01:00 EST 2006
platform: linux-elf
options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) idea(int) blowfish(idx)
compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -mcpu=pentium -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
OPENSSLDIR: "/etc/ssl"
LDD info for TOR binary :
ldd /usr/local/bin/tor
libz.so.1 => /usr/lib/libz.so.1 (0x40026000)
libssl.so.0 => /usr/lib/libssl.so.0 (0x40037000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40068000)
libdl.so.2 => /lib/libdl.so.2 (0x400b9000)
libevent-1.1a.so.1 => /usr/local/lib/libevent-1.1a.so.1 (0x400bd000)
libc.so.6 => /lib/libc.so.6 (0x400c4000)
libcrypto.so.0 => /usr/lib/libcrypto.so.0 (0x401f3000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: mindcandy28
https://gitlab.torproject.org/tpo/core/tor/-/issues/247
Tor doesn't seem to work with Network configuration
2020-06-27T14:11:00Z
Trac
Tor doesn't seem to work with Network configuration
Running OS X 10.3.9 with Tor installed; Network settings pointing to Privoxy on 127.0.0.1, port 8118 for HTTP,
HTTPS, and Gopher. Using Safari 1.3, Camino 1.0b1 and Firefox 1.5 with SwitchProxy and the browser's Connection
settings poin...
Running OS X 10.3.9 with Tor installed; Network settings pointing to Privoxy on 127.0.0.1, port 8118 for HTTP,
HTTPS, and Gopher. Using Safari 1.3, Camino 1.0b1 and Firefox 1.5 with SwitchProxy and the browser's Connection
settings pointing to Privoxy as well.
Connecting to ipid.shat.net/ using Safari or Camino shows an ip address in a different part of the country or
world, as expected. Using Firefox 1.5 with SwitchProxy turned off (Network settings for OS X are still enabled), I get an
ip address for my ISP, even though they're not running any Tor servers. If I use Network Utility to do a Whois lookup,
it also says I'm coming from my ISP; same if I go to www.dnsstuff.com (Java and JavaScript are off). Turning on SwitchProxy
(even while Network settings are enabled) and trying again gets me an IP address in a different part of the country or world,
as it should be.
This makes no sense, and it doesn't inspire confidence, since I get different results depending on which browser I'm using.
I followed the directions for installation and setup, so I can only presume it's a bug of some sort, perhaps with OS X, or Tor.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: dedwards
https://gitlab.torproject.org/tpo/core/tor/-/issues/248
exit/dns assert failure when out of sockets
2020-06-27T14:11:00Z
Roger Dingledine
exit/dns assert failure when out of sockets
Feb 06 14:42:40.773 [warn] connection_add(): Failing because we have 8159 connections already. Please raise your ulimit -n.
Feb 06 14:55:33.357 [err] dns.c:177: purge_expired_resolves: Assertion pend->conn->s == -1 failed; aborting.
leg...
Feb 06 14:42:40.773 [warn] connection_add(): Failing because we have 8159 connections already. Please raise your ulimit -n.
Feb 06 14:55:33.357 [err] dns.c:177: purge_expired_resolves: Assertion pend->conn->s == -1 failed; aborting.
legacy/trac#2 0x00000000004320fe in purge_expired_resolves (now=1139255733) at dns.c:166
legacy/trac#3 0x00000000004323d0 in dns_resolve (exitconn=0x16c9cdf0) at dns.c:282
legacy/trac#4 0x0000000000421201 in connection_exit_begin_resolve (cell=0x7fbffff13e, circ=0x18ddac30)
at connection_edge.c:1608
legacy/trac#5 0x000000000043af87 in connection_edge_process_relay_cell (cell=0x7fbffff130,
circ=0x18ddac30, conn=0x0, layer_hint=0x0) at relay.c:1058
legacy/trac#6 0x0000000000439654 in circuit_receive_relay_cell (cell=0x7fbffff130, circ=0x18ddac30,
cell_direction=2) at relay.c:169
legacy/trac#7 0x0000000000412c03 in command_process_relay_cell (cell=0x7fbffff130, conn=0xae1b30)
at command.c:315
legacy/trac#8 0x0000000000423270 in connection_or_process_cells_from_inbuf (conn=0xae1b30)
at connection_or.c:777
legacy/trac#9 0x000000000041bc65 in connection_handle_read (conn=0xae1b30) at connection.c:1202
(gdb) print *oldest_cached_resolve
$2 = {node = {hte_next = 0x0, hte_hash = 1156299437},
address = "www.cinemanow.com", '\0' <repeats 238 times>, addr = 0, state = 0 '\0',
expire = 1139254227, pending_connections = 0xadc4900, next = 0x2c7bfb0}
(gdb) print *oldest_cached_resolve->pending_connections
$3 = {conn = 0xf6b00d0, next = 0x0}
(gdb) print *oldest_cached_resolve->pending_connections->conn
$4 = {magic = 2084319310, type = 4 '\004', state = 5 '\005', purpose = 0 '\0',
wants_to_read = 0, wants_to_write = 0, hold_open_until_flushed = 0, has_sent_end = 0,
control_events_are_extended = 0, is_obsolete = 0, s = 494, poll_index = 3343,
read_event = 0x7cf730, write_event = 0x9937ac0, inbuf = 0xa7194d0, inbuf_reached_eof = 0,
timestamp_lastread = 1139255616, outbuf = 0x700490, outbuf_flushlen = 0,
timestamp_lastwritten = 1139255618, timestamp_created = 1139254410,
timestamp_lastempty = 1139255733, addr = 1166092339, port = 1062, marked_for_close = 0,
marked_for_close_file = 0x0, address = 0x10812050 "69.129.40.51", identity_pkey = 0x0,
identity_digest = "tE3¯&i\027\025\204Áª»i\f\001>©ÕßH",
nickname = 0x1a062760 "$744533AF2669171584C1AABB690C013EA9D5DF48",
chosen_exit_name = 0x0, tls = 0x627d8c0, bandwidth = 6291456, receiver_bucket = 6291456,
circ_id_type = CIRC_ID_TYPE_HIGHER, n_circuits = 1, next_with_same_id = 0x0,
next_circ_id = 767, stream_id = 0, next_stream = 0x0, cpath_layer = 0x0,
package_window = 0, deliver_window = 0, requested_resource = 0x0, socks_request = 0x0,
global_identifier = 5000930, event_mask = 0, incoming_cmd_len = 0,
incoming_cmd_cur_len = 0, incoming_cmd = 0x0, on_circuit = 0x0,
rend_query = '\0' <repeats 16 times>, incoming_cmd_type = 0}
This is an OR conn that's pending on a DNS resolve? What the heck.
[Automatically added by flyspray2trac: Operating System: All]
0.1.2.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/249
streams automatically attached to controller circuits
2020-06-27T14:11:00Z
goodell
streams automatically attached to controller circuits
Currently, if a controller builds a circuit, then for all streams that Tor manages that match the
exit policy for that circuit, Tor will gladly attach that stream to that circuit. This is sometimes
desirable if a controller exists for t...
Currently, if a controller builds a circuit, then for all streams that Tor manages that match the
exit policy for that circuit, Tor will gladly attach that stream to that circuit. This is sometimes
desirable if a controller exists for the purpose of effecting an alternate selection algorithm for
general-purpose circuits. However, this is undesirable if a controller exists for the purpose of
constructing circuits for special use (e.g. Blossom). So, for each circuit we need a way of
specifying whether Tor is allowed to automatically attach streams to that circuit. I propose that
we have two classes of circuits: PUBLIC and PRIVATE, such that hen Tor is asked to automatically
attach a stream to some circuit, it must choose from among PUBLIC circuits only. Circuits built
via the controller with the EXTENDCIRCUIT command are considered PRIVATE by default. I propose
an additional controller command, SETCIRCUITEXPOSURE, with the following syntax:
"SETCIRCUITEXPOSURE" SP CircuitID SP {0,1}
An argument of '0' sets the circuit with the specified CircuitID to PRIVATE.
An argument of '1' sets the circuit with the specified CircuitID to PUBLIC.
[Automatically added by flyspray2trac: Operating System: All]
Roger Dingledine
Roger Dingledine
https://gitlab.torproject.org/tpo/core/tor/-/issues/250
internal circuit building algorithm uses routers introduced by controller
2020-06-27T14:11:00Z
goodell
internal circuit building algorithm uses routers introduced by controller
The mechanism by which Tor constructs circuits internally freely incorporates routers introduced by the controller.
In some cases this is desirable, such as when a controller exists for the purpose of feeding Tor additional
router descri...
The mechanism by which Tor constructs circuits internally freely incorporates routers introduced by the controller.
In some cases this is desirable, such as when a controller exists for the purpose of feeding Tor additional
router descriptors to use. In other cases this is undesirable, such as when a controller exists for the purpose
of providing Tor with router descriptors for special use (e.g. Blossom). Adding an optional entry to the descriptor
is insufficient, since a Tor controller could plausibly be trying to give a Tor client in one Tor network a descriptor
that is used in another Tor network. Thus, we must store some internal state about whether a given descriptor is
PUBLIC, meaning that Tor MAY use it to construct circuits internally, or PRIVATE, meaning that controllers MAY but
Tor MAY NOT use it in constructing circuits. I propose that we modify the POSTDESCRIPTOR controller command to allow
an extra argument that specifies the purpose of this router:
"+POSTDESCRIPTOR" (SP "PRIVATE") CRLF Descriptor CRLF "." CRLF
If "PRIVATE" is specified, then Tor MAY NOT use this descriptor to build circuits. (Preserves backwards compatibility)
Also, we may want to change the purpose of a descriptor, so I propose an additional controller command:
"SETDESCPURPOSE" SP ServerID SP {0,1}
If 0, then Tor will set the purpose of this descriptor to PRIVATE.
If 1, then Tor will set the purpose of this descriptor to PUBLIC.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/251
routers sometimes prefer not to talk to dirservers
2020-06-27T14:11:00Z
goodell
routers sometimes prefer not to talk to dirservers
Tor consists of two components, a program (the software) and a network (the service).
If our design is to be modular, then these components will be separable. Specifically,
if a Tor controller wants to replace or augment the functionali...
Tor consists of two components, a program (the software) and a network (the service).
If our design is to be modular, then these components will be separable. Specifically,
if a Tor controller wants to replace or augment the functionality that a directory
server ordinarily provides, then we should allow it to do so. However, aside from NoPublish,
we presently have no means by which we can instruct Tor to not attempt to contact the
directory servers using the standard, internal mechanism for interacting with directory
servers. We want a means by which we can tell Tor to NOT contact the directory server but
also NOT complain about its inability to do so. Specifically, if we use controller commands
to tell a Tor server to not publish its descriptors, then the server MUST NOT contact the
directories for the purpose of publishing descriptors, and otherwise still be functional.
Also, if we use controller commands to tell a Tor server OR client to not fetch descriptors
from the directory, then the server OR client MUST NOT contact the directories for the
purpose of fetching descriptors, and otherwise still be functional (though perhaps the
functionality will be limited if Tor clients know about fewer than three descriptors).
So here are the new config options. All have value '1' by default.
PublishServerDescriptor {0,1}
PublishHiddenServiceDescriptors {0,1}
FetchServerDescriptors {0,1}
FetchHiddenServiceDescriptors {0,1}
PublishServerDescriptor determines whether a server publishes its descriptor to
the directories.
PublishHiddenServiceDescriptors determines whether a server publishes any hidden
service descriptors it controls to the directories.
FetchServerDescriptors determines whether a server or client fetches server
descriptors from the directories.
FetchHiddenServiceDescriptors determines whether a server or client fetches hidden
service descriptors from the directories.
(*) Both ClientOnly and NoPublish SHOULD be aliases for the NEGATION of
PublishServerDescriptor.
We might also consider the ability to configure the set of directories to the empty set...
[Automatically added by flyspray2trac: Operating System: All]
Roger Dingledine
Roger Dingledine