Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:10:12Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/806error during build on ming322020-06-27T14:10:12ZAndrew Lewmanerror during build on ming32When compiling tor 0.2.0.30 in mingw:
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I../common -I/usr/local/include -I/usr/local/ssl/include -I...When compiling tor 0.2.0.30 in mingw:
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I../common -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/include -g -O2 -Wall -g -O2 -MT config.o -MD -MP -MF .deps/config.Tpo -c -o config.o config.c
config.c: In function `options_act':
config.c:1268: warning: initialization makes integer from pointer without a cast
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/804seg fault on r16563 v3 authority2020-06-27T14:10:12ZRoger Dingledineseg fault on r16563 v3 authoritymoria1 on Tor 0.2.1.4-alpha-dev (r16563)
Aug 16 20:55:01.039 [notice] Time to compute a consensus.
Aug 16 20:55:01.039 [info] networkstatus_compute_consensus(): Generating consens
us using method 3.
#0 0x00002b93dfb35580 in strlen () ...moria1 on Tor 0.2.1.4-alpha-dev (r16563)
Aug 16 20:55:01.039 [notice] Time to compute a consensus.
Aug 16 20:55:01.039 [info] networkstatus_compute_consensus(): Generating consens
us using method 3.
#0 0x00002b93dfb35580 in strlen () from /lib/libc.so.6
#1 0x00002b93dfb07560 in vfprintf () from /lib/libc.so.6
legacy/trac#2 0x00002b93dfb276fa in vsnprintf () from /lib/libc.so.6
legacy/trac#3 0x00000000004963e3 in tor_vsnprintf (
str=0x7fffcb8f1900 "p Bandwidth=6266160\n", size=4981567,
format=0x7fffcb8f0201 "3\v\002", args=0x5) at compat.c:340
legacy/trac#4 0x0000000000496481 in tor_snprintf (
str=0x2b9300002b93 <Address 0x2b9300002b93 out of bounds>, size=4981567,
format=0x7fffcb8f0201 "3\v\002") at compat.c:321
legacy/trac#5 0x000000000044dbf0 in networkstatus_compute_consensus (votes=0x16a4d00,
total_authorities=6, identity_key=0x62c0e0, signing_key=0x62bff0,
legacy_id_key_digest=0x0, legacy_signing_key=0x0) at dirvote.c:1049
legacy/trac#6 0x000000000044ec11 in dirvote_act (options=0x5faf00, now=1218934501)
at dirvote.c:1907
legacy/trac#7 0x0000000000459213 in second_elapsed_callback (fd=<value optimized out>,
event=<value optimized out>, args=<value optimized out>) at main.c:1067
legacy/trac#8 0x00002b93df3e90e2 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#9 0x00000000004599f8 in do_main_loop () at main.c:1459
legacy/trac#10 0x0000000000459b95 in tor_main (argc=3, argv=<value optimized out>)
at main.c:2025
legacy/trac#11 0x00002b93dfadf4ca in __libc_start_main () from /lib/libc.so.6
legacy/trac#12 0x0000000000406b0a in _start () at ../sysdeps/x86_64/elf/start.S:113
legacy/trac#3 0x00000000004963e3 in tor_vsnprintf (
str=0x7fffcb8f1900 "p Bandwidth=6266160\n", size=4981567,
format=0x7fffcb8f0201 "3\v\002", args=0x5) at compat.c:340
340 r = vsnprintf(str, size, format, args);
legacy/trac#5 0x000000000044dbf0 in networkstatus_compute_consensus (votes=0x16a4d00,
total_authorities=6, identity_key=0x62c0e0, signing_key=0x62bff0,
legacy_id_key_digest=0x0, legacy_signing_key=0x0) at dirvote.c:1049
1049 int r = tor_snprintf(buf, sizeof(buf), "p %s\n", rs_out.exitsummary);
(gdb) print buf
$7 = 6401584
(gdb) print sizeof(buf)
$8 = 4
(gdb) print rs_out
No symbol "rs_out" in current context.
(another victim of optimization i guess)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/803assert in routerstatus_format_entry()2020-06-27T14:10:12ZRoger Dingledineassert in routerstatus_format_entry()r16563.
Aug 16 18:42:00.186 [] Downloading consensus from 82.94.251.204:443 using /tor/s
tatus-vote/current/consensus/14C131+27B6B5+585769+81349F+E2A2AF+E8A9C4.z
Aug 16 19:33:57.203 [] routerstatus_format_entry(): Bug: Cannot get the de...r16563.
Aug 16 18:42:00.186 [] Downloading consensus from 82.94.251.204:443 using /tor/s
tatus-vote/current/consensus/14C131+27B6B5+585769+81349F+E2A2AF+E8A9C4.z
Aug 16 19:33:57.203 [] routerstatus_format_entry(): Bug: Cannot get the descript
or with digest 009CF1422D2244E918B4530A673871D46009B752 for 5193811E81189B705618
C7DB16BE3B48170C2800.
Aug 16 19:33:57.208 [] routerstatus_format_entry(): Bug: descriptor digest in ro
uterlist does not match the one in routerstatus: 33503E7B5447030D4289F465F2BD0A0
44781B34E vs 78DB41D7DAA1B80572FB422E789FBDBCEF456C68
Aug 16 19:33:57.212 [] Bug: dirserv.c:1966: routerstatus_format_entry: Assertion
!memcmp(desc->cache_info.signed_descriptor_digest, rs->descriptor_digest, DIGES
T_LEN) failed; aborting.
#0 0xb7fd1410 in ?? ()
#1 0xbfe9327c in ?? ()
legacy/trac#2 0x00000006 in ?? ()
legacy/trac#3 0x00001144 in ?? ()
legacy/trac#4 0xb7d01811 in raise () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#5 0xb7d02fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#6 0x08093bd4 in routerstatus_format_entry (
buf=0xbfe93541 "r agate ATQMjN9ekLnU/xrr3KQDzS/25WI eNtB19qhuAVy+0IueJ+9vO9FbGg 2008-08-16 20:14:41 193.202.115.224 9001 0\ns Running Unnamed Valid\n",
buf_len=1379, rs=0x88f9918, version=0x0, first_line_only=0, v2_format=0)
at dirserv.c:1964
legacy/trac#7 0x080ab8da in networkstatus_getinfo_helper_single (rs=0x88f9918)
at networkstatus.c:1782
legacy/trac#8 0x080ad1e7 in getinfo_helper_networkstatus (conn=0x8663de0,
question=0x8170880 "ns/all", answer=0xbfe93be0) at networkstatus.c:1862
legacy/trac#9 0x08086535 in connection_control_process_inbuf (conn=0x8663de0)
at control.c:1976
legacy/trac#10 0x08070c68 in connection_process_inbuf (conn=0x8663de0, package_partial=6)
at connection.c:2733
legacy/trac#11 0x080729b1 in connection_handle_read (conn=0x8663de0) at connection.c:1931
legacy/trac#12 0x080ab5c8 in conn_read_callback (fd=10, event=2, _conn=0x8663de0)
at main.c:458
legacy/trac#13 0xb7f9cc79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
legacy/trac#14 0xb7f9cf65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#15 0xb7f9cdcb in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#16 0x080ab10f in do_main_loop () at main.c:1459
legacy/trac#17 0x080ab2e5 in tor_main (argc=11, argv=0xbfe93e64) at main.c:2025
legacy/trac#18 0x080e5b92 in main (argc=Cannot access memory at address 0x1144
) at tor_main.c:29
legacy/trac#6 0x08093bd4 in routerstatus_format_entry (
buf=0xbfe93541 "r agate ATQMjN9ekLnU/xrr3KQDzS/25WI eNtB19qhuAVy+0IueJ+9vO9FbGg 2008-08-16 20:14:41 193.202.115.224 9001 0\ns Running Unnamed Valid\n",
buf_len=1379, rs=0x88f9918, version=0x0, first_line_only=0, v2_format=0)
at dirserv.c:1964
1964 tor_assert(!memcmp(desc->cache_info.signed_descriptor_digest,
(gdb) print *rs
$4 = {published_on = 1218917681, nickname = "agate", '\0' <repeats 14 times>,
identity_digest = "\0014\f\214ß!^\220¹Ôÿ\032ëܤ\003Í/öåb",
descriptor_digest = "xÛA×Ú¡¸\005rûB.x\237½¼ïElh", addr = 3251270624,
or_port = 9001, dir_port = 0, is_authority = 0, is_exit = 0, is_stable = 0,
is_fast = 0, is_running = 1, is_named = 0, is_unnamed = 1, is_valid = 1,
is_v2_dir = 0, is_possible_guard = 0, is_bad_exit = 0, is_bad_directory = 0,
is_hs_dir = 0, version_known = 1, version_supports_begindir = 1,
version_supports_conditional_consensus = 0,
version_supports_extrainfo_upload = 1, version_supports_v3_dir = 1,
has_bandwidth = 0, has_exitsummary = 0, bandwidth = 0, exitsummary = 0x0,
need_to_mirror = 0, name_lookup_warned = 0, last_dir_503_at = 0,
dl_status = {next_attempt_at = 0, n_download_failures = 0 '\0',
schedule = DL_SCHED_GENERIC}}
(gdb) print desc
No symbol "desc" in current context.
(darn optimizer)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/802BandwidthBurst rate being used constantly2020-06-27T14:10:12Zmicahmicah@torproject.orgBandwidthBurst rate being used constantlyI have three machines, all configured exactly the same way acting as round-robin web servers. They get an even distribution
of traffic, averaging 50kbps in and 200kbps out and have had an even distribution amongst the nodes for a year an...I have three machines, all configured exactly the same way acting as round-robin web servers. They get an even distribution
of traffic, averaging 50kbps in and 200kbps out and have had an even distribution amongst the nodes for a year and a half.
I installed tor on one of the nodes to test an exit enclave setup, with the idea that if it worked well, I would deploy it
to the other nodes (as well as elsewhere). I used the following configuration:
SocksPort 0 # what port to open for local application connections
SocksListenAddress 127.0.0.1 # accept connections only from localhost
Log notice syslog
RunAsDaemon 1
DataDirectory /var/lib/tor
Nickname auk
Address my.ip.here
OutboundBindAddress my.ip.here
ContactInfo my.contact.info.here
ORPort 9001
ExitPolicyRejectPrivate 0
ExitPolicy accept my.ip.here:80
ExitPolicy accept my.ip.here:443
ExitPolicy reject *:*
BandwidthRate 250 KB
BandwidthBurst 1MB
As you can see, I set BandwidthBurst to 1MB, and BadwidthRate to be 250KB, but looking at my bandwidth usage
statistics, I see that this node is using 1MB the entire time, averaging 872kbps in and 1.03M out (almost always at
this rate, with some fluctuations up to 2.35M in and 2.71M out.
This doesn't seem like what I would expect for these bandwidth settings, I could be misunderstanding how these
are applied, and if so please tell me what I am missing.
Thanks for your work on tor, its appreciated!
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/core/tor/-/issues/799Aug 12 16:37:07.937 [Fehler] Error from libevent: evsignal_init: socketpair: ...2020-06-27T14:10:13ZTracAug 12 16:37:07.937 [Fehler] Error from libevent: evsignal_init: socketpair: No errorVidalia can not start TOR.
See report.
Aug 12 16:37:07.937 [Fehler] Error from libevent: evsignal_init: socketpair: No error
How can I sart TOR?
Thanks for soloutiones.
[Automatically added by flyspray2trac: Operating System: Window...Vidalia can not start TOR.
See report.
Aug 12 16:37:07.937 [Fehler] Error from libevent: evsignal_init: socketpair: No error
How can I sart TOR?
Thanks for soloutiones.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: leMaximumhttps://gitlab.torproject.org/tpo/core/tor/-/issues/797FastFirstHopPK 0 prevents tunneled directory connections from working.2020-06-27T14:10:13ZNick MathewsonFastFirstHopPK 0 prevents tunneled directory connections from working.See Erwin Lam's email from 3 August 2008 on or-talk:
http://archives.seul.org/or/talk/Aug-2008/msg00010.html
It seems that in some cases we build a one-hop circuit to a server without putting its onion key in the
extend_info. This h...See Erwin Lam's email from 3 August 2008 on or-talk:
http://archives.seul.org/or/talk/Aug-2008/msg00010.html
It seems that in some cases we build a one-hop circuit to a server without putting its onion key in the
extend_info. This happens _at least_ when we don't know any onion key for the server, because we are
connecting to it for directory information and we don't have any descriptors yet.
You can test this yourself: run with -FastFirstHopPK 0, with a new empty datadirectory (to avoid cached data),
and with no other options set.
The right fix is probably to override should_use_create_fast_for_router so that it uses a create_fast cell
for one-hop tunnels when no onion key is known, even if FastFirstHopPK 0 is set.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/784unclear error message: crash state conflict2020-06-27T14:10:13ZTracunclear error message: crash state conflictThis concerns the tor button, sorry to file this report under tor client.
After some weird firefox behaviour (couldn't switch tabs anymore) i closed and reopened firefox which led to the following error message:
Crash state conflict! ...This concerns the tor button, sorry to file this report under tor client.
After some weird firefox behaviour (couldn't switch tabs anymore) i closed and reopened firefox which led to the following error message:
Crash state conflict! Please file bug report with these four values: false,false,false,true
It is obvious to me that i don't get to make any decissions here because i'm not part of this project, but the source of this error message was really hard to track down, it didn't mention at all that it was produced by the tor button.
I really wish this gets immediate fixing, because it makes firefox look unstable when it is acutally a tor button error.
(i only found out this is produced by the tor button because of a google search http://www.google.at/search?q=%22Crash+state+conflict!)
all the best,
hansi.
p.s. nevertheless... great work on tor!
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: kritzikratzihttps://gitlab.torproject.org/tpo/core/tor/-/issues/783contact2020-06-27T14:10:14ZTraccontactAm trying to act as a relay to help Tor. Relay button doesn't work. High speed microwave ISP with 0 latency
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: mhetheringtonAm trying to act as a relay to help Tor. Relay button doesn't work. High speed microwave ISP with 0 latency
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: mhetheringtonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/782Patch: Open /dev/pf before dropping privileges with TransPort2020-06-27T14:10:14ZTracPatch: Open /dev/pf before dropping privileges with TransPortCurrently, when using TransPort and OpenBSD pf, Tor opens /dev/pf
after dropping privileges, so the permissions on /dev/pf must be
modified to allow access to the unprivileged Tor user.
The patch should ensure that /dev/pf is opened w...Currently, when using TransPort and OpenBSD pf, Tor opens /dev/pf
after dropping privileges, so the permissions on /dev/pf must be
modified to allow access to the unprivileged Tor user.
The patch should ensure that /dev/pf is opened while Tor is still
running as root.
Note: diff is to trunk
Index: src/or/config.c
===================================================================
--- src/or/config.c (revision 16230)
+++ src/or/config.c (working copy)
@@ -1060,6 +1060,16 @@
}
}
+#if defined(HAVE_NET_IF_H) && defined(HAVE_NET_PFVAR_H)
+ /* Open /dev/pf before dropping privileges. */
+ if (options->TransPort) {
+ if (get_pf_socket() < 0) {
+ *msg = tor_strdup("Unable to open /dev/pf for transparent proxy.");
+ goto rollback;
+ }
+ }
+#endif
+
/* Setuid/setgid as appropriate */
if (options->User || options->Group) {
/* XXXX021 We should only do this the first time through, not on
Index: src/or/connection_edge.c
===================================================================
--- src/or/connection_edge.c (revision 16230)
+++ src/or/connection_edge.c (working copy)
@@ -1641,8 +1641,7 @@
#ifdef TRANS_PF
static int pf_socket = -1;
-static int
-get_pf_socket(void)
+int get_pf_socket(void)
{
int pf;
/* Ideally, this should be opened before dropping privs. */
Index: src/or/or.h
===================================================================
--- src/or/or.h (revision 16230)
+++ src/or/or.h (working copy)
@@ -2939,6 +2939,10 @@
} hostname_type_t;
hostname_type_t parse_extended_hostname(char *address);
+#if defined(HAVE_NET_IF_H) && defined(HAVE_NET_PFVAR_H)
+int get_pf_socket(void);
+#endif
+
/********************************* connection_or.c ***************************/
void connection_or_remove_from_identity_map(or_connection_t *conn);
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: loafierNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/781segfault in libz2020-06-27T14:10:14ZTracsegfault in libzI'm using Version: 0.2.0.30-2~~etch+1 from http://mirror.noreply.org/pub/tor
Jul 20 22:30:39 magnesium Tor[31470]: Your Tor server's identity key fingerprint is 'nirgal 05F2 1249 3535 17EB 6205 0CF3 B309 7392 3F61 5B1C'
Jul 20 22:30:51 ...I'm using Version: 0.2.0.30-2~~etch+1 from http://mirror.noreply.org/pub/tor
Jul 20 22:30:39 magnesium Tor[31470]: Your Tor server's identity key fingerprint is 'nirgal 05F2 1249 3535 17EB 6205 0CF3 B309 7392 3F61 5B1C'
Jul 20 22:30:51 magnesium Tor[31470]: We now have enough directory information to build circuits.
Jul 20 22:30:51 magnesium Tor[31470]: Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jul 20 22:30:53 magnesium Tor[31470]: Tor has successfully opened a circuit. Looks like client functionality is working.
Jul 20 22:31:58 magnesium Tor[31470]: Performing bandwidth self-test...done.
Jul 20 22:32:23 magnesium Tor[31470]: Self-testing indicates your DirPort is reachable from the outside. Excellent.
Jul 23 07:11:00 magnesium kernel: [722001.420438] tor[31470]: segfault at 9ac7669c ip b7f9988e sp bf9c4850 error 4 in libz.so.1.2.3[b7f94000+13000]
I'm not sure that repport helps a lot...
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: nirgalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/779Don't cross the exit streams!2020-06-27T14:10:14ZRoger DingledineDon't cross the exit streams!slush reports in
http://archives.seul.org/or/talk/Jul-2008/msg00061.html
that when he makes 300 circuits in a quick amount of time, then
refreshes his page, he gets a page with some content from a different
stream in it. See e.g. http:/...slush reports in
http://archives.seul.org/or/talk/Jul-2008/msg00061.html
that when he makes 300 circuits in a quick amount of time, then
refreshes his page, he gets a page with some content from a different
stream in it. See e.g. http://www.slush.cz/centrumyahoo.png for an
example.
Jens has independently reported this too.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/775tor crash on libevent error2020-06-27T14:10:14ZTractor crash on libevent errorJul 15 03:44:56.239 [notice] Tor 0.2.0.28-rc (r15188) opening new log file.
...
Jul 15 18:53:24.691 [err] Error from libevent: event_queue_remove: 0x9c331c38(fd 0) not on queue 1
...
Jul 17 11:58:35.282 [notice] Tor 0.2.1.2-alpha (r15383...Jul 15 03:44:56.239 [notice] Tor 0.2.0.28-rc (r15188) opening new log file.
...
Jul 15 18:53:24.691 [err] Error from libevent: event_queue_remove: 0x9c331c38(fd 0) not on queue 1
...
Jul 17 11:58:35.282 [notice] Tor 0.2.1.2-alpha (r15383) opening log file.
...
Jul 17 23:33:22.515 [err] Error from libevent: event_queue_remove: 0xb2797c38(fd 0) not on queue 1
Hello,
since the last two days i've the same error on mxr running on a debian hardy with all standard scripts.
I've no change in the config since some days.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: amishttps://gitlab.torproject.org/tpo/core/tor/-/issues/771TLS no-compression is distinguishable?2020-06-27T14:10:14ZRoger DingledineTLS no-compression is distinguishable?We turned off TLS compression in Tor 0.2.1.1-alpha:
- Never use OpenSSL compression: it wastes RAM and CPU trying to
compress cells, which are basically all encrypted, compressed,
or both.
but it would appear that this is...We turned off TLS compression in Tor 0.2.1.1-alpha:
- Never use OpenSSL compression: it wastes RAM and CPU trying to
compress cells, which are basically all encrypted, compressed,
or both.
but it would appear that this isn't what Firefox and Apache do. How
noticeable is this?
See also http://archives.seul.org/or/talk/Jun-2008/msg00188.html
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/768one-hop circuit restriction should not apply to special-purpose routers2020-06-27T14:10:14Zgoodellone-hop circuit restriction should not apply to special-purpose routersAt some point (r9735?), code was added to src/or/control.c that prevents
controllers from attaching streams to one-hop circuits. The idea seems to be
that we can use the cost of forking and maintaining a patch as a lever to
prevent peo...At some point (r9735?), code was added to src/or/control.c that prevents
controllers from attaching streams to one-hop circuits. The idea seems to be
that we can use the cost of forking and maintaining a patch as a lever to
prevent people from writing controllers that jeopardize the operational
security of routers and the anonymity properties of the Tor network by creating
and using one-hop circuits rather than the standard three-hop circuits. It may
be, for example, that some users do not actually seek true anonymity but simply
reachability through network perspectives afforded by the Tor network, and
since anonymity is stronger in numbers, forcing users to contribute to
anonymity and decrease the risk to server operators by using full-length paths
may be reasonable.
Whether or not we agree that the particular approach of using hardcoded,
immutable policy in the Tor client to limit self-determinism on the part of
clients is the right way to address the risks posed by one-hop circuit
utilization (for example, I think that routers ought to take responsibility for
ensuring that they are not allowing exit from one-hop circuits), it remains
true that as presently implemented, the sweeping restriction of one-hop
circuits for all routers limits the usefulness of Tor as a general-purpose
technology for building circuits. In particular, we should allow for
controllers, such as Blossom, that create and use single-hop circuits involving
routers that are not part of the Tor network.
There are several ways to address the problem while maintaining the approach of
using hardcoded restrictions in the client code. The simplest solution is to
just have a new configuration parameter that allows the attachment of streams
to one-hop circuits. An objection to that approach might be that the abusive
controllers will simply set the configuration paramter and carry on. Another
solution is to require that we can only exit from one-hop circuits if the
(single) router in the circuit has a descriptor whose associated purpose is not
general. Again, controllers can set purposes on descriptors, or feed the Tor
descriptors via POSTDESCRIPTOR, so controllers could still be abusive, but the
overhead would be somewhat greater.
A third solution is to require descriptors to have a special option that
indicates to the client that they can be used in one-hop circuits, and have
clients object, as they do now for all routers, to attaching streams to one-hop
circuits for routers that do not have this option set. That solution seems to
eliminate the worry about operational router security, since server operators
will not set this bit unless they are willing to take on such risk. If we
worry about the impact on anonymity of the network resulting from including
such "risky" routers in regular Tor path selection, we can just systematically
exclude those.
Tactically, we should do something to allow Blossom to say "yes, I really do
mean to use this one-hop circuit." What is the right way to achieve this in
the short-term?
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/767Rendezvous Descriptor Upload Failures2020-06-27T14:10:14ZKarsten LoesingRendezvous Descriptor Upload FailuresRoger Dingledine wrote on June 20, 2008:
> It looks like hid_serv_get_responsible_directories() looks at
> routerstatus entries, but ignores whether we actually have descriptors.
> So if I don't have the descriptor it chooses, I end up w...Roger Dingledine wrote on June 20, 2008:
> It looks like hid_serv_get_responsible_directories() looks at
> routerstatus entries, but ignores whether we actually have descriptors.
> So if I don't have the descriptor it chooses, I end up with this in my
> logs:
>
> Jun 19 19:21:22.045 [warn] Requested exit point
> '$68333D0761BCF397A587A0C0B963E4A9E99EC4D3' is not known. Closing.
> Jun 19 19:21:22.045 [warn] Making tunnel to dirserver failed.
Right, that's the same bug that is described in the NLnet mid-June report:
"Descriptor Upload Failures: The current logic to upload rendezvous service
descriptors does not handle failures in a reasonable way. In case of a
failure, Tor waits for a solid hour before making the next attempt. There
should either be a smaller timeout or an individual handling of failures
per directory."
In the mid-June measurements and when using v0 rendezvous descriptors this
bug affected 481 of 3270 cases (14.7 %); only in very few cases it affected
all three hidden service authorities and became visible, because clients
couldn't access the hidden service. In my yesterday evaluations with v2
rendezvous descriptors, this bug occurred in 1298 out of 9460 attempts
(13.7 %). This means we really need to fix this bug to increase
reliability.
The fix you suggested above only avoids those nasty warnings and
unnecessary upload attempts, but it doesn't help to maintain rendezvous
descriptor availability.
My first idea was to put all upload attempts that cannot be performed due
to missing router descriptors in a queue. As soon as new router descriptors
arrive, this queue should be checked, and rendezvous descriptors be
uploaded.
However, this idea does not work. Tor doesn't seem to make any attempts to
download missing router descriptors when it thinks it has enough (I'm not
so sure about its behavior, could you confirm?). In one test case a Tor
providing a hidden service failed to upload v0 rendezvous descriptors to
the three hidden service authorities for more than two hours.
So, my second idea was to request router descriptors as soon as we realize
that we need them and implement the queuing idea, so that a second attempt
will be performed as soon as router descriptors have arrived.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/763Inaccuracies in Rendezvous Descriptor Upload Logic2020-06-27T14:10:15ZKarsten LoesingInaccuracies in Rendezvous Descriptor Upload LogicThe current logic for publishing a rendezvous service descriptor is to wait
for 30 seconds after the last change to the set of introduction points.
However, in an evaluation it was found that in some test cases these
30 seconds were exce...The current logic for publishing a rendezvous service descriptor is to wait
for 30 seconds after the last change to the set of introduction points.
However, in an evaluation it was found that in some test cases these
30 seconds were exceeded: In one test case, there was a 34 seconds gap
inbetween two introduction establishments, but without an attempt to upload
a descriptor. In another case, a descriptor was not uploaded until
41 seconds after an introduction point establishment.
An inspection of the log files revealed that the abandoning of an
introduction point *candidate* resets the 30-seconds counter, too, even
though it would have no effect on the uploaded descriptor. Hence, given
that the 30-seconds delay is a useful means to estimate when a descriptor
is stable, the 30-seconds counter should only be reset when an actual
change to the descriptor to be uploaded occurs.
A possible fix is to check whether an introduction point that is given up
was contained in the last published descriptor. Only in that case, the
descriptor should be marked as dirty and the 30-seconds countdown started.
A bugfix is attached below. Backport candidate for 0.2.0.x.
Index: /home/karsten/tor/tor-trunk/src/or/rendservice.c
===================================================================
--- /home/karsten/tor/tor-trunk/src/or/rendservice.c (revision 15806)
+++ /home/karsten/tor/tor-trunk/src/or/rendservice.c (working copy)
@@ -1260,10 +1260,20 @@
service->descriptor_version)) {
log_info(LD_REND,"Giving up on %s as intro point for %s.",
intro->extend_info->nickname, service->service_id);
+ if (service->desc) {
+ SMARTLIST_FOREACH(service->desc->intro_nodes, rend_intro_point_t *, dintro, {
+ if (!memcmp(dintro->extend_info->identity_digest,
+ intro->extend_info->identity_digest, DIGEST_LEN)) {
+ log_info(LD_REND, "The intro point we are giving up was included "
+ "in the last published descriptor. Marking "
+ "current descriptor as dirty.");
+ service->desc_is_dirty = now;
+ }
+ });
+ }
rend_intro_point_free(intro);
smartlist_del(service->intro_nodes,j--);
changed = 1;
- service->desc_is_dirty = now;
}
smartlist_add(intro_routers, router);
}
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/759Vidalia hangs and consumes 100% cpu during initialization2020-06-27T14:10:15ZTracVidalia hangs and consumes 100% cpu during initializationI have just installed the latest version of the Vidalia bundle on my fresh install of windows xp sp2.
When ever I try to start the application it just hangs and consumes all available processor memory,
and the Vidalia Control Panel windo...I have just installed the latest version of the Vidalia bundle on my fresh install of windows xp sp2.
When ever I try to start the application it just hangs and consumes all available processor memory,
and the Vidalia Control Panel window turns white forcing me to kill the proc with taskmanager.
I waited several minutes assuming that it may indeed be my old Pentium 3 slowly creeping along,
but the application never freed up the memory and failed to properly initialize
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: suomynonahttps://gitlab.torproject.org/tpo/core/tor/-/issues/754RendNodes configuration option is ignored2020-06-27T14:10:15ZTracRendNodes configuration option is ignoredThe RendNodes configuration option should enable users to specify a list of relays that are preferred as rendezvous
node when establishing a connection to a hidden service. It was added with revision 1433 in version 0.0.6pre1.
But the c...The RendNodes configuration option should enable users to specify a list of relays that are preferred as rendezvous
node when establishing a connection to a hidden service. It was added with revision 1433 in version 0.0.6pre1.
But the configuration option is currently ignored, because it is used in the choose_good_exit_server()
function in circuitbuild.c only. Since cannibalization was introduced in version 0.1.0.1-rc, this method isn't used
for establishing rendezvous and introduction circuits anymore. Now the circuits are selected in the
circuit_find_to_cannibalize() function in circuitlist.c, where pre-built 3-hop circuits are either extended to a known
introduction point or just declared as rendezvous circuit with the third hop automatically being the rendezvous point.
Therefore enabling the the configuration option has no effect on the chosen rendezvous point.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: chriswhttps://gitlab.torproject.org/tpo/core/tor/-/issues/748Limit verbosity of [warn] Failing because we have 991 connections already. Pl...2020-06-27T14:10:15ZTracLimit verbosity of [warn] Failing because we have 991 connections already. Please raise your ulimitHello, on a standard log Tor usage ( notice mode only) the verbosity of
[warn] Failing because we have 991 connections already. Please raise your ulimit -n.
Can block a server by disk /var saturation.
Yes, i now w that you can separe t...Hello, on a standard log Tor usage ( notice mode only) the verbosity of
[warn] Failing because we have 991 connections already. Please raise your ulimit -n.
Can block a server by disk /var saturation.
Yes, i now w that you can separe that, and make a good machine configuration,
but all we experienced that many users are not like that.
So can we reduce logs like that to something like ( repeted x times).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: amishttps://gitlab.torproject.org/tpo/core/tor/-/issues/743Handle Reception of RENDEZVOUS_ESTABLISHED and RENDEZVOUS2 cells immediately2020-06-27T14:10:15ZTracHandle Reception of RENDEZVOUS_ESTABLISHED and RENDEZVOUS2 cells immediatelyTwo client-side events during hidden-service establishment are not
handled event-based, but observed by the one second loop in main.c. This
leads to unnecessary delays of hidden-service establishment up to two
seconds together.
While ot...Two client-side events during hidden-service establishment are not
handled event-based, but observed by the one second loop in main.c. This
leads to unnecessary delays of hidden-service establishment up to two
seconds together.
While other events like finishing to establish the introduction circuit
in rend_client_introcirc_has_opened() call the function
connection_ap_attach_pending() to proceed immediately, for two events
this does not happen. Therefore the protocol proceeds after the one
second loop has checked, if anything has changed. Depending on when the
event occurs this check can happen anytime between zero and one second
after the event.
One of the two events is the reception of a RENDEZVOUS2 cell in
rend_client_receive_rendezvous().
The other situation containing the bug only occurs if the introduction
circuit is established before the RENDEZVOUS_ESTABLISHED cell is
received. If establishing the introduction circuit takes longer than
sending the ESTABLISH_RENDEZVOUS cell and receiving the acknowledgment,
everything is fine, because as mentioned before the
rend_client_introcirc_has_opened() function initiates further steps. The
buggy sequence of those events occurred in 28 per cent of 1,200 hidden
service access attempts.
To fix this bug the connection_ap_attach_pending() function needs to be
called after receiving RENDEZVOU2 and RENDEZVOUS_ESTABLISHED cells, too.
The bug was introduced in revision 817, when the
connection_ap_attach_pending() function was called in the main loop for
the first time.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: chrisw