Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:07Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33900Check for invalid zero IPv4 addresses and ports in extend cells2020-06-13T15:53:07ZteorCheck for invalid zero IPv4 addresses and ports in extend cellsWhen we send and parse extend cells, we check that their IPv4 address field is not AF_UNSPEC.
But we should also check for zero IPv4 addresses and zero ports. (Which are both invalid.)
Code and points in #33817, I just needed a separat...When we send and parse extend cells, we check that their IPv4 address field is not AF_UNSPEC.
But we should also check for zero IPv4 addresses and zero ports. (Which are both invalid.)
Code and points in #33817, I just needed a separate bug number.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29437test-stem times out intermittently2020-06-13T15:44:35Zrl1987test-stem times out intermittently```
control.base_controller... success (1.23s)
control.controller...
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wron...```
control.base_controller... success (1.23s)
control.controller...
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated
```
https://travis-ci.org/rl1987/tor/jobs/490611608Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30916assert in dimap_add_entry()2020-06-13T15:42:42ZDavid Gouletdgoulet@torproject.orgassert in dimap_add_entry()From tor-relays@:
https://lists.torproject.org/pipermail/tor-relays/2019-June/017402.html
The stack trace is:
```
Jun 18 13:33:31.000 [notice] Bootstrapped 0%: Starting
Jun 18 13:33:32.000 [notice] Starting with guard context "defau...From tor-relays@:
https://lists.torproject.org/pipermail/tor-relays/2019-June/017402.html
The stack trace is:
```
Jun 18 13:33:31.000 [notice] Bootstrapped 0%: Starting
Jun 18 13:33:32.000 [notice] Starting with guard context "default"
============================================================ T= 1560854012
INTERNAL ERROR: Raw assertion failed at ../src/lib/ctime/di_ops.c:179: !
old_val/usr/bin/tor(dump_stack_symbols_to_error_fds+0x33)[0x55a17b410943]
/usr/bin/tor(tor_raw_assertion_failed_msg_+0x86)[0x55a17b410fd6]
/usr/bin/tor(dimap_add_entry+0xa0)[0x55a17b411ba0]
/usr/bin/tor(construct_ntor_key_map+0x69)[0x55a17b357969]
/usr/bin/tor(server_onion_keys_new+0x4d)[0x55a17b39f4dd]
/usr/bin/tor(+0x66e27)[0x55a17b287e27]
/usr/bin/tor(threadpool_new+0x18b)[0x55a17b3b3f0b]
/usr/bin/tor(cpu_init+0x9d)[0x55a17b28828d]
/usr/bin/tor(run_tor_main_loop+0x136)[0x55a17b27a496]
/usr/bin/tor(tor_run_main+0x1215)[0x55a17b27b935]
/usr/bin/tor(tor_main+0x3a)[0x55a17b278a8a]
/usr/bin/tor(main+0x19)[0x55a17b278609]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7ffb901ba2e1]
/usr/bin/tor(_start+0x2a)[0x55a17b27865a]
Jun 18 13:33:33.000 [notice] Tor 0.3.5.8 opening log file.
```
It appears that tor tried to add the same value in the `di_digest256_map_t` twice.
Logs indicate 0.3.5.8Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30117Support stem's backtrace signals in Travis2020-06-13T15:40:34ZteorSupport stem's backtrace signals in TravisIn #29437, we're trying to track down a stem hang in our CI.
In #30012, I added backtrace support to stem.
But we need that backtrace support in our CI to see why stem is hanging.In #29437, we're trying to track down a stem hang in our CI.
In #30012, I added backtrace support to stem.
But we need that backtrace support in our CI to see why stem is hanging.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/30021Do not cache cipher list classification if cipher list is not yet available.2020-06-13T15:40:15ZNick MathewsonDo not cache cipher list classification if cipher list is not yet available.See #29437 for motivation.See #29437 for motivation.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17778Memory leak in ntor test2020-06-13T14:51:59ZcypherpunksMemory leak in ntor testThe ntor test contains a memory leak by not freeing the keymap of `server1`.The ntor test contains a memory leak by not freeing the keymap of `server1`.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16823extra tor_free() for create_cell_t in command_process_create_cell()2020-06-13T14:48:12ZIsis Lovecruftextra tor_free() for create_cell_t in command_process_create_cell()In `command_process_create_cell()` (on master, as of commit da04fed865b6df09b33e6b632d51d34b3eb20d14)
```
memset(&created_cell, 0, sizeof(created_cell));
len = onion_skin_server_handshake(ONION_HANDSHAKE_TYPE_FAST,
...In `command_process_create_cell()` (on master, as of commit da04fed865b6df09b33e6b632d51d34b3eb20d14)
```
memset(&created_cell, 0, sizeof(created_cell));
len = onion_skin_server_handshake(ONION_HANDSHAKE_TYPE_FAST,
create_cell->onionskin,
create_cell->handshake_len,
NULL,
created_cell.reply,
keys, CPATH_KEY_MATERIAL_LEN,
rend_circ_nonce);
tor_free(create_cell);
if (len < 0) {
log_warn(LD_OR,"Failed to generate key material. Closing.");
circuit_mark_for_close(TO_CIRCUIT(circ), END_CIRC_REASON_INTERNAL);
tor_free(create_cell);
return;
}
```
Which is a double-free (somewhat dependent on what the `PREDICT_LIKELY` macro generates).
I haven't tested yet, but it might be possible to crash relays with this bug. We should probably patch this ASAP.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8014Reject the reference-implementation of curve25519 from donna in a more compre...2020-06-13T14:28:15ZTracReject the reference-implementation of curve25519 from donna in a more comprehensible way.during ./configure I get the following result:
[...]
checking whether we can use curve25519-donna-c64... no
checking whether we can use curve25519 from nacl... no
I do have nacl(-devel) installed on my machine. Closer inspection of conf...during ./configure I get the following result:
[...]
checking whether we can use curve25519-donna-c64... no
checking whether we can use curve25519 from nacl... no
I do have nacl(-devel) installed on my machine. Closer inspection of config.log tells me that conftest.c has "#include <crypto_scalarmult_curve25519.h>". That file is in /usr/include/nacl, so I had to add "-I/usr/include/nacl" for this particular error to pass.
That didn't work though as I am now getting "conftest.c:58:4: error: #error Hey, this is the reference implementation!". The conftest.c file itself has this:
#include <crypto_scalarmult_curve25519.h>
#ifdef crypto_scalarmult_curve25519_ref_BYTES
#error Hey, this is the reference implementation!
#endif
"crypto_scalarmult_curve25519_ref_BYTES" is indeed defined in /usr/include/nacl/crypto_scalarmult_curve25519.h, so how am I supposed to satisfy this test then?
**Trac**:
**Username**: mr-4Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7972configure fails to detect nacl2020-06-13T14:26:32Zweasel (Peter Palfrader)configure fails to detect naclHey,
the configure script's test includes a crypto_scalarmult_curve25519.h, without specifying any extra path.
On Debian, the nacl headers are in /usr/include/nacl, so maybe add that to the -I path, or include nacl/crypto_scalarmult_cu...Hey,
the configure script's test includes a crypto_scalarmult_curve25519.h, without specifying any extra path.
On Debian, the nacl headers are in /usr/include/nacl, so maybe add that to the -I path, or include nacl/crypto_scalarmult_curve25519.h?
Cheers,Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7959onionskin_answer(): Bug: couldn't format created cell2020-06-13T14:26:29ZMatthew Finkelonionskin_answer(): Bug: couldn't format created cellRunning 0.2.4.8-alpha with UseNTorHandshake 1
```
Jan 14 23:01:33.000 [debug] connection_or_process_cells_from_inbuf(): 27: starting, inbuf_datalen 0 (0 pending in tls object).
Jan 14 23:01:33.000 [debug] global_read_bucket now 10737418...Running 0.2.4.8-alpha with UseNTorHandshake 1
```
Jan 14 23:01:33.000 [debug] connection_or_process_cells_from_inbuf(): 27: starting, inbuf_datalen 0 (0 pending in tls object).
Jan 14 23:01:33.000 [debug] global_read_bucket now 1073741824.
Jan 14 23:01:33.000 [debug] global_write_bucket now 1073741824.
Jan 14 23:01:33.000 [debug] global_relayed_read_bucket now 819200.
Jan 14 23:01:33.000 [debug] or_conn->read_bucket now 1073741824.
Jan 14 23:01:33.000 [debug] or_conn->write_bucket now 1073741824.
Jan 14 23:01:33.000 [debug] conn_read_callback(): socket 27 wants to read.
Jan 14 23:01:33.000 [debug] connection_read_to_buf(): 27: starting, inbuf_datalen 0 (0 pending in tls object). at_most 16384.
Jan 14 23:01:33.000 [debug] connection_read_to_buf(): After TLS read of 512: 549 read, 0 written
Jan 14 23:01:33.000 [debug] connection_or_process_cells_from_inbuf(): 27: starting, inbuf_datalen 512 (0 pending in tls object).
Jan 14 23:01:33.000 [debug] channel_queue_cell(): Directly handling incoming cell_t 0x7fff3db0c140 for channel 0x7f1548d16660 (global ID 5)
Jan 14 23:01:33.000 [debug] command_process_create_cell(): Got a CREATE cell for circ_id 60215 on channel 5 (0x7f1548d16660)
Jan 14 23:01:33.000 [debug] circuit_get_by_circid_channel_impl(): circuit_get_by_circid_channel_impl() found nothing for circ_id 60215, channel ID 5 (0x7f1548d16660)
Jan 14 23:01:33.000 [debug] circuitmux_attach_circuit(): Attaching circuit 60215 on channel 5 to cmux 0x7f1548d167c0
Jan 14 23:01:33.000 [debug] command_process_create_cell(): success: handed off onionskin.
Jan 14 23:01:33.000 [debug] connection_or_process_cells_from_inbuf(): 27: starting, inbuf_datalen 0 (0 pending in tls object).
Jan 14 23:01:33.000 [debug] conn_write_callback(): socket 22 wants to write.
Jan 14 23:01:33.000 [debug] cpuworker_main(): onion_skin_server_handshake succeeded.
Jan 14 23:01:33.000 [debug] cpuworker_main(): finished writing response.
Jan 14 23:01:33.000 [debug] conn_read_callback(): socket 22 wants to read.
Jan 14 23:01:33.000 [debug] read_to_chunk(): Read 620 bytes. 620 on inbuf.
Jan 14 23:01:33.000 [debug] connection_cpu_process_inbuf(): Unpacking cpuworker reply, chan_id is 5, circ_id is 60215
Jan 14 23:01:33.000 [debug] circuit_get_by_circid_channel_impl(): circuit_get_by_circid_channel_impl() returning circuit 0x7f1548d194f0 for circ_id 60215, channel ID 5 (0x7f1548d16660)
Jan 14 23:01:33.000 [warn] onionskin_answer(): Bug: couldn't format created cell
Jan 14 23:01:33.000 [warn] onionskin_answer failed. Closing.
Jan 14 23:01:33.000 [debug] circuit_get_by_circid_channel_impl(): circuit_get_by_circid_channel_impl() returning circuit 0x7f1548d194f0 for circ_id 60215, channel ID 5 (0x7f1548d16660)
Jan 14 23:01:33.000 [debug] channel_send_destroy(): Sending destroy (circID 60215) on channel 0x7f1548d16660 (global ID 5)
Jan 14 23:01:33.000 [debug] channel_write_cell(): Writing cell_t 0x7fff3db0c010 to channel 0x7f1548d16660 with global ID 5
Jan 14 23:01:33.000 [debug] conn_write_callback(): socket 27 wants to write.
Jan 14 23:01:33.000 [debug] flush_chunk_tls(): flushed 512 bytes, 0 ready to flush, 0 remain.
Jan 14 23:01:33.000 [debug] connection_handle_write_impl(): After TLS write of 512: 0 read, 586 written
```Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30257Propagate USR1 and ABRT signals from stem tests through to tor2020-06-13T10:52:06ZteorPropagate USR1 and ABRT signals from stem tests through to torIn #30234, we got the tor logs, but the USR1 and ABRT signals sent by timelimit to test_stem.py aren't being propagated to tor:
```
Apr 22 03:32:30.000 [notice] Monitored process 20402 is dead.
Apr 22 03:32:30.000 [notice] Owning control...In #30234, we got the tor logs, but the USR1 and ABRT signals sent by timelimit to test_stem.py aren't being propagated to tor:
```
Apr 22 03:32:30.000 [notice] Monitored process 20402 is dead.
Apr 22 03:32:30.000 [notice] Owning controller process has vanished -- exiting now.
Apr 22 03:32:30.000 [notice] Catching signal TERM, exiting cleanly.
```
https://travis-ci.org/teor2345/tor/jobs/522893523#L4944
We need to work out how to get the signals from this stem test process down to the tor it launches:
```
================================================================================
Signal SIGABRT received by thread MainThread in process 20402
--------------------------------------------------------------------------------
Event notifier thread stacktrace
File "/usr/lib/python3.4/threading.py", line 888, in _bootstrap
self._bootstrap_inner()
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "/home/travis/build/teor2345/tor/stem/stem/control.py", line 984, in _event_loop
self._event_notice.wait(0.05)
File "/usr/lib/python3.4/threading.py", line 553, in wait
signaled = self._cond.wait(timeout)
File "/usr/lib/python3.4/threading.py", line 294, in wait
gotit = waiter.acquire(True, timeout)
--------------------------------------------------------------------------------
MainThread thread stacktrace
File "/home/travis/build/teor2345/tor/stem/run_tests.py", line 451, in <module>
main()
File "/home/travis/build/teor2345/tor/stem/run_tests.py", line 287, in main
integ_runner.start(target, args.attribute_targets, args.tor_path)
File "/home/travis/build/teor2345/tor/stem/test/runner.py", line 262, in start
self._owner_controller = self.get_tor_controller(True)
File "/home/travis/build/teor2345/tor/stem/test/runner.py", line 482, in get_tor_controller
controller.authenticate(password = CONTROL_PASSWORD, chroot_path = self.get_chroot())
File "/home/travis/build/teor2345/tor/stem/stem/control.py", line 1103, in authenticate
stem.connection.authenticate(self, *args, **kwargs)
File "/home/travis/build/teor2345/tor/stem/stem/connection.py", line 530, in authenticate
protocolinfo_response = get_protocolinfo(controller)
File "/home/travis/build/teor2345/tor/stem/stem/connection.py", line 1007, in get_protocolinfo
protocolinfo_response = _msg(controller, 'PROTOCOLINFO 1')
File "/home/travis/build/teor2345/tor/stem/stem/connection.py", line 1036, in _msg
return controller.msg(message)
File "/home/travis/build/teor2345/tor/stem/stem/control.py", line 654, in msg
response = self._reply_queue.get()
File "/usr/lib/python3.4/queue.py", line 167, in get
self.not_empty.wait()
File "/usr/lib/python3.4/threading.py", line 290, in wait
waiter.acquire()
File "/home/travis/build/teor2345/tor/stem/run_tests.py", line 98, in log_traceback
for thread_name, stacktrace in test.output.thread_stacktraces().items():
File "/home/travis/build/teor2345/tor/stem/test/output.py", line 110, in thread_stacktraces
stacktraces[thread.name] = ''.join(traceback.format_stack(frame))
--------------------------------------------------------------------------------
Tor listener thread stacktrace
File "/usr/lib/python3.4/threading.py", line 888, in _bootstrap
self._bootstrap_inner()
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "/home/travis/build/teor2345/tor/stem/stem/control.py", line 939, in _reader_loop
control_message = self._socket.recv()
File "/home/travis/build/teor2345/tor/stem/stem/socket.py", line 474, in recv
return self._recv(lambda s, sf: recv_message(sf))
File "/home/travis/build/teor2345/tor/stem/stem/socket.py", line 274, in _recv
return handler(my_socket, my_socket_file)
File "/home/travis/build/teor2345/tor/stem/stem/socket.py", line 474, in <lambda>
return self._recv(lambda s, sf: recv_message(sf))
File "/home/travis/build/teor2345/tor/stem/stem/socket.py", line 676, in recv_message
line = control_file.readline()
File "/usr/lib/python3.4/socket.py", line 374, in readinto
return self._sock.recv_into(b)
================================================================================
```
https://travis-ci.org/teor2345/tor/jobs/522893523#L3830Tor: 0.2.9.x-finalDamian JohnsonDamian Johnson