Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:01:48Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14802Return 0 when we fail to get the amount of system memory on some obscure OS2020-06-27T14:01:48ZMatthew FinkelReturn 0 when we fail to get the amount of system memory on some obscure OSCurrently we incorrectly return -1 when sysctl fails in
```
#elif defined(HAVE_SYSCTL) && defined(HW_PHYSMEM)
/* On some systems (like FreeBSD I hope) you can use a size_t with
* HW_PHYSMEM. */
size_t memsize=0;
size_t len = siz...Currently we incorrectly return -1 when sysctl fails in
```
#elif defined(HAVE_SYSCTL) && defined(HW_PHYSMEM)
/* On some systems (like FreeBSD I hope) you can use a size_t with
* HW_PHYSMEM. */
size_t memsize=0;
size_t len = sizeof(memsize);
int mib[2] = {CTL_HW, HW_USERMEM};
if (sysctl(mib,2,&memsize,&len,NULL,0))
return -1;
return memsize;
```Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14798Avoid calling SMARTLIST_FOREACH on a NULL smartlist in tests2020-06-27T14:01:48ZteorAvoid calling SMARTLIST_FOREACH on a NULL smartlist in testsTwo of the test functions could possibly call SMARTLIST_FOREACH on a NULL smartlist.
This branch fixes the issue:
**Repository:** https://github.com/teor2345/tor.git
**Branch:** avoid-NULL-smartlist-foreach
Check if each smartlist ...Two of the test functions could possibly call SMARTLIST_FOREACH on a NULL smartlist.
This branch fixes the issue:
**Repository:** https://github.com/teor2345/tor.git
**Branch:** avoid-NULL-smartlist-foreach
Check if each smartlist is NULL before calling SMARTLIST_FOREACH on it.
Bug discovered by the clang static analyzer.
Apple clang 600.0.56 (LLVM 3.5svn) on x86_64-apple-darwin14.1.0.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14786two random spec fixes2020-06-27T14:01:49ZSebastian Hahntwo random spec fixesBranch random_spec_fixes in my repo.Branch random_spec_fixes in my repo.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14764powerpc32 compilation failures due to char signedness issues.2020-06-27T14:01:49ZYawning Angelpowerpc32 compilation failures due to char signedness issues.Originally reported in: https://lists.torproject.org/pipermail/tor-dev/2015-February/008231.html
One of the scheduler functions uses a `char` as an argument to pass a `-1`/`1` value, which causes GCC to issue warnings on platforms where...Originally reported in: https://lists.torproject.org/pipermail/tor-dev/2015-February/008231.html
One of the scheduler functions uses a `char` as an argument to pass a `-1`/`1` value, which causes GCC to issue warnings on platforms where `char` defaults to unsigned. While the patch does address the issue, after discussion with nickm, the argument is better changed to an int.Tor: 0.2.6.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14759Tor is killed with Bad system call2020-06-27T14:01:49ZTracTor is killed with Bad system callI've setup a tor bridge but it dies with "Bad system call" after a few days. This is likely because I use the sandbox.
The log output is:
```
Feb 05 05:41:47.000 [notice] Heartbeat: Tor's uptime is 6 days 18:00 hours, with 1 circuits op...I've setup a tor bridge but it dies with "Bad system call" after a few days. This is likely because I use the sandbox.
The log output is:
```
Feb 05 05:41:47.000 [notice] Heartbeat: Tor's uptime is 6 days 18:00 hours, with 1 circuits open. I've sent 23.40 MB and received 213.94 MB.
Feb 05 05:41:47.000 [notice] Average packaged cell fullness: 87.064%
Feb 05 05:41:47.000 [notice] TLS write overhead: 6%
Bad system call
```
This happens with both tor-0.2.5.10 and tor-0.2.6.2-alpha. Both dies after 6 days 18:00 hours uptime. I'm currently testing latest git but it will probably take 6 days before I know if it works. After tor has been killed it will again die with Bad system call if I try to restart it. After restarting it a few times it will successfully start but die after 6 days.
The log when restarting:
```
Feb 06 13:45:14.593 [notice] Tor v0.2.6.2-alpha (git-6cb1daf062df5252) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.1k and Zlib 1.2.8.
Feb 06 13:45:14.594 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 06 13:45:14.594 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 06 13:45:14.594 [notice] Read configuration file "/etc/tor/torrc".
Feb 06 13:45:14.619 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
Feb 06 13:45:14.619 [notice] MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 06 13:45:14.622 [notice] Opening OR listener on 0.0.0.0:443
Feb 06 13:45:14.623 [notice] Caching new entry tor for tor
Feb 06 13:45:14.624 [notice] Caching new entry tor for tor
Feb 06 13:45:14.593 [notice] Tor v0.2.6.2-alpha (git-6cb1daf062df5252) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.1k and Zlib 1.2.8.
Feb 06 13:45:14.594 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 06 13:45:14.594 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Feb 06 13:45:14.594 [notice] Read configuration file "/etc/tor/torrc".
Feb 06 13:45:14.619 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
Feb 06 13:45:14.619 [notice] MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Feb 06 13:45:14.622 [notice] Opening OR listener on 0.0.0.0:443
Feb 06 13:45:14.623 [notice] Caching new entry tor for tor
Feb 06 13:45:14.624 [notice] Caching new entry tor for tor
Feb 06 13:45:14.000 [notice] Not disabling debugger attaching for unprivileged users.
Feb 06 13:45:14.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Feb 06 13:45:14.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Feb 06 13:45:15.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Feb 06 13:45:15.000 [notice] Your Tor server's identity key fingerprint is '<REDACTED>'
Feb 06 13:45:15.000 [notice] Your Tor bridge's hashed identity key fingerprint is '<REDACTED>'
Feb 06 13:45:15.000 [notice] Bootstrapped 0%: Starting
Feb 06 13:45:21.000 [notice] Bootstrapped 5%: Connecting to directory server
Feb 06 13:45:21.000 [notice] Signaling readyness to systemd
Feb 06 13:45:21.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Feb 06 13:45:21.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection
Feb 06 13:45:21.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus
Feb 06 13:45:21.000 [notice] Bootstrapped 50%: Loading relay descriptors
Bad system call (core dumped)
```
I'm running an Arch Linux system with tor running in a chroot according to the instructions on the arch wiki.
torrc
```
SocksPort 0
ORPort 443
BridgeRelay 1
Exitpolicy reject *:*
BandwidthRate 200 KBytes
BandwidthBurst 10 MBits
User tor
Sandbox 1
Log notice stdout
DisableDebuggerAttachment 0
```
DisableDebuggerAttachment was added to get a coredump.
Here is some of the info from the coredump with potentially sensitive data redacted.
```
# gdb torchroot/usr/bin/tor torchroot/tmp/core.tor.11879.1423224556
GNU gdb (GDB) 7.8.2
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from torchroot/usr/bin/tor...done.
[New LWP 11880]
[New LWP 11879]
[New LWP 11881]
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/bin/tor'.
Program terminated with signal SIGSYS, Bad system call.
#0 0x00007f179c9c9200 in __open_nocancel () from /usr/lib/libc.so.6
(gdb) info threads
Id Target Id Frame
3 Thread 0x7f1798a57700 (LWP 11881) 0x00007f179cea46bf in recv ()
from /usr/lib/libpthread.so.0
2 Thread 0x7f179e2c1700 (LWP 11879) config_free_lines (front=0x0,
front@entry=0x7f17a3cc7460) at src/or/confparse.c:173
* 1 Thread 0x7f1799258700 (LWP 11880) (Exiting) 0x00007f179c9c9200 in __open_nocancel
() from /usr/lib/libc.so.6
(gdb) thread apply all bt full
Thread 3 (Thread 0x7f1798a57700 (LWP 11881)):
#0 0x00007f179cea46bf in recv () from /usr/lib/libpthread.so.0
No symbol table info available.
#1 0x00007f179e3f9a0a in recv (__flags=0, __n=552, __buf=0x7f1798a569b0, __fd=14)
at /usr/include/bits/socket2.h:44
No locals.
#2 read_all (fd=14, buf=0x7f1798a569b0 "", count=552, isSocket=1)
at src/common/util.c:1972
numread = 0
result = <optimized out>
#3 0x00007f179e3ba11b in cpuworker_main (data=0xe, data@entry=0x7f179f649c40)
at src/or/cpuworker.c:422
fd = 14
onion_keys = {my_identity = "<REDACTED>",
onion_key = 0x7f178c0008c0, last_onion_key = 0x7f178c000fb0,
curve25519_key_map = 0x7f178c0010b0, junk_keypair = 0x7f178c0010f0}
req = {magic = 0, tag = '\000' <repeats 11 times>, task = 0 '\000', timed = 0,
started_at = {tv_sec = 0, tv_usec = 0}, create_cell = {cell_type = 0 '\000',
handshake_type = 0, handshake_len = 0,
onionskin = '\000' <repeats 504 times>}}
rpl = {magic = 0, tag = '\000' <repeats 11 times>, success = 0 '\000',
timed = 0, handshake_type = 0, started_at = {tv_sec = 0, tv_usec = 0},
n_usec = 0, created_cell = {cell_type = 0 '\000', handshake_len = 0,
reply = '\000' <repeats 506 times>}, keys = '\000' <repeats 71 times>,
rend_auth_material = '\000' <repeats 19 times>}
__PRETTY_FUNCTION__ = "cpuworker_main"
__func__ = "cpuworker_main"
#4 0x00007f179e3e91ac in tor_pthread_helper_fn (_data=0x0) at src/common/compat.c:2572
data = 0x7f179f641cf0
func = 0x7f179e3ba070 <cpuworker_main>
arg = 0x7f179f649c40
sigs = {__val = {<REDACTED>, <REDACTED> <repeats 15 times>}}
#5 0x00007f179ce9c314 in start_thread () from /usr/lib/libpthread.so.0
No symbol table info available.
#6 0x00007f179c9d624d in clone () from /usr/lib/libc.so.6
No symbol table info available.
Thread 2 (Thread 0x7f179e2c1700 (LWP 11879)):
#0 config_free_lines (front=0x0, front@entry=0x7f17a3cc7460) at src/or/confparse.c:173
tmp = 0x7f17a3cc7460
#1 0x00007f179e3991d3 in config_reset (fmt=fmt@entry=0x7f179e69e160 <state_format>,
options=options@entry=0x7f17a34aa6c0, var=0x7f179e6a53c0 <state_vars_+704>,
use_defaults=use_defaults@entry=1) at src/or/confparse.c:932
c = 0x7f17a3cc7460
msg = 0x0
__func__ = "config_reset"
__PRETTY_FUNCTION__ = "config_reset"
#2 0x00007f179e39a1e7 in config_init (fmt=0x7f179e69e160 <state_format>,
options=0x7f17a34aa6c0) at src/or/confparse.c:1049
i = 22
var = <optimized out>
#3 0x00007f179e39a4f0 in config_dump (fmt=fmt@entry=0x7f179e69e160 <state_format>,
default_options=default_options@entry=0x0, options=0x7f179f1d1060,
minimal=minimal@entry=1, comment_defaults=comment_defaults@entry=0)
at src/or/confparse.c:1072
elements = <optimized out>
defaults = 0x7f17a34aa6c0
defaults_tmp = 0x7f17a34aa6c0
line = <optimized out>
assigned = <optimized out>
result = <optimized out>
i = <optimized out>
msg = 0x0
__PRETTY_FUNCTION__ = "config_dump"
__func__ = "config_dump"
#4 0x00007f179e35a4aa in or_state_save (now=now@entry=1423224555)
at src/or/statefile.c:440
state = <optimized out>
fname = <optimized out>
tbuf = "<REDACTED>"
now = 1423224555
#5 0x00007f179e307bc8 in run_scheduled_events (now=1423224555) at src/or/main.c:1600
have_dir_info = <optimized out>
last_rotated_x509_certificate = 1423224555
time_to_add_entropy = 1423228155
time_to_downrate_stability = 1423267755
time_to_check_for_expired_networkstatus = 1423224675
time_to_write_stats_files = 1423228155
should_init_bridge_stats = 0
time_to_save_stability = 0
time_to_clean_caches = 1423226355
time_to_retry_dns_init = 1423225155
i = <optimized out>
time_to_check_v3_certificate = 1423224855
time_to_download_networkstatus = 1423224615
time_to_write_bridge_status_file = 0
time_to_write_bridge_stats = 1423310955
time_to_shrink_memory = 1423224615
time_to_try_getting_descriptors = 1423224565
time_to_reset_descriptor_failures = 1423228155
time_to_recheck_bandwidth = 0
time_to_launch_reachability_tests = 0
time_to_next_heartbeat = 0
options = 0x7f179f1d1310
is_server = 1
time_to_check_listeners = 1423224615
time_to_check_port_forwarding = 0
#6 second_elapsed_callback (timer=<optimized out>, arg=<optimized out>)
at src/or/main.c:1761
current_second = 0
now = 1423224555
bytes_written = <optimized out>
bytes_read = <optimized out>
seconds_elapsed = <optimized out>
options = <optimized out>
__PRETTY_FUNCTION__ = "second_elapsed_callback"
#7 0x00007f179d95aca6 in event_base_loop () from /usr/lib/libevent-2.0.so.5
No symbol table info available.
#8 0x00007f179e308ea4 in do_main_loop () at src/or/main.c:2105
loop_result = -1568300031
now = 139739487642625
__PRETTY_FUNCTION__ = "do_main_loop"
__func__ = "do_main_loop"
#9 0x00007f179e30bca5 in tor_main (argc=<optimized out>, argv=<optimized out>)
at src/or/main.c:3075
result = 0
__PRETTY_FUNCTION__ = "tor_main"
#10 0x00007f179c90e040 in __libc_start_main () from /usr/lib/libc.so.6
No symbol table info available.
#11 0x00007f179e30532b in _start ()
No symbol table info available.
Thread 1 (Thread 0x7f1799258700 (LWP 11880)):
#0 0x00007f179c9c9200 in __open_nocancel () from /usr/lib/libc.so.6
No symbol table info available.
#1 0x00007f179c96104b in __libc_message () from /usr/lib/libc.so.6
No symbol table info available.
#2 0x00007f179c9612de in __libc_fatal () from /usr/lib/libc.so.6
No symbol table info available.
#3 0x00007f179cea5a59 in pthread_cancel_init () from /usr/lib/libpthread.so.0
No symbol table info available.
#4 0x00007f179cea5b64 in _Unwind_ForcedUnwind () from /usr/lib/libpthread.so.0
No symbol table info available.
#5 0x00007f179cea3f20 in __pthread_unwind () from /usr/lib/libpthread.so.0
No symbol table info available.
#6 0x00007f179ce9d395 in pthread_exit () from /usr/lib/libpthread.so.0
No symbol table info available.
#7 0x00007f179e3ebb7b in spawn_exit () at src/common/compat.c:2641
No locals.
#8 0x00007f179e3ba418 in cpuworker_main (data=0x7f179ca53b80,
data@entry=0x7f17a149d590) at src/or/cpuworker.c:500
fd = 12
onion_keys = {my_identity = '\000' <repeats 19 times>, onion_key = 0x0,
last_onion_key = 0x0, curve25519_key_map = 0x0, junk_keypair = 0x0}
req = {magic = 0, tag = '\000' <repeats 11 times>, task = 0 '\000', timed = 0,
started_at = {tv_sec = 0, tv_usec = 0}, create_cell = {cell_type = 0 '\000',
handshake_type = 0, handshake_len = 0,
onionskin = '\000' <repeats 504 times>}}
rpl = {magic = 0, tag = '\000' <repeats 11 times>, success = 0 '\000',
timed = 0, handshake_type = 0, started_at = {tv_sec = 0, tv_usec = 0},
n_usec = 0, created_cell = {cell_type = 0 '\000', handshake_len = 0,
reply = '\000' <repeats 506 times>}, keys = '\000' <repeats 71 times>,
rend_auth_material = "<REDACTED>"}
__PRETTY_FUNCTION__ = "cpuworker_main"
__func__ = "cpuworker_main"
#9 0x00007f179e3e91ac in tor_pthread_helper_fn (_data=0x0) at src/common/compat.c:2572
data = 0x7f17a3974fa0
func = 0x7f179e3ba070 <cpuworker_main>
arg = 0x7f17a149d590
sigs = {__val = {<REDACTED>, <REDACTED> <repeats 15 times>}}
#10 0x00007f179ce9c314 in start_thread () from /usr/lib/libpthread.so.0
No symbol table info available.
#11 0x00007f179c9d624d in clone () from /usr/lib/libc.so.6
No symbol table info available.
```
**Trac**:
**Username**: tholinTor: 0.2.6.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14741Cancelling a cpuworker job doesn't decrement the total pending tasks counter2020-06-27T14:01:50ZDavid Gouletdgoulet@torproject.orgCancelling a cpuworker job doesn't decrement the total pending tasks counter`cpuworker_cancel_circ_handshake()` should decrement the `total_pending_tasks` counter if the job was successfully cancelled meaning "job" if not NULL.
This issue has been observed with a fast relay where enough jobs were cancelled maki...`cpuworker_cancel_circ_handshake()` should decrement the `total_pending_tasks` counter if the job was successfully cancelled meaning "job" if not NULL.
This issue has been observed with a fast relay where enough jobs were cancelled making `if (total_pending_tasks >= max_pending_tasks)` always true. There are no ways to decrement the counter without having a worker actually completing a job that now can't be queued because we've reached the maximum task allowed.
This makes the relay stop working correctly since no onionskin job can be achieved anymore.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14740Segmentation fault on scheduler domain messages2020-06-27T14:01:50ZcypherpunksSegmentation fault on scheduler domain messagesThe introduction of the scheduler in d438cf1ec9d5de08b8a8fffd7c38b66134fd337c has no string representing these types of domain messages. The list of domains (in `src/common/log.c`) is currently
```
static const char *domain_list[] = {
...The introduction of the scheduler in d438cf1ec9d5de08b8a8fffd7c38b66134fd337c has no string representing these types of domain messages. The list of domains (in `src/common/log.c`) is currently
```
static const char *domain_list[] = {
"GENERAL", "CRYPTO", "NET", "CONFIG", "FS", "PROTOCOL", "MM",
"HTTP", "APP", "CONTROL", "CIRC", "REND", "BUG", "DIR", "DIRSERV",
"OR", "EDGE", "ACCT", "HIST", "HANDSHAKE", "HEARTBEAT", "CHANNEL", NULL
};
```
This should include a string for the scheduler domain. The segmentation fault is reproducible by executing Tor as `tor --LogMessageDomains 1 --Log debug`.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14555Clarification about new CIRC attributes2020-06-27T14:01:51ZDamian JohnsonClarification about new CIRC attributes```
10:37 < atagar> nickm: it would be nice if the socks username/password had a description: https://gitweb.torproject.org/torspec.git/commit/?id=29759745fe1a3a216af7eb9e7ddfa20a10e60f47
10:37 < atagar> example for my unit tests would b...```
10:37 < atagar> nickm: it would be nice if the socks username/password had a description: https://gitweb.torproject.org/torspec.git/commit/?id=29759745fe1a3a216af7eb9e7ddfa20a10e60f47
10:37 < atagar> example for my unit tests would be nice too if you have one handy
10:49 < nickm> atagar: will try to add. doing about a million other things. plase keep bugging me if you can
```
Can do. Questions I have when I look at the [new spec addition](https://gitweb.torproject.org/torspec.git/commit/?id=29759745fe1a3a216af7eb9e7ddfa20a10e60f47) is...
* It's not clear to me what these credentials are for. Please describe what the attributes are.
* You say 'EscapedUsername' and 'EscapedPassword'. What kind of escaping is at play here? Below instead of 'Escaped*' you say "SocksUsername = SocksPassword = a quoted string" which makes me suspect it's just mislabelled.
* Please keep in mind that you're saying we can have a username without a password or a password without a username. Not sure if that's intended.
* Not spec related but if you have an example of this event handy (especially an example that demos the escaping if that's really a thing) I'd love to have it so I can add it to our unit tests.
Cheers! -DamianTor: 0.2.6.x-finalArthur EdelsteinArthur Edelsteinhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14554Possible infinite loop on pipe_drain()2020-06-27T14:01:51ZDavid Gouletdgoulet@torproject.orgPossible infinite loop on pipe_drain()In `src/common/compat_threads.c`, there is this function:
```
static int
pipe_drain(int fd)
{
char buf[32];
ssize_t r;
while ((r = read_ni(fd, buf, sizeof(buf))) >= 0)
;
if (r == 0 || errno != EAGAIN)
return -1;
return...In `src/common/compat_threads.c`, there is this function:
```
static int
pipe_drain(int fd)
{
char buf[32];
ssize_t r;
while ((r = read_ni(fd, buf, sizeof(buf))) >= 0)
;
if (r == 0 || errno != EAGAIN)
return -1;
return 0;
}
```
This one will end up in an infinite loop because read() returns 0 when EOF. Furthermore, if let say we get out of this loop somehow, errno == SUCCESS will return -1. Even if the fd is in non blocking mode, if the fd is drained, the last read() will return 0 non stop (I tested it here with two threads).
I'm coming up with a fix asap that use a safer read() wrapper.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14541Error converting OutboundBindAddress 192.0.2.23 into sockaddr.2020-06-27T14:01:51ZJens KubiezielError converting OutboundBindAddress 192.0.2.23 into sockaddr.Recently I upgraded to the latest Tor nightly build and the log files filled instantly with:
> Jan 30 11:55:55.000 [warn] Error converting OutboundBindAddress 192.0.2.23 into sockaddr. Ignoring.
I switched back to an older version and th...Recently I upgraded to the latest Tor nightly build and the log files filled instantly with:
> Jan 30 11:55:55.000 [warn] Error converting OutboundBindAddress 192.0.2.23 into sockaddr. Ignoring.
I switched back to an older version and the log messages disappeared. So I assume something was introduced between those two versions. A little digging in the code showed that [commit ca5ba2956bcd4b5ee1e526ccf5914f52fe6e6d51](https://gitweb.torproject.org/tor.git/commit/?id=ca5ba2956bcd4b5ee1e526ccf5914f52fe6e6d51) made a change in `src/or/connection.c`.
I didn't wait until the reachability test finished, because there were nearly 100000 lines of the message and I decided to roll back.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14536tor_assertion_failed_(): Bug: ../src/or/channel.c:3953: channel_is_local: Ass...2020-06-27T14:01:51ZJens Kubiezieltor_assertion_failed_(): Bug: ../src/or/channel.c:3953: channel_is_local: Assertion chan failedI'm running 0.2.6.2-alpha-dev (git-525a2ce6e3098930+427ec43) as an exit relay and saw the following message in my log files:
>Jan 30 12:02:51.000 [err] Bug: Assertion chan failed in channel_is_local at ../src/or/channel.c:3953. Stack tr...I'm running 0.2.6.2-alpha-dev (git-525a2ce6e3098930+427ec43) as an exit relay and saw the following message in my log files:
>Jan 30 12:02:51.000 [err] Bug: Assertion chan failed in channel_is_local at ../src/or/channel.c:3953. Stack trace:
>Jan 30 12:02:51.000 [err] Bug: /usr/bin/tor(log_backtrace+0x41) >[0x7fae740bde31]
>Jan 30 12:02:51.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x9f) >[0x7fae740cb3cf]
>Jan 30 12:02:51.000 [err] Bug: /usr/bin/tor(channel_is_local+0x5f) [0x7fae7403c96f]
>Jan 30 12:02:51.000 [err] Bug: /usr/bin/tor(onionskin_answer+0x153) [0x7fae7404a383]
>Jan 30 12:02:51.000 [err] Bug: /usr/bin/tor(+0xea9ca) [0x7fae7408f9ca]
>Jan 30 12:02:51.000 [err] Bug: /usr/bin/tor(replyqueue_process+0x51) [0x7fae740d5201]
>Jan 30 12:02:51.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x414) [0x7fae736b3254]
>Jan 30 12:02:51.000 [err] Bug: /usr/bin/tor(do_main_loop+0x19d) [0x7fae73fde56d]
>Jan 30 12:02:51.000 [err] Bug: /usr/bin/tor(tor_main+0x189d) [0x7fae73fe151d]
>Jan 30 12:02:51.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7fae728d0ead]
>Jan 30 12:02:51.000 [err] Bug: /usr/bin/tor(+0x35b4d) [0x7fae73fdab4d]
I get this message on several machines, all configured as exit relays. Please tell me if you need more information. I'll happily provide it.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14527Typo in a log_warn message in notice.c2020-06-27T14:01:51ZJens KubiezielTypo in a log_warn message in notice.cIn line 1620 of [src/or/config.c](https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n1620) is a typo:
> log_warn(LD_BUG, "Failed parsing oubound bind addresses: %s", msg);
A 't' should be added to oubound.In line 1620 of [src/or/config.c](https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n1620) is a typo:
> log_warn(LD_BUG, "Failed parsing oubound bind addresses: %s", msg);
A 't' should be added to oubound.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14487Faravahar IP Change 2/20/20152020-06-27T14:01:52ZSina RabbaniFaravahar IP Change 2/20/2015Faravahar need to get a new IPV4 address and I would like to do this change on 2/20/2015.
I will keep the old IP running and hopefully forward the traffic using iptable rules.
I will reply to this ticket with a signed PGP note with the ...Faravahar need to get a new IPV4 address and I would like to do this change on 2/20/2015.
I will keep the old IP running and hopefully forward the traffic using iptable rules.
I will reply to this ticket with a signed PGP note with the new IP address.
Thanks,
SinaTor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14478Zero length keys test improvements2020-06-27T14:01:52ZcypherpunksZero length keys test improvementsThe zero length keys could use some small improvements, such as;
1. Remove the temporary directories that are generated. It prevents the main temporary directory from growing over time after each script execution. The solution would be a...The zero length keys could use some small improvements, such as;
1. Remove the temporary directories that are generated. It prevents the main temporary directory from growing over time after each script execution. The solution would be a trap that removes them when the script exits.
```
diff --git a/src/test/zero_length_keys.sh b/src/test/zero_length_keys.sh
index 3a99ca1..2545734 100755
--- a/src/test/zero_length_keys.sh
+++ b/src/test/zero_length_keys.sh
@@ -26,6 +26,8 @@ if [ $# -lt 1 ]; then
fi
export DATA_DIR=`mktemp -d -t tor_zero_length_keys.XXXXXX`
+trap "rm -rf "$DATA_DIR"" 0
+
# DisableNetwork means that the ORPort won't actually be opened.
# 'ExitRelay 0' suppresses a warning.
TOR="./src/or/tor --hush --DisableNetwork 1 --ShutdownWaitLength 0 --ORPort 12345 --ExitRelay 0"
```
2. Do not export the variable `DATA_DIR` because it is useless and stop using the old style command substitution because it has cases of undefined results [0]. Also Bash mentions a preference towards the newer `$()` style [1].
```
diff --git a/src/test/zero_length_keys.sh b/src/test/zero_length_keys.sh
index 3a99ca1..ede7df5 100755
--- a/src/test/zero_length_keys.sh
+++ b/src/test/zero_length_keys.sh
@@ -25,7 +25,8 @@ if [ $# -lt 1 ]; then
exit $?
fi
-export DATA_DIR=`mktemp -d -t tor_zero_length_keys.XXXXXX`
+DATA_DIR="$(mktemp -d -t tor_zero_length_keys.XXXXXX)"
+
# DisableNetwork means that the ORPort won't actually be opened.
# 'ExitRelay 0' suppresses a warning.
TOR="./src/or/tor --hush --DisableNetwork 1 --ShutdownWaitLength 0 --ORPort 12345 --ExitRelay 0"
```
3. Because i am unsure which platforms/shells need to be supported, this improvement may be more work than the satisfaction of correctness it gives. In GNU Coreutils the `mktemp` program marks the `-t` option as deprecated [2]. On other platforms the option is not deprecated. A list of options of the several `mktemp` implementations is available on [StackOverflow](https://stackoverflow.com/a/2792789). The question is whether the script needs to be platform-aware so it can avoid deprecated options or not.
[0] http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03
[1] https://www.gnu.org/software/bash/manual/bashref.html#Major-Differences-From-The-Bourne-Shell (search for `$()`)
[2] https://www.gnu.org/software/coreutils/manual/html_node/mktemp-invocation.html#mktemp-invocation
_PS: The patches are just suggestions, if others agree i can merge them together into one patch and upload a patch file for easier merging._Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14451Use "socket:/path/to/socket" syntax everywhere for AF_UNIX ports2020-06-27T14:01:52ZNick MathewsonUse "socket:/path/to/socket" syntax everywhere for AF_UNIX portsWith legacy/trac#11485, Andrea did a cool syntax for AF_UNIX hidden-service address targets.
Why didn't all the other FooPort options think of that?
We shouldn't have a separate option for Unix vs IP address as in:
```
SocksPort 127.0....With legacy/trac#11485, Andrea did a cool syntax for AF_UNIX hidden-service address targets.
Why didn't all the other FooPort options think of that?
We shouldn't have a separate option for Unix vs IP address as in:
```
SocksPort 127.0.0.1:9050
SocksSocket /home/nickm/.tor/connect-to-this
```
Instead why not just have it be:
```
SocksPort 127.0.0.1:9050
SocksPort socket:/home/nickm/.tor/connect-to-this
```Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14450tor-resolve should better handle .onion addresses2020-06-27T14:01:52Zweasel (Peter Palfrader)tor-resolve should better handle .onion addressesIn https://bugs.debian.org/776454, Russell Coker asks for a slight modification of tor-resolve's behavior wrt .onion addresses:
$ tor-resolve zp7zwyd5t3aju57m.onion
Jan 28 17:38:42.055 [warn] Got SOCKS5 status response '4': host is ...In https://bugs.debian.org/776454, Russell Coker asks for a slight modification of tor-resolve's behavior wrt .onion addresses:
$ tor-resolve zp7zwyd5t3aju57m.onion
Jan 28 17:38:42.055 [warn] Got SOCKS5 status response '4': host is unreachable
Jan 28 17:38:42.055 [warn] zp7zwyd5t3aju57m.onion is a hidden service; those don't have IP addresses. To connect to a hidden service, you need to send the hostname to Tor; we suggest an application that uses SOCKS 4a.
The above output is informative, but not particularly useful for the case of
scripts.
https://www.howtoforge.com/anonymous-ssh-sessions-with-tor
The above web site gives an example of how to use tor which btraks when used
with .onion addresses. One way to solve this would be for tor-resolve to
give "zp7zwyd5t3aju57m.onion" on stdout and the warning message on stderr,
that would inform users but work in the desired manner with scripts.
A small change to tor-resolve will make it work better with existing documented
practice and make it work with future use for .onion addresses in cases where
admins only care about non-onion addresses now.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14415After upgrading tor the service is restarted but the process failed to restart2020-06-27T14:01:52ZTracAfter upgrading tor the service is restarted but the process failed to restartHello Good Morning,
After upgrading the service tor automatically restarted but the process failed to restart as evident in the attached log file.
Running in openVZ enviroment.
tor 0.2.6.2-alpha-dev-20150126T150909Z-1~trusty+1
uname ...Hello Good Morning,
After upgrading the service tor automatically restarted but the process failed to restart as evident in the attached log file.
Running in openVZ enviroment.
tor 0.2.6.2-alpha-dev-20150126T150909Z-1~trusty+1
uname -a
Linux Hostname 2.6.32-042stab094.7 !#1 SMP Wed Oct 22 12:43:21 MSK 2014 x86_64 x86_64 x86_64 GNU/Linux
cat /etc/apt/sources.list.d/tor.list
deb !http://deb.torproject.org/torproject.org trusty main
deb !http://deb.torproject.org/torproject.org tor-nightly-master-trusty main
If any more data is needed, please tell me.
Thanks.
**Trac**:
**Username**: tor-3742@vinicius.slTor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14350configure.ac: fix disabling systemd notification support2020-06-27T14:01:53ZAnthony Basileconfigure.ac: fix disabling systemd notification supportIf --disable-systemd is given, we set $systemd to false, not $enable_systemd. As a result, the way configure.ac is currently written, if libsystemd is found, we still turn on systemd support even if we explicitly disable it with --disab...If --disable-systemd is given, we set $systemd to false, not $enable_systemd. As a result, the way configure.ac is currently written, if libsystemd is found, we still turn on systemd support even if we explicitly disable it with --disable-system.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14325tor-resolve errata2020-06-27T14:01:54Zgrarpamptor-resolve errataThe binary help string does not match the manpage option list, or the actual source code.
./tor-resolve
Syntax: tor-resolve [-4] [-v] [-x] [-F] [-p port] hostname [sockshost:socksport]
The note below should direct people to use SOCKSv...The binary help string does not match the manpage option list, or the actual source code.
./tor-resolve
Syntax: tor-resolve [-4] [-v] [-x] [-F] [-p port] hostname [sockshost:socksport]
The note below should direct people to use SOCKSv5, not legacy 4a stuff. This message occurs in two places in the source. The '-4' option should also be renamed to '-4a'.
./tor-resolve -v abcdefghijklmnop.onion 127.0.0.1:9051
[warn] ... To connect to a hidden service ... we suggest an application that uses SOCKS 4a.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14296Avoid redundant check for NULL defport->unix_addr in config.c2020-06-27T14:01:54ZteorAvoid redundant check for NULL defport->unix_addr in config.cAnything in the middle of a structure will always be non-null.
clang 3.6.0 warns on this because it is redundant.
See my branch **config-remove-redundant-assert** in my **teor2345** github.Anything in the middle of a structure will always be non-null.
clang 3.6.0 warns on this because it is redundant.
See my branch **config-remove-redundant-assert** in my **teor2345** github.Tor: 0.2.6.x-final