The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:01:07Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16260HS can repick an expired intro points or one that we've already picked2020-06-27T14:01:07ZDavid Gouletdgoulet@torproject.orgHS can repick an expired intro points or one that we've already pickedLet's assume here we are about to cycle our intro points in `rend_services_introduce()`, we do a dance and at the end we choose 3 new ones. To do that, we use `router_choose_random_node()` that picks a random node using the torrc `Exclud...Let's assume here we are about to cycle our intro points in `rend_services_introduce()`, we do a dance and at the end we choose 3 new ones. To do that, we use `router_choose_random_node()` that picks a random node using the torrc `ExcludeNodes` list but also an exclude_nodes list that we've populated before which contains expired intro points.
After that, we happily launch an intro circuit by calling `rend_service_launch_establish_intro()` and then `circuit_launch_by_extend_info()`. In there, a circuit can be cannibalized and if so, the exit node is NOT extended to our intro points that we picked earlier because of our purpose:
```
case CIRCUIT_PURPOSE_S_ESTABLISH_INTRO:
/* it's ready right now */
```
The IP is then changed to the one we just cannibalized once we have our circuit. This is not desirable for two reasons:
1) We ignore the exclude nodes list thus we can end up picking an expired IP.
2) We can use to the same IP multiple times for a single descriptor.
All of the above, I was able to reproduce in a chutney network that is having a set of IPs that expired in the previous period and a set of IPs that are all the same.
It's not that terrible in the real network because the probability of that happening is roughly `1/<relay count>` which is < 1% currently, still worth fixing imo.
Possible solution for this:
i) Use a 4th hop for the IP circuit meaning we allow cannibalization but we extend the circuit to the intro point.
ii) Disable cannibalization for intro point thus always creating a fresh circuit ending up at the right place.
My pick here would be i) because I think a 4th hop is cheaper than a creating a new circuit.
Comments welcome!Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16251Tor does not recognise libressl version and fails to compile on OpenBSD 5.62020-06-27T14:01:08ZTracTor does not recognise libressl version and fails to compile on OpenBSD 5.6Compiling tor from git returns:
`src/common/tortls.c:1451: undefined reference to `SSL_CIPHER_find'`
Latest commit on the git repo is, for reference: `90e07ab338cd59caeaeb31a3d207bb34d433b8ab`
User 'mancha' on #tor helped me pin the p...Compiling tor from git returns:
`src/common/tortls.c:1451: undefined reference to `SSL_CIPHER_find'`
Latest commit on the git repo is, for reference: `90e07ab338cd59caeaeb31a3d207bb34d433b8ab`
User 'mancha' on #tor helped me pin the problem. They supplied the following source code to test the SSL version currently in use:
{{{#include <stdio.h>
#include <openssl/crypto.h>
#define OPENSSL_VER(a,b,c,d,e) \
(((a)<<28) | \
((b)<<20) | \
((c)<<12) | \
((d)<< 4) | \
(e))
#define OPENSSL_V_SERIES(a,b,c) OPENSSL_VER((a),(b),(c),0,0)
int main()
{
printf("OPENSSL_VERSION_NUMBER : %x\n", OPENSSL_VERSION_NUMBER);
printf("OPENSSL_V_SERIES(1,0,2): %x\n", OPENSSL_V_SERIES(1,0,2));
return 0;
}
}}}
Compiling with `cc -o foo foo.c -lcrypto` returns:
```
OPENSSL_VERSION_NUMBER : 20000000
OPENSSL_V_SERIES(1,0,2): 10002000
```
Mancha also suggested the following patch:
```
--- a/src/common/tortls.c
+++ b/src/common/tortls.c
@@ -1440,7 +1440,7 @@ static int
find_cipher_by_id(const SSL *ssl, const SSL_METHOD *m, uint16_t cipher)
{
const SSL_CIPHER *c;
-#if OPENSSL_VERSION_NUMBER >= OPENSSL_V_SERIES(1,0,2)
+#if 0
{
unsigned char cipherid[3];
tor_assert(ssl);
```
Applying the patch makes tor compile successfully.
**Trac**:
**Username**: cwkTor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16248[Assertion] connection_stop_reading: Assertion conn->read_event failed; aborting2020-06-27T14:01:08Zyurivict271[Assertion] connection_stop_reading: Assertion conn->read_event failed; aborting<skipped>
> May 31 01:14:37.000 [notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $EC116BCB80565A408CE67F8EC3FE3B0B02C3A065~orion at 94.242.246.24. Retrying on a new circuit.
> May 31 01:14:37.000 [err] void tor_asse...<skipped>
> May 31 01:14:37.000 [notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $EC116BCB80565A408CE67F8EC3FE3B0B02C3A065~orion at 94.242.246.24. Retrying on a new circuit.
> May 31 01:14:37.000 [err] void tor_assertion_failed_(const char *, unsigned int, const char *, const char *)(): Bug: src/or/main.c:580: connection_stop_reading: Assertion conn->read_event failed; aborting.
> May 31 01:14:37.000 [err] Bug: Assertion conn->read_event failed in connection_stop_reading at src/or/main.c:580. (Stack trace not available)
This tor instance is only connected to the TransPort, with DNS to DNSPort.
I will be happy to provide any other information if I can.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16247revert commit 49bdfbab or don't overwrite isolation_flags2020-06-27T14:01:08ZTracrevert commit 49bdfbab or don't overwrite isolation_flagsDon't overwrite isolation flags.
**Trac**:
**Username**: jojelinoDon't overwrite isolation flags.
**Trac**:
**Username**: jojelinoTor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16244(Sandbox) Unexpected syscalls on relay2020-06-27T14:01:08ZGeorge Kadianakis(Sandbox) Unexpected syscalls on relayweasel reported the following sandxbox warnings on his relay:
```
(Sandbox) Caught a bad syscall attempt (syscall eventfd2)
/usr/bin/tor(+0x1328b6)[0x7f71180d18b6]
/lib/x86_64-linux-gnu/libc.so.6(eventfd+0xd)[0x7f711649e2fd]
/lib/x86_64-...weasel reported the following sandxbox warnings on his relay:
```
(Sandbox) Caught a bad syscall attempt (syscall eventfd2)
/usr/bin/tor(+0x1328b6)[0x7f71180d18b6]
/lib/x86_64-linux-gnu/libc.so.6(eventfd+0xd)[0x7f711649e2fd]
/lib/x86_64-linux-gnu/libc.so.6(eventfd+0xd)[0x7f711649e2fd]
/usr/bin/tor(alert_sockets_create+0xec)[0x7f71180bef9c]
```
```
(Sandbox) Caught a bad syscall attempt (syscall open)
/usr/bin/tor(+0x1328b6)[0x7f653db158b6]
/lib/x86_64-linux-gnu/libpthread.so.0(open64+0x10)[0x7f653c3b81d0]
/lib/x86_64-linux-gnu/libpthread.so.0(open64+0x10)[0x7f653c3b81d0]
/usr/bin/tor(tor_open_cloexec+0x40)[0x7f653daff5e0]
/usr/bin/tor(start_writing_to_file+0xf2)[0x7f653db10732]
/usr/bin/tor(+0x12d89b)[0x7f653db1089b]
/usr/bin/tor(+0x12d9e8)[0x7f653db109e8]
/usr/bin/tor(crypto_pk_write_private_key_to_filename+0xcb)[0x7f653db1f57b]
```
We should probably test the sandbox more thoroughly on relay-mode.
Here is the torrc used (to reproduce this):
```
Sandbox 1
PublishServerDescriptor 0
OrPort 9031
```Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16242Build fails with --enable-gcc-warnings and -Werror2020-06-27T14:01:08ZTracBuild fails with --enable-gcc-warnings and -WerrorBuilding master with --enable-gcc-warnings:
src/or/directory.c: In function ‘find_dl_schedule_and_len’:
src/or/directory.c:3482:1: error: control reaches end of non-void function [-Werror=return-type]
Patch in branch `fractalcat-fix-gc...Building master with --enable-gcc-warnings:
src/or/directory.c: In function ‘find_dl_schedule_and_len’:
src/or/directory.c:3482:1: error: control reaches end of non-void function [-Werror=return-type]
Patch in branch `fractalcat-fix-gcc-warning` at https://github.com/fractalcat/tor.git.
**Trac**:
**Username**: fractalcathttps://gitlab.torproject.org/tpo/core/tor/-/issues/16235identity-ed25519 is undocumented2020-06-27T14:01:08ZDamian Johnsonidentity-ed25519 is undocumentedOn reflection suspect you'd rather legacy/trac#16227 to be specifically about documenting future expansion. Spec 228 doesn't include a proposal for what would be added to the dir-spec. As such controllers like Stem, metrics-lib, and Brid...On reflection suspect you'd rather legacy/trac#16227 to be specifically about documenting future expansion. Spec 228 doesn't include a proposal for what would be added to the dir-spec. As such controllers like Stem, metrics-lib, and BridgeDB don't have a clear description on how they should be parsing this new content.
Happy to review it when we have a proposed spec addition.Tor: 0.2.7.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16228Double-free on failure to add ephemeral hidden services2020-06-27T14:01:08ZNick MathewsonDouble-free on failure to add ephemeral hidden servicesGiving this a number because it was in 0.2.7.1-alpha.Giving this a number because it was in 0.2.7.1-alpha.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16227Document which descriptor lines can have extra fields.2020-06-27T14:01:08ZDamian JohnsonDocument which descriptor lines can have extra fields.Hi, DocTor checks just notified me of an invalid extrainfo descriptor from a tor relay running Tor 0.2.7.1-alpha-dev...
```
router Truie 198.50.156.78 9001 0 9030
identity-ed25519
-----BEGIN ED25519 CERT-----
AQQABhWIAZTz0r0KRagr6X9SHfm...Hi, DocTor checks just notified me of an invalid extrainfo descriptor from a tor relay running Tor 0.2.7.1-alpha-dev...
```
router Truie 198.50.156.78 9001 0 9030
identity-ed25519
-----BEGIN ED25519 CERT-----
AQQABhWIAZTz0r0KRagr6X9SHfm4oiIuMLVhJQQmNchtkBuR5SuFAQAgBAAVkw7m
0YJgO/A8VMioco097sIOutDiM7UqqPvoIyKErk1akOm3f6VAO/juOzxEeAgzgfA7
DiRsSjeVjp0xUdE43bXhK/8Uh+SPMwYKj47drjgTHGgzjTmlY9B/jFJ1Wgs=
-----END ED25519 CERT-----
platform Tor 0.2.7.1-alpha-dev on Linux
protocols Link 1 2 Circuit 1
published 2015-05-28 15:44:47
fingerprint A692 21A7 EC74 98D2 F88A 0FB7 9526 1013 FA36 CAAE
uptime 61
bandwidth 1073741824 1073741824 9506816
extra-info-digest 0879DB7B765218D7B3AE7557669D20307BB21CAA V609l+N6ActBveebfNbH5lQ6wHDNstDkFgyqEhBHwtA
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBALbTpnPvhaGET+2ACtLdG6jhQXN8uVJ0iF9RwMh2hwu351yp3eVPt7os
ditUF6w7KV+6emkvLu9EBpNN7vWrpDAhRNOGTOZhZKLnGFaxp+eGNX6+5AhmiWYt
/+w+f6dvVKEjsaX3XZsMqcTBjw2hzVpHxh/AjgDx/b9mJKC85vENAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBALDSt2G+Zjl20a59HZsuag913ONdnnNa/uVMRbsZZkbnNRONf2aXBGgu
wrW7XtPLeAKl+d0d5g9XnePVvefcEdKvoKNCFv6s8s3S2KB/CEkeyE7Lxx1Pc6Qx
f/jgS3T3TFHUlvtZvHLZ/3WaXMyuTTRlGadpzDkQx5oWR6aNn065AgMBAAE=
-----END RSA PUBLIC KEY-----
onion-key-crosscert
-----BEGIN CROSSCERT-----
TCcCIv38fGcSzUO+DKxudFme2XBRuDkf5FjEr+6UbtDyuDjvjJDFYagN+zMJf/4K
RyBScjyKYK6MVMxAmf25QjAGx3KHV00ozVSzlN3WDAS2iicuKYvBsehG9g/tr6mI
luS5EoSKJIlmM2jOhN1QyR+Rpi37z/E6VTksk/bd69A=
-----END CROSSCERT-----
ntor-onion-key-crosscert 0
-----BEGIN ED25519 CERT-----
AQoABhNgARWTDubRgmA78DxUyKhyjT3uwg660OIztSqo++gjIoSuAEW8gwMcFUSD
mfkijKN6KyZxHloENGcgJMeJsR9kvfYp/u7O+VoPQ1kTxaw1lajTrnGQF+PV1MlK
niid4Nq5ZgM=
-----END ED25519 CERT-----
hidden-service-dir
contact 0x11F48D36 David Goulet <dgoulet AT ev0ke dot net>
ntor-onion-key qDcuoDpDD36bIapIbXBVhkIoiuMIXD9jNfjF1+7Vaks=
reject *:*
router-sig-ed25519 AxqrLz7QL/e+xGhhihs/rNzWsBW0Qla7Cwru1q88A5i+pcQBgfzfECiecptqYbDAsUPXMtwFsLp7Ls2BMOzvCQ
router-signature
-----BEGIN SIGNATURE-----
mSkveaqx79vzXLc6yC2+x8yZMQPe74ihw9tZJDdSOK5VqhzZOKHFM+JoD12noxQd
wgxa+IX0RG65KlguYE7NEZ7M6JOwr6r0zK/pWSZE8ZeHyt7FDx9ygc3k2ybQ6RWE
Hd7QXPiyVgs9cIgnvGFVt/5vzjMV+BELpOtehBrUJbs=
-----END SIGNATURE-----
```
I'm not sure if Truie is just doing something funky. identity-ed25519? router-sig-ed25519? None of these are things in the dir-spec, and its extra-info-digest line is invalid too.
Regardless of how this is being generated, seems like the DirAuths should be balking at such invalid content. Stem certainly doesn't like it when validation is enabled.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16216sandboxing breaks with systemd watchdog support2020-06-27T14:01:09Zweasel (Peter Palfrader)sandboxing breaks with systemd watchdog supportsystemd watchdog stuff opens a datagram unix socket to communicate with systemd.
Currently, our sandboxing rules don't allow that.
```
--- a/src/common/sandbox.c
+++ b/src/common/sandbox.c
@@ -170,6 +170,7 @@ static int filter_nopar_ge...systemd watchdog stuff opens a datagram unix socket to communicate with systemd.
Currently, our sandboxing rules don't allow that.
```
--- a/src/common/sandbox.c
+++ b/src/common/sandbox.c
@@ -170,6 +170,7 @@ static int filter_nopar_gen[] = {
SCMP_SYS(read),
SCMP_SYS(rt_sigreturn),
SCMP_SYS(sched_getaffinity),
+ SCMP_SYS(sendmsg),
SCMP_SYS(set_robust_list),
#ifdef __NR_sigreturn
SCMP_SYS(sigreturn),
@@ -551,6 +552,13 @@ sb_socket(scmp_filter_ctx ctx, sandbox_cfg_t *filter)
return rc;
rc = seccomp_rule_add_3(ctx, SCMP_ACT_ALLOW, SCMP_SYS(socket),
+ SCMP_CMP(0, SCMP_CMP_EQ, PF_UNIX),
+ SCMP_CMP_MASKED(1, SOCK_CLOEXEC|SOCK_NONBLOCK, SOCK_DGRAM),
+ SCMP_CMP(2, SCMP_CMP_EQ, 0));
+ if (rc)
+ return rc;
+
+ rc = seccomp_rule_add_3(ctx, SCMP_ACT_ALLOW, SCMP_SYS(socket),
SCMP_CMP(0, SCMP_CMP_EQ, PF_NETLINK),
SCMP_CMP(1, SCMP_CMP_EQ, SOCK_RAW),
SCMP_CMP(2, SCMP_CMP_EQ, 0));
```Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16215missing return value check in sb_socket()2020-06-27T14:01:09Zweasel (Peter Palfrader)missing return value check in sb_socket()All the other seccomp_rule_add calls check their return values. One doesn't.
It probably should conform.
```
--- a/src/common/sandbox.c
+++ b/src/common/sandbox.c
@@ -547,6 +547,8 @@ sb_socket(scmp_filter_ctx ctx, sandbox_cfg_t *filte...All the other seccomp_rule_add calls check their return values. One doesn't.
It probably should conform.
```
--- a/src/common/sandbox.c
+++ b/src/common/sandbox.c
@@ -547,6 +547,8 @@ sb_socket(scmp_filter_ctx ctx, sandbox_cfg_t *filter)
SCMP_CMP(0, SCMP_CMP_EQ, PF_UNIX),
SCMP_CMP_MASKED(1, SOCK_CLOEXEC|SOCK_NONBLOCK, SOCK_STREAM),
SCMP_CMP(2, SCMP_CMP_EQ, 0));
+ if (rc)
+ return rc;
rc = seccomp_rule_add_3(ctx, SCMP_ACT_ALLOW, SCMP_SYS(socket),
SCMP_CMP(0, SCMP_CMP_EQ, PF_NETLINK),
```Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16205bogus IP address / clock change from authority server2020-06-27T14:01:09ZTracbogus IP address / clock change from authority serverToday I found messages about bogus IP address and clock changes in my relay log (see attachment). My node:
https://atlas.torproject.org/#details/4E8CE6F5651E7342C1E7E5ED031E82078134FB0D
This caused the HSDir flag of my relay to be remov...Today I found messages about bogus IP address and clock changes in my relay log (see attachment). My node:
https://atlas.torproject.org/#details/4E8CE6F5651E7342C1E7E5ED031E82078134FB0D
This caused the HSDir flag of my relay to be removed...
**Trac**:
**Username**: rene0Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16204Use opaque trunnel structures?2020-06-27T14:01:09ZNick MathewsonUse opaque trunnel structures?Trunnel can generate code in "opaque mode" that hides all structure definitions and forces you to use accessor functions. In his review of legacy/trac#12498, dgoulet points out that I am a bit sloppy with using accessors for trunnel str...Trunnel can generate code in "opaque mode" that hides all structure definitions and forces you to use accessor functions. In his review of legacy/trac#12498, dgoulet points out that I am a bit sloppy with using accessors for trunnel structures.
IMO, we should decide whether our coding style requires the use of accessors. I hadn't thought that it did, but if we make that decisions, we should force accessor use by making structures opaque.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16202Include trunnel version used to generate trunnel C files?2020-06-27T14:01:09ZNick MathewsonInclude trunnel version used to generate trunnel C files?I'm okay with doing this if we can use git submodules or something to ensure that we never never have ours get out of sync with the real trunnel release. Divergence here would be eeeeevil.I'm okay with doing this if we can use git submodules or something to ensure that we never never have ours get out of sync with the real trunnel release. Divergence here would be eeeeevil.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16201Replace tinytest copy with git submodule?2020-06-27T14:01:09ZNick MathewsonReplace tinytest copy with git submodule?Can we use git submodules instead of copying the tinytest source into Tor directly?Can we use git submodules instead of copying the tinytest source into Tor directly?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16199Stop shipping generated Trunnel files in git repository2020-06-27T14:01:09ZNick MathewsonStop shipping generated Trunnel files in git repositoryTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16197Typos in prop 2242020-06-27T14:01:09ZdonnchaTypos in prop 224I've push a fix for two trivial typos in prop 224 to https://github.com/DonnchaC/torspec/commit/f508fabbb8869c70c9326a8f275ef762b9e337a4.
In section 2.5 Hidden service descriptors: encryption format - Where is the `nonce` used as input ...I've push a fix for two trivial typos in prop 224 to https://github.com/DonnchaC/torspec/commit/f508fabbb8869c70c9326a8f275ef762b9e337a4.
In section 2.5 Hidden service descriptors: encryption format - Where is the `nonce` used as input to the KDF specified. Is the nonce the `hsdir-shared-random` determined by the directory authorities?
```
secret_input = nonce | blinded_public_key | subcredential |
INT_4(revision_counter)
keys = KDF(secret_input, salt, "hsdir-encrypted-data",
S_KEY_LEN + S_IV_LEN + MAC_KEY_LEN)
```https://gitlab.torproject.org/tpo/core/tor/-/issues/16189Ensure our scrypt interoperates with openssl's scrypt2020-06-27T14:01:10ZNick MathewsonEnsure our scrypt interoperates with openssl's scryptIn e98aa30d555cb5a656d320a0f86ab5b3b1dce2db, openssl 1.1 adds an scrypt algorithm. Let's make sure we output the same results as them, so we can eventually not ship our own, and use theirs when it's available.In e98aa30d555cb5a656d320a0f86ab5b3b1dce2db, openssl 1.1 adds an scrypt algorithm. Let's make sure we output the same results as them, so we can eventually not ship our own, and use theirs when it's available.Tor: 0.2.7.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/16182Replacing an older pending vote from this directory (dannenberg.torauth.de)2020-07-24T17:47:30ZRoger DingledineReplacing an older pending vote from this directory (dannenberg.torauth.de)The directory authorities failed to produce a consensus earlier today. Here's our hint:
```
May 25 05:55:11.355 [notice] Replacing an older pending vote from this directory (dannenberg.torauth.de)
```
Why, at the :55:11 mark, was moria...The directory authorities failed to produce a consensus earlier today. Here's our hint:
```
May 25 05:55:11.355 [notice] Replacing an older pending vote from this directory (dannenberg.torauth.de)
```
Why, at the :55:11 mark, was moria1 willing to receive a new vote from dannenberg? This was after I'd published and received signatures, right? So it is way way too late?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16180Load Balancing/High Availability Onion Services2020-06-27T14:01:10ZdonnchaLoad Balancing/High Availability Onion ServicesThis will be the parent ticket for coordinating tasks during my Summer of Privacy project. The latest version of my proposal is available on Github https://gist.github.com/DonnchaC/03ad5cd0b8ead0ae9e30. The project schedule is available ...This will be the parent ticket for coordinating tasks during my Summer of Privacy project. The latest version of my proposal is available on Github https://gist.github.com/DonnchaC/03ad5cd0b8ead0ae9e30. The project schedule is available at wiki:doc/gsocdonnchadonncha