Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:10:31Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/546missing cert launches never back off2020-06-27T14:10:31ZRoger Dingledinemissing cert launches never back offI just added ides as a new v3 authority to my config.c (on moria[12] and on my
bridge relay), and now
Nov 07 16:24:07.260 [notice] Launching request for 1 missing certificates
Nov 07 16:24:07.261 [warn] Received http status code 404 ("N...I just added ides as a new v3 authority to my config.c (on moria[12] and on my
bridge relay), and now
Nov 07 16:24:07.260 [notice] Launching request for 1 missing certificates
Nov 07 16:24:07.261 [warn] Received http status code 404 ("Not found") from serv
er '128.31.0.34:9031' while fetching "/tor/keys/fp/27B6B5996C426270A5C95488AA5BC
EB6BCC86956".
Nov 07 16:24:07.261 [notice] Launching request for 1 missing certificates
Nov 07 16:24:07.469 [warn] Received http status code 404 ("Not found") from serv
er '86.59.21.38:80' while fetching "/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB
6BCC86956".
Nov 07 16:24:07.469 [notice] Launching request for 1 missing certificates
Nov 07 16:24:07.616 [warn] Received http status code 404 ("Not found") from serv
er '216.224.124.114:9030' while fetching "/tor/keys/fp/27B6B5996C426270A5C95488A
A5BCEB6BCC86956".
Nov 07 16:24:07.616 [notice] Launching request for 1 missing certificates
Nov 07 16:24:07.616 [warn] Received http status code 404 ("Not found") from serv
er '128.31.0.34:9031' while fetching "/tor/keys/fp/27B6B5996C426270A5C95488AA5BC
EB6BCC86956".
Nov 07 16:24:07.617 [notice] Launching request for 1 missing certificates
Nov 07 16:24:07.618 [warn] Received http status code 404 ("Not found") from server '128.31.0.34:9031' while fetching "/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB6BCC86956".
it repeats ad infinitum without ever backing off.
(The other half of the bug might be that this cert isn't to be found anywhere,
even though ides is running. How are certs for new authorities supposed to get
spread around the network?)
[Automatically added by flyspray2trac: Operating System: All]0.2.0.10-alphahttps://gitlab.torproject.org/tpo/core/tor/-/issues/545updating guard status from v2 networkstatuses?2020-06-27T14:10:31ZRoger Dingledineupdating guard status from v2 networkstatuses?This is on my bridge, which is a relay plus dircache.
Nov 06 15:27:35.689 [info] connection_dir_client_reached_eof(): Received network
status objects (size 1729899) from server '128.31.0.34:9031'
Nov 06 15:27:35.720 [info] router_set_ne...This is on my bridge, which is a relay plus dircache.
Nov 06 15:27:35.689 [info] connection_dir_client_reached_eof(): Received network
status objects (size 1729899) from server '128.31.0.34:9031'
Nov 06 15:27:35.720 [info] router_set_networkstatus_v2(): Setting networkstatus
downloaded from directory server "moria1" at 128.31.0.34:9031 (published 2007-11
-06 20:27:25)
Nov 06 15:27:35.803 [info] router_set_networkstatus_v2(): Setting networkstatus
downloaded from directory server "tor26" at 86.59.21.38:80 (published 2007-11-06
20:26:19)
Nov 06 15:27:35.886 [info] router_set_networkstatus_v2(): Setting networkstatus
downloaded from directory server "dizum" at 194.109.206.212:80 (published 2007-1
1-06 20:26:24)
Nov 06 15:27:35.967 [info] router_set_networkstatus_v2(): Setting networkstatus
downloaded from directory server "moria2" at 128.31.0.34:9032 (published 2007-11
-06 20:26:30)
Nov 06 15:27:36.048 [info] router_set_networkstatus_v2(): Setting networkstatus
downloaded from directory server "lefkada" at 140.247.60.64:80 (published 2007-1
1-06 20:26:49)
Nov 06 15:27:36.107 [info] entry_guards_compute_status(): Summary: Entry 'sabota
ge' is reachable, unusable and not live.
Nov 06 15:27:36.107 [info] entry_guards_compute_status(): Summary: Entry 'teunto
rt' is reachable, usable and live.
...
It appears to be not only caching the v2 networkstatuses, but also looking at them
and acting on them?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/544bandwidth buckets are ints2020-06-27T14:10:31ZRoger Dingledinebandwidth buckets are intsNov 06 12:09:57.592 [debug] global_read_bucket now 6291456.
Nov 06 13:10:20.167 [debug] global_read_bucket now -1815240658.
Nov 06 13:10:20.167 [debug] global_write_bucket now -1815085682.
Nov 06 13:10:20.167 [debug] global_relayed_read...Nov 06 12:09:57.592 [debug] global_read_bucket now 6291456.
Nov 06 13:10:20.167 [debug] global_read_bucket now -1815240658.
Nov 06 13:10:20.167 [debug] global_write_bucket now -1815085682.
Nov 06 13:10:20.167 [debug] global_relayed_read_bucket now 512000.
Nov 06 13:10:20.167 [warn] Your system clock just jumped 3517 seconds forward; a
ssuming established circuits no longer work.
This overflow is probably a bug in 0.1.2.x too.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/5430.2.0.9-alpha servers don't update enough dir info2022-10-12T22:01:51ZRoger Dingledine0.2.0.9-alpha servers don't update enough dir infoNov 03 22:38:08.163 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 0/1170 usable descriptors.
Nov 03 22:38:08.299 [notice] I learned some more directory information, but not
enough t...Nov 03 22:38:08.163 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 0/1170 usable descriptors.
Nov 03 22:38:08.299 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 7/1170 usable descriptors.
Nov 03 22:38:08.357 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 56/1170 usable descriptors.
Nov 03 22:38:08.403 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 102/1170 usable descriptors.
Nov 03 22:38:08.445 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 152/1170 usable descriptors.
Nov 03 22:38:08.494 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 201/1170 usable descriptors.
Nov 03 22:38:08.534 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 254/1170 usable descriptors.
Nov 03 22:38:08.589 [notice] We now have enough directory information to build c
ircuits.
Nov 03 22:38:14.721 [notice] Tor has successfully opened a circuit. Looks like c
lient functionality is working.
So far so good.
Nov 05 17:01:51.001 [notice] Our directory information is no longer up-to-date e
nough to build circuits.
Nov 05 17:05:54.709 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 301/1230 usable descriptors.
Nov 05 17:05:54.793 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 301/1230 usable descriptors.
Nov 05 17:05:54.833 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 301/1230 usable descriptors.
Nov 05 17:05:55.141 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 301/1230 usable descriptors.
Nov 05 17:06:55.449 [notice] We now have enough directory information to build c
ircuits.
Nov 05 17:15:03.960 [notice] Our directory information is no longer up-to-date e
nough to build circuits.
Nov 05 17:21:09.975 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 293/1197 usable descriptors.
Nov 05 17:21:10.005 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 293/1197 usable descriptors.
Nov 05 17:21:10.030 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 293/1197 usable descriptors.
Nov 05 17:21:10.372 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 293/1197 usable descriptors.
Nov 05 17:36:25.179 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 281/1197 usable descriptors.
Nov 05 17:36:25.206 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 281/1197 usable descriptors.
Nov 05 17:36:25.230 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 281/1197 usable descriptors.
Nov 05 17:36:25.675 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 281/1197 usable descriptors.
Nov 05 17:51:40.348 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 265/1197 usable descriptors.
Nov 05 17:51:40.389 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 265/1197 usable descriptors.
Nov 05 17:51:40.413 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 265/1197 usable descriptors.
Nov 05 17:51:40.755 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 265/1197 usable descriptors.
Nov 05 18:06:54.579 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 255/1198 usable descriptors.
Nov 05 18:06:54.622 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 255/1198 usable descriptors.
Nov 05 18:06:54.768 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 255/1198 usable descriptors.
Nov 05 18:06:54.981 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 255/1198 usable descriptors.
Nov 05 18:14:01.845 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 226/1153 usable descriptors.
Nov 05 18:14:01.862 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 227/1153 usable descriptors.
Nov 05 18:14:01.877 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 229/1153 usable descriptors.
Nov 05 18:22:09.761 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 223/1154 usable descriptors.
Nov 05 18:22:09.795 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 223/1154 usable descriptors.
Nov 05 18:22:09.822 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 223/1154 usable descriptors.
Nov 05 18:22:10.294 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 223/1154 usable descriptors.
Nov 05 18:37:25.011 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 196/1155 usable descriptors.
Nov 05 18:37:25.055 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 196/1155 usable descriptors.
Nov 05 18:37:25.084 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 196/1155 usable descriptors.
Nov 05 18:37:25.592 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 196/1155 usable descriptors.
Nov 05 18:52:40.170 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 187/1155 usable descriptors.
Nov 05 18:52:40.196 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 187/1155 usable descriptors.
Nov 05 18:52:40.217 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 187/1155 usable descriptors.
Nov 05 18:52:40.696 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 187/1155 usable descriptors.
Nov 05 19:07:57.288 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 173/1156 usable descriptors.
Nov 05 19:07:57.316 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 173/1156 usable descriptors.
Nov 05 19:07:57.339 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 173/1156 usable descriptors.
Nov 05 19:07:57.775 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 173/1156 usable descriptors.
Nov 05 19:19:05.298 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 169/1169 usable descriptors.
Nov 05 19:19:05.315 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 170/1169 usable descriptors.
Nov 05 19:19:05.332 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 171/1169 usable descriptors.
Nov 05 19:19:05.347 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 171/1169 usable descriptors.
Nov 05 19:23:12.044 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 168/1169 usable descriptors.
Nov 05 19:23:12.076 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 168/1169 usable descriptors.
Nov 05 19:23:12.096 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 168/1169 usable descriptors.
Nov 05 19:23:12.437 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 168/1169 usable descriptors.
Nov 05 19:38:24.736 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 155/1170 usable descriptors.
...
Nov 05 22:10:57.386 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 55/1160 usable descriptors.
Nov 05 22:15:59.274 [warn] I have no descriptor for the router named "moria1" in
my declared family; I'll use the nickname as is, but this may confuse clients.
Nov 05 22:15:59.274 [warn] I have no descriptor for the router named "moria2" in
my declared family; I'll use the nickname as is, but this may confuse clients.
Nov 05 22:15:59.278 [notice] Application request when we're believed to be offli
ne. Optimistically trying directory fetches again.
Nov 05 22:25:09.857 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 55/1172 usable descriptors.
Nov 05 22:25:09.875 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 57/1172 usable descriptors.
Nov 05 22:25:10.060 [notice] I learned some more directory information, but not
enough to build a circuit: We have only 58/1172 usable descriptors.
it's slowly gone up to 95/1300 usable descriptors.
Something is clearly wrong here. :)
[Automatically added by flyspray2trac: Operating System: All]0.2.0.10-alphahttps://gitlab.torproject.org/tpo/core/tor/-/issues/542looking for fallback-consensus in funny place2020-06-27T14:10:31ZRoger Dingledinelooking for fallback-consensus in funny placeNov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/c
ached-certs": No such file or directory
Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/c
ached-consensus": No such file or d...Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/c
ached-certs": No such file or directory
Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/c
ached-consensus": No such file or directory
Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/u
nverified-consensus": No such file or directory
Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "${prefix}/share/t
or/fallback-consensus": No such file or directory
My orconfig.h even says
/* Default location for platform-independent read-only data. */
#define SHARE_DATADIR "${prefix}/share"
Are we defining this wrong in the autoconf?
(Linux Debian Etch, I did an svn checkout and then ./autogen && ./configure &&
make && src/or/tor)
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/541problem Toor with Avast2020-06-27T14:10:31ZTracproblem Toor with AvastHi all.
I have a problem between the tor.exe and from the avast-virus scanner called ashserv.exe.
When i started my system and i go to the Internet with firefox (avast is started from the autostart).
Next step i klick manually privoxy an...Hi all.
I have a problem between the tor.exe and from the avast-virus scanner called ashserv.exe.
When i started my system and i go to the Internet with firefox (avast is started from the autostart).
Next step i klick manually privoxy and vidalia.
After 10-20sek. the cpu goes up to 100% from ashserv.exe and when i killed tor.exe with the taskmanager
or the exit button from vidalia the cpu goes normally.
After 10-20min. later i run vidalia with the tor client and no problems.
But after 1-2 hour later the same problem.
I tried from the vidalia-bundle 01.2.15 to 17 and from the alpha 0.2.0.6 up to 0.2.0.8
Today i installed the alpha 0.2.0.9 (no problem in this minutes but... by all new installations from vidalia
my system goes normally.
But next day the same problem. :-(
My System:
3300+ Semperon
1Gig Ram
DSL
WinXP SP2
all updates from microsoft (I hope ore better not ;-) )
Avast 4.7 Home Edition
Sygate Personal Firewall
Firefox 2.0.0.8 with the torbutton 1.0.4.01
What can i do?
sincerely
Arkon1
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: arkon1https://gitlab.torproject.org/tpo/core/tor/-/issues/540Bug 499 not totally fixed - tor directory still created in %APPDATA%2020-06-27T14:10:31ZTracBug 499 not totally fixed - tor directory still created in %APPDATA%I originally reported bug 499 (I think that was the number) about a state file being created in %APPDATA% regardless of
the specified data directory in Vidalia -
o Minor bugfixes:
- Don't try to access (or alter) the state file when ...I originally reported bug 499 (I think that was the number) about a state file being created in %APPDATA% regardless of
the specified data directory in Vidalia -
o Minor bugfixes:
- Don't try to access (or alter) the state file when running
--list-fingerprint or --verify-config or --hash-password. Resolves
bug 499.
I say this is partially resolved because the state file is no longer created. However an empty 'tor' directory is still
created in %APPDATA% when Vidalia/Tor is run.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: wraithduhttps://gitlab.torproject.org/tpo/core/tor/-/issues/539Dirservers give 503 response, but include content anyway.2020-06-27T14:10:32ZNick MathewsonDirservers give 503 response, but include content anyway.Reported on frell2 by packbart. The server is running 0.1.2.18.
packbart@hendrek:~$ telnet 85.10.240.250 80
Trying 85.10.240.250...
Connected to 85.10.240.250.
Escape character is '!^]'.
GET /tor/server/d/C13519E867FB6761FC90A1CEA1E628...Reported on frell2 by packbart. The server is running 0.1.2.18.
packbart@hendrek:~$ telnet 85.10.240.250 80
Trying 85.10.240.250...
Connected to 85.10.240.250.
Escape character is '!^]'.
GET /tor/server/d/C13519E867FB6761FC90A1CEA1E628817B18EE9E+C5532C1E1D73F578A6C8E88D4365A61334820DBD+5E1920509A6B5C64C754EE7CE371249DDBE643F3+93EC21BD7AD05AF61829657E415CA9DF5ACD9D69.z HTTP/1.0
Host: 85.10.240.250
HTTP/1.1 503 Directory busy, try again later
Date: Wed, 31 Oct 2007 21:01:19 GMT
Vary: Accept-Encoding
X-Cache: MISS from www.anon-proxy.de
Connection: close
Content-Type: text/plain; charset=iso-8859-1
Content-Encoding: x-compress
router videoraptor 88.198.67.4 9003 0 9032
platform Tor 0.1.1.26 on Linux i686
published 2007-10-31 19:00:52
opt fingerprint 5F47 51CE 3E98 4306 B520 32DF 1CE5 1A67 F118 7C9F
uptime 4349911
bandwidth 92160 131072 112693
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMF4Ut+axDUHZGVDzOm613YQ7e1Js0T1BKZR55fzK+XUqSHd9sFveH9R
MUsu0U/YLW6pSi/NGZyb8T4B8+JF1ehsUhcJF2Qz4HbZlvYT7x/j85PwN7l+/hze
TobTi6H9d6W1Nh6jNeHPmVPlYemGG/oOR0w43EIt0OrGM7z6fLhhAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMsEyOXG/RRht13cHiEmJgJ1+rn1Y5tldYTZzlMpv8m5ms9T2n2TB3BF
[...]
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/538[un]named_server_map should never be null.2020-06-27T14:10:32ZNick Mathewson[un]named_server_map should never be null.If no consensus exists, router_reload_consensus_networkstatus() does nothing. Instead, it should initialize
static fields in networkstatus.c that are used for nickname lookup. named_server_map should never be NULL, as it
was in the bug...If no consensus exists, router_reload_consensus_networkstatus() does nothing. Instead, it should initialize
static fields in networkstatus.c that are used for nickname lookup. named_server_map should never be NULL, as it
was in the bug reported by Fabian Keil on or-talk at 27 Oct 2007.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/537Warnings on startup from cached descriptors and invalid time in mtbf history2020-06-27T14:10:32ZRoger DingledineWarnings on startup from cached descriptors and invalid time in mtbf historyhttp://asteria.noreply.org/~weasel/.loud-tor
includes
Bug #1:
Oct 27 12:43:14.706 [warn] Got invalid ISO time "1969-11-08 08:36:56".
(Before 1970)
Oct 27 12:43:14.706 [warn] Couldn't parse started-tracking time in mtbf
history file.
...http://asteria.noreply.org/~weasel/.loud-tor
includes
Bug #1:
Oct 27 12:43:14.706 [warn] Got invalid ISO time "1969-11-08 08:36:56".
(Before 1970)
Oct 27 12:43:14.706 [warn] Couldn't parse started-tracking time in mtbf
history file.
Bug legacy/trac#2: perhaps we shouldn't bitch to the log when we have complaints
(or at least certain complaints) about a descriptor we read from the
cache.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/536memory leak in trusted_dirs_load_certs_from_string2020-06-27T14:10:32ZRoger Dingledinememory leak in trusted_dirs_load_certs_from_string==25743== 4,490 (3,978 direct, 512 indirect) bytes in 10 blocks are definitely l
ost in loss record 7 of 9
==25743== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==25743== by 0x80EBB6C: _tor_malloc (util.c:112)
==25743== by 0x...==25743== 4,490 (3,978 direct, 512 indirect) bytes in 10 blocks are definitely l
ost in loss record 7 of 9
==25743== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==25743== by 0x80EBB6C: _tor_malloc (util.c:112)
==25743== by 0x80DDCC3: authority_cert_parse_from_string (routerparse.c:1496)
==25743== by 0x80CD999: trusted_dirs_load_certs_from_string (routerlist.c:113
)
==25743== by 0x80CD946: trusted_dirs_reload_certs (routerlist.c:96)
==25743== by 0x80B01D4: do_main_loop (main.c:1347)
==25743== by 0x80B1766: tor_main (main.c:1932)
==25743== by 0x80EABB5: main (tor_main.c:28)
Looking at trusted_dirs_load_certs_from_string(), towards the bottom it calls
cert->cache_info.signed_descriptor_body = tor_strndup(s, eos-s);
yet in authority_cert_parse_from_string() we already
cert->cache_info.signed_descriptor_body = tor_malloc(len+1);
memcpy(cert->cache_info.signed_descriptor_body, s, len);
cert->cache_info.signed_descriptor_body[len] = 0;
It seems that we should do only one of these?
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/535servers should support hearing "not new descriptor"2020-06-27T14:10:32ZRoger Dingledineservers should support hearing "not new descriptor"Directory authorities, when they get a descriptor that isn't new enough
(more than cosmetically different) right now send back a 200 response code.
We should send some different code, so servers have a chance of knowing
whether their up...Directory authorities, when they get a descriptor that isn't new enough
(more than cosmetically different) right now send back a 200 response code.
We should send some different code, so servers have a chance of knowing
whether their uploaded descriptor actually "took" or was silently discarded.
So, changes as I understand them:
A) Tor servers should accept 200-299 as successes, not just 200.
B) What success code, within the range 201-299, most closely resembles
"I accepted it but it wasn't new enough so I didn't use it"? Is there
any precedent to follow here?
C) Once step A is done, authorities can start sending back other codes.
D) Is there any way to speed up reaching step C?
E) Should we also change 400 to a range 400-499?
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/534tor clients stop working if one v3 authority goes away for 3 hours2020-06-27T14:10:32ZRoger Dingledinetor clients stop working if one v3 authority goes away for 3 hoursIf one of the v3 authorities goes away, clients that use the v3 consensus
will fail to have a live one, and will refuse to build circuits.
We should make clients tolerate this by using an older consensus if they've
got it. I think "at m...If one of the v3 authorities goes away, clients that use the v3 consensus
will fail to have a live one, and will refuse to build circuits.
We should make clients tolerate this by using an older consensus if they've
got it. I think "at most 24 hours old" is a fine estimate -- not so high
that it will point to useless descriptors, and not so low that a bit of
downtime on the part of the authorities will be a killer.
Of course, this comes with an anonymity downside: the directory mirrors
can try to trick you into using an old consensus. Perhaps if we get an old
consensus then we should go straight to an authority for the next try (or
after a few tries), and then consider any one we get from an authority to
be safe?
When there are 10 authorities and it becomes clear that a majority of them
never vanish, we should then consider removing this feature, since the
anonymity risk will then outweigh the "it works" benefit. But for now, I
think 0.2.0.9-alpha clients will be much happier having this feature.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/533mmap failure complaints too loud2020-06-27T14:10:32ZRoger Dingledinemmap failure complaints too loudOct 23 23:37:44.983 [info] tor_mmap_file(): File "/home/arma/.tor/cached-descrip
tors" is empty. Ignoring.
Oct 23 23:37:44.983 [warn] Unable to mmap new descriptor file at '/home/arma/.to
r/cached-descriptors'.
Perhaps tor_mmap_file sho...Oct 23 23:37:44.983 [info] tor_mmap_file(): File "/home/arma/.tor/cached-descrip
tors" is empty. Ignoring.
Oct 23 23:37:44.983 [warn] Unable to mmap new descriptor file at '/home/arma/.to
r/cached-descriptors'.
Perhaps tor_mmap_file should have a tristate return value -- I succeeded, I failed
but that's ok, and I failed horribly?
(Is there any point to that third state?)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/532Do we use non-Running routers in scary places?2020-06-27T14:10:32ZRoger DingledineDo we use non-Running routers in scary places?Bringing this over from bug 529:
If we clear the flags for a given router yet don't delete the routerstatus
entry when we get a new consensus that doesn't list that router, is that
sufficient to make the client not use that router?
For...Bringing this over from bug 529:
If we clear the flags for a given router yet don't delete the routerstatus
entry when we get a new consensus that doesn't list that router, is that
sufficient to make the client not use that router?
For example, we ignore Running when posting to dir authorities.
For example, we might ignore Running when the client specifically asks for
a server, e.g. with the .exit notation.
(The original discussion also discussed the Valid flag, and wanted to make it
so you needed a Valid flag before you'd get used, on the theory that there
might be bugs with looking at the Running flag. But I think that's just
turtles all the way down. If there are bugs, we should fix them, not require
a second flag that might also have bugs.)
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/531Transition from 0.0.0.0 listener to specific listener disallowed2020-06-27T14:10:32ZNick MathewsonTransition from 0.0.0.0 listener to specific listener disallowedCoderman reported back in August that if you try to change from a listener on 0.0.0.0 to a listener on a specific
address, Tor will often fail, because it doesn't close the old listener until the new listener is open (in order
to be undo...Coderman reported back in August that if you try to change from a listener on 0.0.0.0 to a listener on a specific
address, Tor will often fail, because it doesn't close the old listener until the new listener is open (in order
to be undoable), but it can't open the new listener until the old one is closed.
See or-talk/or-dev thread, "Server node stalls on unsuccessful socks listener change."
It looks like we have two options:
1) Disallow the 0.0.0.0 -> non 0.0.0.0 change.
2) When transitioning from 0.0.0.0, accept that the transition will not be perfectly undoable.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/529v3 client confused about which servers are named2020-06-27T14:10:33ZRoger Dingledinev3 client confused about which servers are namedRunning r11968 as a client, it complains about things like
Oct 16 01:05:36.303 [warn] You specified a server "DrazziBTorNode" by name, but
this name is not registered, so it could be used by any server, not just the one
you meant. To m...Running r11968 as a client, it complains about things like
Oct 16 01:05:36.303 [warn] You specified a server "DrazziBTorNode" by name, but
this name is not registered, so it could be used by any server, not just the one
you meant. To make sure you get the same server in the future, refer to it by k
ey, as "$F268430A96705AC0BB52117AC5122F4DC934727E".
It turns out this is caused by vidalia doing a getinfo on this nickname.
I caught Tor while Vidalia was asking about Bellum:
#0 router_get_by_nickname (nickname=0x8306672 "Bellum", warn_if_unnamed=1)
at routerlist.c:1783
#1 0x08083c5e in getinfo_helper_dir (control_conn=0x8681e20,
question=0x8306668 "desc/name/Bellum", answer=0xbfc4342c) at control.c:1314
legacy/trac#2 0x08085d1b in handle_getinfo_helper (control_conn=0x8681e20,
question=0x8306668 "desc/name/Bellum", answer=0xbfc4342c) at control.c:1804
legacy/trac#3 0x08085df0 in handle_control_getinfo (conn=0x8681e20, len=19,
body=0x8adda00 "desc/name/Bellum\r\n") at control.c:1829
legacy/trac#4 0x08088670 in connection_control_process_inbuf (conn=0x8681e20)
at control.c:2685
legacy/trac#5 0x0807442e in connection_process_inbuf (conn=0x8681e20, package_partial=1)
at connection.c:2638
legacy/trac#6 0x080725a1 in connection_handle_read (conn=0x8681e20) at connection.c:1813
legacy/trac#7 0x080adfc0 in conn_read_callback (fd=24, event=2, _conn=0x8681e20)
at main.c:470
legacy/trac#8 0xb7ee6c79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
legacy/trac#9 0xb7ee6f65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#10 0xb7ee6dcb in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#11 0x080afe3b in do_main_loop () at main.c:1389
legacy/trac#12 0x080b127d in tor_main (argc=1, argv=0xbfc43804) at main.c:1928
legacy/trac#13 0x080e90e2 in main (argc=Cannot access memory at address 0x0
) at tor_main.c:28
It turns out there was a circuit building at that time:
Oct 16 01:26:41.539 [info] exit (high-uptime) circ (length 3, exit chaoscomputer
club23): $5C854C6CE50727F32E51274B1CF4DF9693A206EA(open) Bellum(open) $4121B07A3
86AA1A8015D618D213B1980BA388487(closed)
Now, clearly some part of Tor thought Bellum was Named, so it used the nickname.
But then the other part of Tor thought it wasn't.
In this case, the cached-consensus file said
r Bellum 7j/MKmnxheiRBy8T7pkIzW7ZvqU 22tvSKhAXrqKWmvs53JdUlWDr70 2007-10-15 22:2
7:52 62.75.223.163 9001 9030
s Fast Guard Named Running Stable V2Dir Valid
v Tor 0.1.2.14
but in my cached-status/* directories, which haven't been updated in a few hours
since I'm allegedly not using them anymore, tor26's networkstatus didn't have
an entry for Bellum -- so according to v2 it wouldn't be considered Named.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/528failure case memory leak in base32_decode2020-06-27T14:10:33ZTracfailure case memory leak in base32_decodeIt's trivial, but base32_decode mallocates a "tmp" variable which is not freed in the "illegal character in base32 encoded string" case.
...
/* Convert base32 encoded chars to the 5-bit values that they represent. */
tmp = tor_mallo...It's trivial, but base32_decode mallocates a "tmp" variable which is not freed in the "illegal character in base32 encoded string" case.
...
/* Convert base32 encoded chars to the 5-bit values that they represent. */
tmp = tor_malloc_zero(srclen);
for (j = 0; j < srclen; ++j) {
if (src[j] > 0x60 && src[j] < 0x7B) tmp[j] = src[j] - 0x61;
else if (src[j] > 0x31 && src[j] < 0x38) tmp[j] = src[j] - 0x18;
else {
log_warn(LD_BUG, "illegal character in base32 encoded string");
return -1;
}
}
...
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: ghazelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/527double-free in r118512020-06-27T14:10:33ZRoger Dingledinedouble-free in r11851moria1, running as a v3 authority, dumps core rarely with a glibc complaint:
*** glibc detected *** double free or corruption (out): 0x00002aaaaec6b500 ***
Aborted (core dumped)
Core was generated by `../or/tor -f moria1-orrc'.
Progra...moria1, running as a v3 authority, dumps core rarely with a glibc complaint:
*** glibc detected *** double free or corruption (out): 0x00002aaaaec6b500 ***
Aborted (core dumped)
Core was generated by `../or/tor -f moria1-orrc'.
Program terminated with signal 6, Aborted.
#0 0x00002b3ce904d07b in ?? ()
(gdb) where
#0 0x00002b3ce904d07b in ?? ()
#1 0x00002b3ce904e84e in ?? ()
legacy/trac#2 0x00007fffc2394590 in ?? ()
legacy/trac#3 0x00007fffc2394488 in ?? ()
legacy/trac#4 0x0000003000000018 in ?? ()
legacy/trac#5 0x00007fffc2394670 in ?? ()
legacy/trac#6 0x00007fffc23945b0 in ?? ()
legacy/trac#7 0x00002b3ce8c67b6f in ?? ()
legacy/trac#8 0x0000000000000000 in ?? ()
Last item in my info-level log was
Oct 12 02:42:13.225 [info] connection_or_check_valid_handshake(): Tried connecti
ng to router at 81.36.11.186:29001, but identity key was not as expected: wanted
FD00AAFFA74EEFD3797C78A16C0BCEDE0E016B8A but got BED56DA49ECE42B9059369DEB37E39
0F0F6EC2F5.
I don't know how to trigger it.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.8-alphahttps://gitlab.torproject.org/tpo/core/tor/-/issues/526Eventdns.c crash after closing and reopening ORPort2020-06-27T14:10:33ZNick MathewsonEventdns.c crash after closing and reopening ORPort[Originally reported by Mike Gersten; moving here so I don't forget about it.]
See or-dev thread from September-October titled "Tor crash", especially:
http://archives.seul.org/or/dev/Sep-2007/msg00031.html (initial post)
http://a...[Originally reported by Mike Gersten; moving here so I don't forget about it.]
See or-dev thread from September-October titled "Tor crash", especially:
http://archives.seul.org/or/dev/Sep-2007/msg00031.html (initial post)
http://archives.seul.org/or/dev/Sep-2007/msg00040.html (stack trace)
The circumstances were:
"I first shut down the Or-port, to try to let all connections close.
When it was time to actually say "Time to stop", I re-enabled the
Or-port, and then sent a sigint. (If I send sigint without first
re-enabling the or-port, Tor assumes that it should stop immediately,
without notifying the clients).
Tor crashed about a minute later. I don't know if it was related or not.
This is 1.2.17."
The stack trace was:
0 tor 0x00087c04 event_del + 44 (event.c:697)
1 tor 0x0006cdd4 nameserver_up + 84 (eventdns.c:533)
2 tor 0x0006cee0 reply_callback + 112 (eventdns.c:648)
3 tor 0x0006fc6c reply_handle + 684 (eventdns.c:740)
4 tor 0x000714cc nameserver_ready_callback + 1564
(eventdns.c:925)
5 tor 0x00087364 event_process_active + 240 (event.c:332)
6 tor 0x00087634 event_base_loop + 340 (event.c:448)
7 tor 0x000874cc event_loop + 40 (event.c:382)
8 tor 0x000873d0 event_dispatch + 20 (event.c:346)
9 tor 0x0004b8b0 tor_main + 656 (main.c:1270)
10 tor 0x0000277c _start + 760
11 tor 0x00002480 start + 48
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalNick MathewsonNick Mathewson