The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:01:40Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15043Use acx_pthread.m4 to find pthreads library2020-06-27T14:01:40ZNick MathewsonUse acx_pthread.m4 to find pthreads libraryIn legacy/trac#9495, we noticed that (it seems) we aren't taking any efforts to compile with threading right on some platforms. Let's fix that by not trying to figure it out ourselves. The acx_pthread.m4 autoconf module is just fine; l...In legacy/trac#9495, we noticed that (it seems) we aren't taking any efforts to compile with threading right on some platforms. Let's fix that by not trying to figure it out ourselves. The acx_pthread.m4 autoconf module is just fine; let's use that in 0.2.7. (It's probably too late to do this in 0.2.6; this is a fiddly part of our build system)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15046Stuck at 85%-bootstrapping for 10-15 minutes in git-320a68026ede1f57+15e7a822020-06-27T14:01:39ZTracStuck at 85%-bootstrapping for 10-15 minutes in git-320a68026ede1f57+15e7a820.2.7.0-alpha-dev (git-3e9409ef58139d55+15e7a82) worked perfectly, but since version 0.2.7.0-alpha-dev (git-320a68026ede1f57+15e7a82) and last version 0.2.7.0-alpha-dev (git-320a68026ede1f57+15e7a82) something really changed.
Now I alw...0.2.7.0-alpha-dev (git-3e9409ef58139d55+15e7a82) worked perfectly, but since version 0.2.7.0-alpha-dev (git-320a68026ede1f57+15e7a82) and last version 0.2.7.0-alpha-dev (git-320a68026ede1f57+15e7a82) something really changed.
Now I always stuck at 85% bootstrapping for about 10-15 minutes and only after that tor jumps to 90% bootstrap phase and connects in seconds. 0.2.7.0-alpha-dev (git-3e9409ef58139d55+15e7a82) was working instantly maybe with about max 1 minute delay for full bootstrap.(really some seconds).
That is the first time I have problems with alpha versions. And most strange thing in all that that yesterday before CitizenFour watching all worked perfectly. Sorry for bit crappy report, maybe I should start to discover what changed in last commits.
**Trac**:
**Username**: Ricky_MartinTor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15053Improve out-of-tree builds2020-06-27T14:01:39ZcypherpunksImprove out-of-tree buildsSeveral make rules don't work when building out-of-tree. There are also some files that aren't cleaned up on `make clean` or `make distclean`. Lastly, some file generation blobs don't work properly by leaving temporary files behind.
Thes...Several make rules don't work when building out-of-tree. There are also some files that aren't cleaned up on `make clean` or `make distclean`. Lastly, some file generation blobs don't work properly by leaving temporary files behind.
These are just some of the things i have ran into so far and i am currently patching these issues.
Also creating this ticket to discuss certain parts of the build configuration that are unfamiliar and for which the reasons of implementation can't be traced back.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15055Implement ed25519 link handshake2020-06-27T14:01:39ZNick MathewsonImplement ed25519 link handshakeIn legacy/trac#12498 , we implement a new identity key type. Now it's time to use it in a proper handshake as documented in proposal 220.In legacy/trac#12498 , we implement a new identity key type. Now it's time to use it in a proper handshake as documented in proposal 220.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15056Support ed25519 identities for circuit extension2020-06-27T14:01:39ZNick MathewsonSupport ed25519 identities for circuit extensionOnce legacy/trac#12498 is merged and legacy/trac#15055 is done, we can use ed25519 in circuit extension as documented in proposal 220.Once legacy/trac#12498 is merged and legacy/trac#15055 is done, we can use ed25519 in circuit extension as documented in proposal 220.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15057Write a proposal for removing RSA1024 identities2020-06-27T14:01:39ZNick MathewsonWrite a proposal for removing RSA1024 identitiesOnce legacy/trac#15054 is merged, we'll be on our way to a future where RSA1024 identities are superfluous. We should have a plan to get rid of them some day.Once legacy/trac#15054 is merged, we'll be on our way to a future where RSA1024 identities are superfluous. We should have a plan to get rid of them some day.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15058Write a proposal for removing TAP2020-06-27T14:01:39ZNick MathewsonWrite a proposal for removing TAPThe old circuit extension protocol, which Ian named "TAP" for us, is pretty much superseded by ntor now. Once there are no more 0.2.3.x clients to think about, relays don't really need to support it any more. We should have a proposal ...The old circuit extension protocol, which Ian named "TAP" for us, is pretty much superseded by ntor now. Once there are no more 0.2.3.x clients to think about, relays don't really need to support it any more. We should have a proposal for getting rid of it without breaking things.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15064Fix a bug using IPFW transparent proxy2020-06-27T14:01:38ZTracFix a bug using IPFW transparent proxyWe've been working on setting up IPFW transparent proxy on FreeBSD, and ran into a bug when using "TransProxyType ipfw". The attached patch fixes the issue.
**Trac**:
**Username**: kmoore134We've been working on setting up IPFW transparent proxy on FreeBSD, and ran into a bug when using "TransProxyType ipfw". The attached patch fixes the issue.
**Trac**:
**Username**: kmoore134Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15073issue with establishing tor connection in linux2020-06-27T14:01:38ZTracissue with establishing tor connection in linuxHello
I am a user in Iran, running tor on a linux. Recently- more than a week- tor failed to establish connection to the tor network, messages as such:
Feb 28 09:40:46.000 [notice] Bootstrapped 0%: Starting
Feb 28 09:40:47.000 [notice] B...Hello
I am a user in Iran, running tor on a linux. Recently- more than a week- tor failed to establish connection to the tor network, messages as such:
Feb 28 09:40:46.000 [notice] Bootstrapped 0%: Starting
Feb 28 09:40:47.000 [notice] Bootstrapped 5%: Connecting to directory server
Feb 28 09:41:50.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Feb 28 09:41:51.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection
Feb 28 09:41:51.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus
Feb 28 09:41:51.000 [notice] Bootstrapped 25%: Loading networkstatus consensus
Feb 28 09:47:20.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
I know that your first advise must be using the tor-browser but for the technical reason and ease of use and also torrifying everything outo f my linux I much prepfer to use tor as a daemon built in app in linux.
I tried to troubleshoot all the possible ways including a new kvm and setting tor in it to observe the connection establishment and if that is suppressed by the Iran regime. I should say that there I received pretty funny messages as:
Feb 28 09:57:48.000 [warn] 10 connections died in state connect()ing with SSL state (No SSL object)
Feb 28 09:59:05.000 [warn] Problem bootstrapping. Stuck at 50%: Loading relay descriptors. (Connection timed out; TIMEOUT; count 12; recommendation warn)
Feb 28 09:59:05.000 [warn] 11 connections have failed:
Feb 28 09:59:05.000 [warn] 11 connections died in state connect()ing with SSL state (No SSL object)
or
Feb 28 10:06:14.000 [notice] Bootstrapped 100%: Done
Feb 28 10:06:32.000 [warn] Received http status code 404 ("Not found") from server '85.14.240.188:443' while fetching "/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB6BCC86956".
Feb 28 10:08:45.000 [warn] parse error: Malformed object: missing object end line
Feb 28 10:08:45.000 [warn] Unparseable microdescripto
or
Feb 25 11:51:53.000 [warn] I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's not going to work. Did you perhaps ask for an IPv6 address on an IPv4Only port, or vice versa?
Feb 25 11:51:53.000 [warn] I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's not going to work. Did you perhaps ask for an IPv6 address on an IPv4Only port, or vice versa?
Feb 25 11:52:05.000 [notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $F65E0196C94DFFF48AFBF2F5F9E3E19AAE583FD0~destiny at 94.242.246.23. Retrying on a new circuit.
Feb 25 11:52:05.000 [notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $F65E0196C94DFFF48AFBF2F5F9E3E19AAE583FD0~destiny at 94.242.246.23. Retrying on a new circuit.
pretty much seems to my eyes a tampered ssl. My tor config is straight forward and includes a default 9050 port socks 5 on the 127.0.0.1.
Here is the signature and version info:
-Linux localhost 2.6.32-431.23.3.el6.x86_64 #1 SMP Thu Jul 31 17:20:51 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
-tor-0.2.5.10-1.el6.x86_64
-torsocks-2.0.0-2.el6.x86_64
**Trac**:
**Username**: hsafehttps://gitlab.torproject.org/tpo/core/tor/-/issues/15083Assertion ch->data < &ch->mem[0]+ch->memlen failed2020-06-27T14:01:38ZTracAssertion ch->data < &ch->mem[0]+ch->memlen failedFeb 28 06:25:04.000 [notice] Tor 0.2.5.10 (git-43a5f3d91e726291) opening new log file.
Feb 28 09:12:42.000 [notice] Caching new entry debian-tor for debian-tor
Feb 28 09:12:55.000 [notice] Heartbeat: Tor's uptime is 9 days 23:57 hours, w...Feb 28 06:25:04.000 [notice] Tor 0.2.5.10 (git-43a5f3d91e726291) opening new log file.
Feb 28 09:12:42.000 [notice] Caching new entry debian-tor for debian-tor
Feb 28 09:12:55.000 [notice] Heartbeat: Tor's uptime is 9 days 23:57 hours, with 3628 circuits open. I've sent 2019.68 GB and received 1952.11 GB.
Feb 28 09:12:55.000 [notice] Average packaged cell fullness: 97.211%
Feb 28 09:12:55.000 [notice] TLS write overhead: 3%
Feb 28 09:12:55.000 [notice] Circuit handshake stats since last time: 24992/25002 TAP, 25312/25314 NTor.
Feb 28 15:12:55.000 [notice] Heartbeat: Tor's uptime is 10 days 5:57 hours, with 4022 circuits open. I've sent 2074.91 GB and received 2005.67 GB.
Feb 28 15:12:55.000 [notice] Average packaged cell fullness: 97.253%
Feb 28 15:12:55.000 [notice] TLS write overhead: 3%
Feb 28 15:12:55.000 [notice] Circuit handshake stats since last time: 37526/37526 TAP, 31539/31539 NTor.
Feb 28 15:29:59.000 [err] tor_assertion_failed_(): Bug: ../src/or/buffers.c:2627: assert_buf_ok: Assertion ch->data < &ch->mem[0]+ch->memlen failed; aborting.
Feb 28 15:29:59.000 [err] Bug: Assertion ch->data < &ch->mem[0]+ch->memlen failed in assert_buf_ok at ../src/or/buffers.c:2627. Stack trace:
Feb 28 15:29:59.000 [err] Bug: /usr/bin/tor(log_backtrace+0x41) [0x7fb3e3dd9d01]
Feb 28 15:29:59.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x9f) [0x7fb3e3de59bf]
Feb 28 15:29:59.000 [err] Bug: /usr/bin/tor(assert_buf_ok+0x167) [0x7fb3e3d547f7]
Feb 28 15:29:59.000 [err] Bug: /usr/bin/tor(assert_connection_ok+0xb8) [0x7fb3e3d8de28]
Feb 28 15:29:59.000 [err] Bug: /usr/bin/tor(+0x37617) [0x7fb3e3cfc617]
Feb 28 15:29:59.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x414) [0x7fb3e33d3254]
Feb 28 15:29:59.000 [err] Bug: /usr/bin/tor(do_main_loop+0x19d) [0x7fb3e3cfcf4d]
Feb 28 15:29:59.000 [err] Bug: /usr/bin/tor(tor_main+0x1aa5) [0x7fb3e3d000b5]
Feb 28 15:29:59.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7fb3e25f0ead]
Feb 28 15:29:59.000 [err] Bug: /usr/bin/tor(+0x3465d) [0x7fb3e3cf965d]
**Trac**:
**Username**: poiutyTor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15087Move timeliness check out of tor_cert_checksig, or into tor_cert_get_checkabl...2020-06-27T14:01:37ZNick MathewsonMove timeliness check out of tor_cert_checksig, or into tor_cert_get_checkable_sigThere's a mismatch in our certificate API: When we're doing single verification, we check the expiration time, but when we are doing batch verification, we rely on the caller to do so. We should make these functions do the same thing.There's a mismatch in our certificate API: When we're doing single verification, we check the expiration time, but when we are doing batch verification, we rely on the caller to do so. We should make these functions do the same thing.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15088Add the wait4() syscall to the seccomp sandbox2020-06-27T14:01:37ZTracAdd the wait4() syscall to the seccomp sandboxTor version 0.2.5.10 seems to call wait4() upon receiving SIGHUP, and this violates the seccomp sandbox rules in sandbox.c, crashing the tor process.
Trace from tor's log on debug loglevel, right after `/etc/init.d/tor reload`:
```
====...Tor version 0.2.5.10 seems to call wait4() upon receiving SIGHUP, and this violates the seccomp sandbox rules in sandbox.c, crashing the tor process.
Trace from tor's log on debug loglevel, right after `/etc/init.d/tor reload`:
```
============================================================ T= 1425215692
(Sandbox) Caught a bad syscall attempt (syscall wait4)
/usr/bin/tor(+0x12f4f1)[0x4273cf44f1]
/lib64/libc.so.6(waitpid+0x1a)[0x3423957b1da]
/lib64/libc.so.6(waitpid+0x1a)[0x3423957b1da]
/usr/bin/tor(notify_pending_waitpid_callbacks+0x4a)[0x4273cf42da]
/usr/bin/tor(process_signal+0x4ad)[0x4273bfb96d]
/usr/lib64/libevent-2.0.so.5(event_base_loop+0x99e)[0x3423a111a6e]
/usr/bin/tor(do_main_loop+0x1ad)[0x4273bfa77d]
/usr/bin/tor(tor_main+0x1875)[0x4273bfd755]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x342394e2d55]
/usr/bin/tor(+0x31c49)[0x4273bf6c49]
Mar 01 16:14:52.000 [info] cpuworker_main(): read request failed. Exiting.
```
The patch is as simple as adding wait4() to the whitelist:
```
diff -Naur tor-0.2.5.10/src/common/sandbox.c tor-0.2.5.10.new/src/common/sandbox.c
--- tor-0.2.5.10/src/common/sandbox.c
+++ tor-0.2.5.10.new/src/common/sandbox.c
@@ -119,6 +119,7 @@
SCMP_SYS(epoll_wait),
SCMP_SYS(fcntl),
SCMP_SYS(fstat),
+ SCMP_SYS(wait4),
#ifdef __NR_fstat64
SCMP_SYS(fstat64),
#endif
```
**Trac**:
**Username**: sanicTor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15102Tor crashed with tor_assertion_failed_() in ../src/or/buffers.c:26272020-06-27T14:01:37ZTracTor crashed with tor_assertion_failed_() in ../src/or/buffers.c:2627Hi,
unfortunately our tor relay just crashed today while relaying aroung 20MB/s data.
This is all I could find in the /var/log/tor/log:
Mar 02 11:02:23.000 [notice] Heartbeat: Tor's uptime is 30 days 6:00 hours, with 27608 circuits op...Hi,
unfortunately our tor relay just crashed today while relaying aroung 20MB/s data.
This is all I could find in the /var/log/tor/log:
Mar 02 11:02:23.000 [notice] Heartbeat: Tor's uptime is 30 days 6:00 hours, with 27608 circuits open. I've sent 63378.02 GB and received 61162.07 GB.
Mar 02 11:02:23.000 [notice] Average packaged cell fullness: 99.115%
Mar 02 11:02:23.000 [notice] TLS write overhead: 3%
Mar 02 11:02:23.000 [notice] Circuit handshake stats since last time: 216438/216438 TAP, 170322/170322 NTor.
Mar 02 11:18:54.000 [err] tor_assertion_failed_(): Bug: ../src/or/buffers.c:2627: assert_buf_ok: Assertion ch->data < &ch->mem[0]+ch->memlen failed; aborting.
Mar 02 11:18:54.000 [err] Bug: Assertion ch->data < &ch->mem[0]+ch->memlen failed in assert_buf_ok at ../src/or/buffers.c:2627. Stack trace:
Mar 02 11:18:54.000 [err] Bug: /usr/bin/tor(log_backtrace+0x41) [0x7fc22b3d6191]
Mar 02 11:18:54.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x94) [0x7fc22b3e1d94]
Mar 02 11:18:54.000 [err] Bug: /usr/bin/tor(assert_buf_ok+0x167) [0x7fc22b3528a7]
Mar 02 11:18:54.000 [err] Bug: /usr/bin/tor(assert_connection_ok+0xce) [0x7fc22b38bbae]
Mar 02 11:18:54.000 [err] Bug: /usr/bin/tor(+0x35017) [0x7fc22b2fa017]
Mar 02 11:18:54.000 [err] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x754) [0x7fc22a94af24]
Mar 02 11:18:54.000 [err] Bug: /usr/bin/tor(do_main_loop+0x195) [0x7fc22b2fb7b5]
Mar 02 11:18:54.000 [err] Bug: /usr/bin/tor(tor_main+0x18f5) [0x7fc22b2fe7a5]
Mar 02 11:18:54.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7fc229b2bec5]
Mar 02 11:18:54.000 [err] Bug: /usr/bin/tor(+0x32f5b) [0x7fc22b2f7f5b]
**Trac**:
**Username**: amkihttps://gitlab.torproject.org/tpo/core/tor/-/issues/15127testing missing dependency on *_sha1.i2020-06-27T14:01:37Zweasel (Peter Palfrader)testing missing dependency on *_sha1.iOn Tor master,
```
--- src/common/src_common_libor_testing_a-util_codedigest.o ---
../tor/src/common/util_codedigest.c:10:10: fatal error: 'common_sha1.i' file not found
#include "common_sha1.i" ^
```
```
CC src/or/src_o...On Tor master,
```
--- src/common/src_common_libor_testing_a-util_codedigest.o ---
../tor/src/common/util_codedigest.c:10:10: fatal error: 'common_sha1.i' file not found
#include "common_sha1.i" ^
```
```
CC src/or/src_or_libtor_testing_a-config_codedigest.o
../tor/src/or/config_codedigest.c:10:10: fatal error: 'or_sha1.i' file not found
#include "or_sha1.i"
```
At least these appear to be fixed by
```
diff --git a/src/common/include.am b/src/common/include.am
index 5b63392..a642f7a 100644
--- a/src/common/include.am
+++ b/src/common/include.am
@@ -146,4 +146,5 @@ src/common/common_sha1.i: $(libor_SOURCES) $(libor_crypto_a_SOURCES) $(COMMONHEA
fi
src/common/util_codedigest.o: src/common/common_sha1.i
+src/common/src_common_libor_testing_a-util_codedigest.o: src/common/common_sha1.i
diff --git a/src/or/include.am b/src/or/include.am
index b44e109..e257ceb 100644
--- a/src/or/include.am
+++ b/src/or/include.am
@@ -190,6 +190,7 @@ ORHEADERS = \
noinst_HEADERS+= $(ORHEADERS) micro-revision.i
src/or/config_codedigest.o: src/or/or_sha1.i
+src/or/src_or_libtor_testing_a-config_codedigest.o: src/or/or_sha1.i
micro-revision.i: FORCE
@rm -f micro-revision.tmp; \
--
2.3.0
```Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15151connection_edge.c:1601:7: error: unused variable 'rv' [-Werror,-Wunused-varia...2020-06-27T14:01:37Zweasel (Peter Palfrader)connection_edge.c:1601:7: error: unused variable 'rv' [-Werror,-Wunused-variable]On freebsd-amd64, tor master
https://jenkins.torproject.org/view/Failed+Unstable/job/tor-ci-freebsd-amd64-master/4/consoleFull
```
12:40:13 --- src/or/connection_edge.o ---
12:40:13 ../tor/src/or/connection_edge.c:1601:7: error: unused ...On freebsd-amd64, tor master
https://jenkins.torproject.org/view/Failed+Unstable/job/tor-ci-freebsd-amd64-master/4/consoleFull
```
12:40:13 --- src/or/connection_edge.o ---
12:40:13 ../tor/src/or/connection_edge.c:1601:7: error: unused variable 'rv' [-Werror,-Wunused-variable]
12:40:13 int rv;
12:40:13 ^
12:40:13 1 error generated.
12:40:13 *** [src/or/connection_edge.o] Error code 1
```Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15157Spec issues with consensus' new 'package' field2020-06-27T14:01:37ZDamian JohnsonSpec issues with consensus' new 'package' fieldHi Nick. Brought these up on irc but moving to a ticket. Our consensus' new unused [packages field](https://gitweb.torproject.org/torspec.git/commit/?id=ab6453476066fd1bf5c8cb577863c0cdd5079e0f) has some spec issues...
* It isn't very f...Hi Nick. Brought these up on irc but moving to a ticket. Our consensus' new unused [packages field](https://gitweb.torproject.org/torspec.git/commit/?id=ab6453476066fd1bf5c8cb577863c0cdd5079e0f) has some spec issues...
* It isn't very future proof. It's fine for now, but I'm not sure how it could validly have new attributes in the future.
* Presently it necessitates at least one DIGEST entry. Think that's probably a mistake.
* 'one or more non-=, non-" " characters' => That's too imprecise. For instance, it allows newlines which I'm sure wouldn't really be valid.
* It would be nice if it said if a DIGESTTYPE can appear multiple times. I'd like to model this as a hash but I'm not sure if DIGESTTYPE are unique.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15176Refactor main loop for Shadow2020-06-27T14:01:37ZRob JansenRefactor main loop for ShadowLet's make it easier to run Shadow. Shadow has its own main loop. When calling into Tor, Tor should not loop infinitely, else Shadow will 'freeze' in Tor's loop and not work properly. Separating the main loop into the main parts, and the...Let's make it easier to run Shadow. Shadow has its own main loop. When calling into Tor, Tor should not loop infinitely, else Shadow will 'freeze' in Tor's loop and not work properly. Separating the main loop into the main parts, and the then each iteration of the loop into a separate function will make this easier.
Patch attached, created from Tor master.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15180Add make rule for verifying changes files format2020-06-27T14:01:37ZcypherpunksAdd make rule for verifying changes files formatThere is a maintenance script for verifying the format of changes files. Wouldn't it be a good idea to integrate it in the build configuration so developers can easily verify their changes files? This would improve the quality of the cha...There is a maintenance script for verifying the format of changes files. Wouldn't it be a good idea to integrate it in the build configuration so developers can easily verify their changes files? This would improve the quality of the changes files, leading to less work when building the changelog.
I already got a patch ready but i am wondering if anyone is interested in this feature.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15188Fix side-effect in tor_assert expr2020-06-27T14:01:36ZTvdWFix side-effect in tor_assert exprIn testing_common.c there's a call to tor_assert() that contains an expression with a side-effect. We should probably split those up.
Potential patch: https://github.com/TvdW/tor/commit/6e4f7704198d2b7332e6ec388e8c2ffbe51384b7In testing_common.c there's a call to tor_assert() that contains an expression with a side-effect. We should probably split those up.
Potential patch: https://github.com/TvdW/tor/commit/6e4f7704198d2b7332e6ec388e8c2ffbe51384b7Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15190Is rend-spec's 'service-authentication' a thing?2020-06-27T14:01:36ZDamian JohnsonIs rend-spec's 'service-authentication' a thing?Hi Nick, on legacy/trac#15004 I added hidden server descriptor parsing to Stem. donncha has been a fantastic help, providing test data and python crypto examples. Interestingly when we came to the rend-spec's [service-authentication](htt...Hi Nick, on legacy/trac#15004 I added hidden server descriptor parsing to Stem. donncha has been a fantastic help, providing test data and python crypto examples. Interestingly when we came to the rend-spec's [service-authentication](https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n328) lines he [wasn't able to find them in the tor codebase](https://trac.torproject.org/projects/tor/ticket/15004#comment:14).
Were they never implemented? They're very strange fields, prefixing encrypted introduction-points with a plaintext field. Stem presently has (untested) support for them but if they're not actually a thing we should drop them from the spec.Tor: 0.2.8.x-final