Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:01:54Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14280literal IPv6 addresses rejected when ipv4_traffic_ok flag isn't set2020-06-27T14:01:54ZNick Mathewsonliteral IPv6 addresses rejected when ipv4_traffic_ok flag isn't setIn 1053af0b9c4127873034a935ce3382940696e693, I made a copy-and-paste error. Patch will explain where.
I'm going to mark this as a possible backport, but recommend against it: nobody has run into this afaik.In 1053af0b9c4127873034a935ce3382940696e693, I made a copy-and-paste error. Patch will explain where.
I'm going to mark this as a possible backport, but recommend against it: nobody has run into this afaik.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14259memleak in connection_ap_handshake_rewrite_and_attach()2020-06-27T14:01:55ZGeorge Kadianakismemleak in connection_ap_handshake_rewrite_and_attach()I think there is a memleak in `connection_ap_handshake_rewrite_and_attach()`. Specifically, in this block of code:
```
if (socks->command == SOCKS_COMMAND_RESOLVE_PTR) {
unsigned rewrite_flags = 0;
if (conn->use_cached_ipv4_ans...I think there is a memleak in `connection_ap_handshake_rewrite_and_attach()`. Specifically, in this block of code:
```
if (socks->command == SOCKS_COMMAND_RESOLVE_PTR) {
unsigned rewrite_flags = 0;
if (conn->use_cached_ipv4_answers)
rewrite_flags |= AMR_FLAG_USE_IPV4_DNS;
if (conn->use_cached_ipv6_answers)
rewrite_flags |= AMR_FLAG_USE_IPV6_DNS;
if (addressmap_rewrite_reverse(socks->address, sizeof(socks->address),
rewrite_flags, &map_expires)) {
char *result = tor_strdup(socks->address);
/* remember _what_ is supposed to have been resolved. */
tor_snprintf(socks->address, sizeof(socks->address), "REVERSE[%s]",
orig_address);
connection_ap_handshake_socks_resolved(conn, RESOLVED_TYPE_HOSTNAME,
strlen(result), (uint8_t*)result,
-1,
map_expires);
connection_mark_unattached_ap(conn,
END_STREAM_REASON_DONE |
END_STREAM_REASON_FLAG_ALREADY_SOCKS_REPLIED);
return 0;
}
```
The `result` string is strdupped and passed to that function without it ever being freed.
I'm not sure if this code can be reached by - say - a malicious website.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14254Support all the port_cfg_t options for SocksSocket2020-06-27T14:01:55ZNick MathewsonSupport all the port_cfg_t options for SocksSocketThe new SocksSocket interface should support all the happyfun flags that SocksPort supports.The new SocksSocket interface should support all the happyfun flags that SocksPort supports.Tor: 0.2.6.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14224Two minutes after a failed hidserv connection, we do a bonus hsdesc fetch2020-06-27T14:01:55ZRoger DingledineTwo minutes after a failed hidserv connection, we do a bonus hsdesc fetchIf you do the steps to reproduce legacy/trac#14219, you end up eventually hanging up on the hidden service stream attempt: your controller events include
```
1421356924.815634 [torctl-log] localhost:9051 650 HS_DESC REQUESTED yjiqkj6p7dr...If you do the steps to reproduce legacy/trac#14219, you end up eventually hanging up on the hidden service stream attempt: your controller events include
```
1421356924.815634 [torctl-log] localhost:9051 650 HS_DESC REQUESTED yjiqkj6p7drpiwyq NO_AUTH $0B5E5E70FFEA9C7F9FFD13B8E16916A608F3E9EB~CalyxInstitute08 blwd4dzs2mnncf4wtc3bpv6pljwx5awb
1421356925.596473 [torctl-log] localhost:9051 650 HS_DESC RECEIVED yjiqkj6p7drpiwyq NO_AUTH $0B5E5E70FFEA9C7F9FFD13B8E16916A608F3E9EB~CalyxInstitute08
```
and your Tor debug log says
```
Jan 15 16:22:05.595 [info] connection_dir_client_reached_eof(): Received rendezvous descriptor (size 3254, status 200 ("OK"))
Jan 15 16:22:05.596 [info] rend_cache_store_v2_desc_as_client(): We already have a new enough service descriptor for service ID yjiqkj6p7drpiwyq with the same desc ID and version.
Jan 15 16:22:05.596 [info] connection_dir_client_reached_eof(): Successfully fetched v2 rendezvous descriptor.
Jan 15 16:22:05.596 [notice] Closing stream for 'yjiqkj6p7drpiwyq.onion': hidden service is unavailable (try again later).
Jan 15 16:22:05.596 [info] rend_client_note_connection_attempt_ended(): Connection attempt for yjiqkj6p7drpiwyq has ended; cleaning up temporary state.
Jan 15 16:22:05.596 [info] rend_client_note_connection_attempt_ended(): Connection attempt for yjiqkj6p7drpiwyq has ended; cleaning up temporary state.
```
and then your application stream gets closed.
Then two minutes later (!), you see these controller events:
```
1421357045.919921 [torctl-log] localhost:9051 650 HS_DESC REQUESTED yjiqkj6p7drpiwyq NO_AUTH $0B569B9F3999ACA1E7F52EA2C41841F9DDA89C3D~Unnamed blwd4dzs2mnncf4wtc3bpv6pljwx5awb
1421357047.114483 [torctl-log] localhost:9051 650 HS_DESC RECEIVED yjiqkj6p7drpiwyq NO_AUTH $0B569B9F3999ACA1E7F52EA2C41841F9DDA89C3D~Unnamed
```
It turns out that happens because the intro circuit finally closes:
```
Jan 15 16:24:05.918 [info] circuit_expire_building(): Abandoning circ 5 195.154.127.246:9001:2375802890 (state 1,3:open, purpose 6, len 6)
Jan 15 16:24:05.918 [info] internal circ (length 6): $4FEE77AFFD157BBCF2D896AE417FBF647860466C(open) $F4F605AA21C4633CCB5B8DBBC1CEEE5C590C6DCE(open) $B6D30CEC9F8FAB676CCD0634DC86412F1BA8F4D2(open) $5B3B9A0EA1DC16F6348C57FCC83BBB43D1013F4A(open) $10B6A20E3F1D0C0742053A19242AB61586A5B9B4(open) $D51C1F3A39FB0BCA12D2795F67B1FA93A750218D(open)
```
which is reasonable, except, then:
```
Jan 15 16:24:05.918 [info] circuit_mark_for_close_(): Failed intro circ yjiqkj6p7drpiwyq to $D51C1F3A39FB0BCA12D2795F67B1FA93A750218D (building circuit to intro point). Marking intro point as possibly unreachable.
Jan 15 16:24:05.918 [info] rend_client_report_intro_point_failure(): Unknown service "yjiqkj6p7drpiwyq". Re-fetching descriptor.
Jan 15 16:24:05.918 [debug] rend_client_refetch_v2_renddesc(): Fetching v2 rendezvous descriptor for service yjiqkj6p7drpiwyq
```
It looks like the closing of the intro circuit, 2 minutes later, triggers another fetching of a descriptor!Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14222rend_cache_entry_t->received is never used; remove?2020-06-27T14:01:55ZRoger Dingledinerend_cache_entry_t->received is never used; remove?```
diff --git a/src/or/or.h b/src/or/or.h
index 8a15529..5ecd5f3 100644
--- a/src/or/or.h
+++ b/src/or/or.h
@@ -4962,7 +4962,6 @@ typedef struct rend_service_descriptor_t {
/** A cached rendezvous descriptor. */
typedef struct rend_ca...```
diff --git a/src/or/or.h b/src/or/or.h
index 8a15529..5ecd5f3 100644
--- a/src/or/or.h
+++ b/src/or/or.h
@@ -4962,7 +4962,6 @@ typedef struct rend_service_descriptor_t {
/** A cached rendezvous descriptor. */
typedef struct rend_cache_entry_t {
size_t len; /**< Length of <b>desc</b> */
- time_t received; /**< When was the descriptor received? */
time_t last_served; /**< When did we last write this one to somebody?
* (HSDir only) */
char *desc; /**< Service descriptor */
diff --git a/src/or/rendcommon.c b/src/or/rendcommon.c
index 88d9aab..f83d9d5 100644
--- a/src/or/rendcommon.c
+++ b/src/or/rendcommon.c
@@ -1058,7 +1058,6 @@ rend_cache_store_v2_desc_as_dir(const char *desc)
if (e && !strcmp(desc, e->desc)) {
log_info(LD_REND, "We already have this service descriptor with desc "
"ID %s.", safe_str(desc_id_base32));
- e->received = time(NULL);
goto skip;
}
/* Store received descriptor. */
@@ -1075,7 +1074,6 @@ rend_cache_store_v2_desc_as_dir(const char *desc)
rend_service_descriptor_free(e->parsed);
tor_free(e->desc);
}
- e->received = time(NULL);
e->parsed = parsed;
e->desc = tor_strndup(current_desc, encoded_size);
e->len = encoded_size;
@@ -1261,7 +1259,6 @@ rend_cache_store_v2_desc_as_client(const char *desc,
if (e && !strcmp(desc, e->desc)) {
log_info(LD_REND,"We already have this service descriptor %s.",
safe_str_client(service_id));
- e->received = time(NULL);
goto okay;
}
if (!e) {
@@ -1272,7 +1269,6 @@ rend_cache_store_v2_desc_as_client(const char *desc,
rend_service_descriptor_free(e->parsed);
tor_free(e->desc);
}
- e->received = time(NULL);
e->parsed = parsed;
e->desc = tor_malloc_zero(encoded_size + 1);
strlcpy(e->desc, desc, encoded_size + 1);
```
The field of the struct is written to but never used. Did we have a plan for it? Or should we simplify and get rid of it?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14219Visiting a down hidden service that was recently up results in many hsdesc fe...2020-06-27T14:01:56ZRoger DingledineVisiting a down hidden service that was recently up results in many hsdesc fetchesRun a hidden service, so it correctly establishes intro points and uploads its descriptor correctly. Then shut off the hidden service.
Then try to visit it, and watch your HS_DESC control events. You get something like:
```
1421275707.2...Run a hidden service, so it correctly establishes intro points and uploads its descriptor correctly. Then shut off the hidden service.
Then try to visit it, and watch your HS_DESC control events. You get something like:
```
1421275707.240294 [torctl-log] localhost:9051 650 HS_DESC REQUESTED yjiqkj6p7drpiwyq NO_AUTH $0011BD2485AD45D984EC4159C88FC066E5E3300E~CalyxInstitute14 776oil3sjfhbxkj6eewqu3mtzrsnesm2
1421275708.081418 [torctl-log] localhost:9051 650 HS_DESC RECEIVED yjiqkj6p7drpiwyq NO_AUTH $0011BD2485AD45D984EC4159C88FC066E5E3300E~CalyxInstitute14
1421275710.275964 [torctl-log] localhost:9051 650 HS_DESC REQUESTED yjiqkj6p7drpiwyq NO_AUTH $1D6A27AED313662E35F550B212335D4797DCCDF6~CriptoLabTORRelay3 dvcsya66ae4vvzekabjojyrgkdcttnfh
1421275711.550731 [torctl-log] localhost:9051 650 HS_DESC RECEIVED yjiqkj6p7drpiwyq NO_AUTH $1D6A27AED313662E35F550B212335D4797DCCDF6~CriptoLabTORRelay3
1421275713.156023 [torctl-log] localhost:9051 650 HS_DESC REQUESTED yjiqkj6p7drpiwyq NO_AUTH $002121252467538C9DA1BC2378997E64629814F6~metroholografix 776oil3sjfhbxkj6eewqu3mtzrsnesm2
1421275713.767901 [torctl-log] localhost:9051 650 HS_DESC RECEIVED yjiqkj6p7drpiwyq NO_AUTH $002121252467538C9DA1BC2378997E64629814F6~metroholografix
1421275716.254822 [torctl-log] localhost:9051 650 HS_DESC REQUESTED yjiqkj6p7drpiwyq NO_AUTH $000F18AC2CDAE4C710BA0898DC9E21E72E0117D8~TorNinurtaName 776oil3sjfhbxkj6eewqu3mtzrsnesm2
1421275717.405024 [torctl-log] localhost:9051 650 HS_DESC RECEIVED yjiqkj6p7drpiwyq NO_AUTH $000F18AC2CDAE4C710BA0898DC9E21E72E0117D8~TorNinurtaName
```
In this case I fetched the hsdesc four times for the service. According to the original design, I was supposed to fetch it twice: that is, I fetch it once, try all the intro points, once they've all failed, I fetch it once more just to see if it changed, and if it didn't change, I should stop and fail right then.
So: is there a bug where we continue rather than failing? Or is the descriptor that I receive different in each case? What's going on?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14215Test checkdir/perms depends on global umask2020-06-27T14:01:56ZcypherpunksTest checkdir/perms depends on global umaskThe failure/success of the test `checkdir/perms` depends on the global umask. If the global umask is `022` (the default), all tests pass. If the global umask is `077`, the sub-test `checkdir_new_groupok_err` fails.The failure/success of the test `checkdir/perms` depends on the global umask. If the global umask is `022` (the default), all tests pass. If the global umask is `077`, the sub-test `checkdir_new_groupok_err` fails.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14202Remove obsolete workaround from dirserv_thinks_router_is_hs_dir()2020-06-27T14:01:56ZGeorge KadianakisRemove obsolete workaround from dirserv_thinks_router_is_hs_dir()There is this comment and code in `dirserv_thinks_router_is_hs_dir()` that can safely be removed now that tor-0.2.x is deprecated, right?
```
/* XXX We shouldn't need to check dir_port, but we do because of
* bug 1693. In the futur...There is this comment and code in `dirserv_thinks_router_is_hs_dir()` that can safely be removed now that tor-0.2.x is deprecated, right?
```
/* XXX We shouldn't need to check dir_port, but we do because of
* bug 1693. In the future, once relays set wants_to_be_hs_dir
* correctly, we can revert to only checking dir_port if router's
* version is too old. */
/* XXX Unfortunately, we need to keep checking dir_port until all
* *clients* suffering from bug 2722 are obsolete. The first version
* to fix the bug was 0.2.2.25-alpha. */
return (router->wants_to_be_hs_dir && router->dir_port &&
uptime >= get_options()->MinUptimeHidServDirectoryV2 &&
router_is_active(router, node, now));
```Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14195Memory leak in addressmap_register_virtual_address2020-06-27T14:01:57ZNick MathewsonMemory leak in addressmap_register_virtual_addressThere's a memory leak when using virtual addresses. I'll post a self-explanatory patch.There's a memory leak when using virtual addresses. I'll post a self-explanatory patch.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14193set *expires_out correctly in addressmap_rewrite2020-06-27T14:01:57ZNick Mathewsonset *expires_out correctly in addressmap_rewriteRight now, *expires_out is set unconditionally to TIME_MAX at the end of addressmap_rewrite. That's wrong.Right now, *expires_out is set unconditionally to TIME_MAX at the end of addressmap_rewrite. That's wrong.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14192Map address mapping tested and sane2020-06-27T14:01:57ZNick MathewsonMap address mapping tested and saneThis is a parent ticket to track various children.This is a parent ticket to track various children.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14189Silence implicit uint64_t to size_t conversion warnings in clang on 32-bit OS X2020-06-27T14:01:57ZteorSilence implicit uint64_t to size_t conversion warnings in clang on 32-bit OS XThe out of memory checking code performs a calculation based on the difference between the memory used (a `size_t`) and the memory limit (a `uint64_t`).
This causes warnings in clang about implicit conversions losing precision. To ensur...The out of memory checking code performs a calculation based on the difference between the memory used (a `size_t`) and the memory limit (a `uint64_t`).
This causes warnings in clang about implicit conversions losing precision. To ensure this isn't happening, I assert `MaxMemInQueues <= SIZE_T_MAX` before casting.
Branch will be posted after I have the bug number.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14188OpenSSL 1.1.0-dev change: builds without deprecated functions by default2020-06-27T14:01:57ZteorOpenSSL 1.1.0-dev change: builds without deprecated functions by defaultDue to the following OpenSSL change:
```
*) config has been changed so that by default OPENSSL_NO_DEPRECATED is used.
Access to deprecated functions can be re-enabled by running config with
"enable-deprecated". In addition a...Due to the following OpenSSL change:
```
*) config has been changed so that by default OPENSSL_NO_DEPRECATED is used.
Access to deprecated functions can be re-enabled by running config with
"enable-deprecated". In addition applications wishing to use deprecated
functions must define OPENSSL_USE_DEPRECATED. Note that this new behaviour
will, by default, disable some transitive includes that previously existed
in the header files (e.g. ec.h will no longer, by default, include bn.h)
[Matt Caswell]
```
Building tor git with the latest OpenSSL 1.1.0-dev git causes the following errors on OS X with clang (edited for brevity):
```
CC src/common/tortls.o
src/common/crypto.c:408:3: error: implicit declaration of function
'ERR_remove_state' is invalid in C99
ERR_remove_state(0);
src/common/crypto.c:1783:19: error: implicit declaration of function
'DH_generate_parameters' is invalid in C99
dh_parameters = DH_generate_parameters(DH_BYTES*8, DH_GENERATOR, NULL, NULL);
src/common/crypto.c:1783:19: note: did you mean 'DH_generate_parameters_ex'?
/test/tor/openssl-install-x86_64/include/openssl/dh.h:213:5: note:
'DH_generate_parameters_ex' declared here
int DH_generate_parameters_ex(DH *dh, int prime_len,int generator, B...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC src/trunnel/pwbox.o
src/common/crypto.c:3131:3: error: implicit declaration of function
'CRYPTO_set_id_callback' is invalid in C99
CRYPTO_set_id_callback(tor_get_thread_id);
4 errors generated.
make[1]: *** [src/common/crypto.o] Error 1
src/common/tortls.c:675:27: error: implicit declaration of function 'BN_bin2bn'
is invalid in C99
if (!(serial_number = BN_bin2bn(serial_tmp, sizeof(serial_tmp), NULL)))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/common/tortls.c:713:5: error: implicit declaration of function
'BN_clear_free' is invalid in C99
BN_clear_free(serial_number);
src/common/tortls.c:1069:16: error: implicit declaration of function
'BN_num_bits' is invalid in C99
if (rsa && BN_num_bits(rsa->n) == 1024)
src/common/tortls.c:1069:31: error: incomplete definition of type
'struct rsa_st'
if (rsa && BN_num_bits(rsa->n) == 1024)
/test/tor/openssl-install-x86_64/include/openssl/ossl_typ.h:147:16: note:
forward declaration of 'struct rsa_st'
typedef struct rsa_st RSA;
src/common/tortls.c:1072:7: error: implicit declaration of function 'RSA_free'
is invalid in C99
RSA_free(rsa);
src/common/tortls.c:1072:7: note: did you mean 'SSL_free'?
/test/tor/openssl-install-x86_64/include/openssl/ssl.h:2201:6: note: 'SSL_free'
declared here
void SSL_free(SSL *ssl);
```
Building OpenSSL with `./Configure enable-deprecated` and including `-DOPENSSL_USE_DEPRECATED` in the CPPFLAGS seems to require a few tries to actually work. (I don't think it likes parallel builds.)
Building tor with this new version then works fine.
~~ causes a linker error: ~~ (This is actually due to OpenSSL not working with parallel builds.)
```
Undefined symbols for architecture x86_64:
"_EVP_aes_128_ctr", referenced from:
_aes_new_cipher in libor-crypto.a(aes.o)
```
We should probably fix this by 0.2.6-final, otherwise it won't be able to be built with OpenSSL 1.1.0 dev out of the box.
But how are we going to cope with platforms that build OpenSSL without deprecated functions?
Conditionalise on `#if OPENSSL_USE_DEPRECATED`s in the code?
Advise them not to?
It seems like this change could cause a huge mess.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14184Control port command "getinfo entry-guards" return all guards with the "up" s...2020-06-27T14:01:58ZDavid Gouletdgoulet@torproject.orgControl port command "getinfo entry-guards" return all guards with the "up" state`getinfo entry-guards` returns a list of guards that are all flagged as "up" even though the state file shows only one of them is actually up and all others are down.`getinfo entry-guards` returns a list of guards that are all flagged as "up" even though the state file shows only one of them is actually up and all others are down.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14170Build broken on any platform lacking systemd2020-06-27T14:01:58ZSebastian HahnBuild broken on any platform lacking systemda8999acc3bca05f1aaa23399c7d5f7a5e51789a4 which was supposed to fix building of the systemd watchdog broke building on any platform without systemd. Just reverting that commit for now seems like the wrong idea, however, because the underl...a8999acc3bca05f1aaa23399c7d5f7a5e51789a4 which was supposed to fix building of the systemd watchdog broke building on any platform without systemd. Just reverting that commit for now seems like the wrong idea, however, because the underlying issue still exists which isn't being addressed at all - the systemd configure check fails. I have a patch in branch systemd209 in my repo, but building that on my systemd-enabled jessie produces linking errors at the very end. I'm not too well versed in the systemd world, our entire detection magic needs to be checked for all cases because right now we even get the non-corner cases wrong.
This was first reported by Toralf Förster <toralf.foerster@gmx.de> on #tor-dev as indicated in my commit msgTor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14169Tor requires systemd2020-06-27T14:01:58ZcypherpunksTor requires systemdconfigure: error: Package requirements (systemd >= 209) were not met:
No package 'systemd' found
trying ./configure --disable-systemd does not help.configure: error: Package requirements (systemd >= 209) were not met:
No package 'systemd' found
trying ./configure --disable-systemd does not help.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14162Stack traces broken in git master for me2020-06-27T14:01:59ZNick MathewsonStack traces broken in git master for meAccording to "git bisect", this problem begin with fcc78e5f8a3249eadfea31db1aca6884b31c1873.
How exciting. To reproduce, run "make check-local" and verify that you see:
```
./src/test/test-bt-cl assert | python ./src/test/bt_test.py
B...According to "git bisect", this problem begin with fcc78e5f8a3249eadfea31db1aca6884b31c1873.
How exciting. To reproduce, run "make check-local" and verify that you see:
```
./src/test/test-bt-cl assert | python ./src/test/bt_test.py
BAD
./src/test/test-bt-cl crash | python ./src/test/bt_test.py
BAD
```Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14149Update spec with regards to 25-26 hours HSDir flag uptime that turned to 96 h...2020-06-27T14:01:59ZGeorge KadianakisUpdate spec with regards to 25-26 hours HSDir flag uptime that turned to 96 hours.During the lizard attacks many dirauths changed `MinUptimeHidServDirectoryV2` to 96 hours from the previous 26 hours. We should probably update the spec and maybe also make it the new default?During the lizard attacks many dirauths changed `MinUptimeHidServDirectoryV2` to 96 hours from the previous 26 hours. We should probably update the spec and maybe also make it the new default?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14145Fix a typo in util.c comment2020-06-27T14:01:59ZteorFix a typo in util.c commentHi Nick, can you merge **fix-typos** from my github repository **teor2345/tor**?
It's just a misspelling in a comment in util.c.Hi Nick, can you merge **fix-typos** from my github repository **teor2345/tor**?
It's just a misspelling in a comment in util.c.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14141enhancments and fixes for systemd support2020-06-27T14:01:59ZTracenhancments and fixes for systemd supportThe following patch series contains:
1) fix unit & code to work with both RunAsDaemon = 0 or 1
2) improve information about state presented to administrator
3) fix and enable watchdog support
Detailed descriptions inside each patch.
...The following patch series contains:
1) fix unit & code to work with both RunAsDaemon = 0 or 1
2) improve information about state presented to administrator
3) fix and enable watchdog support
Detailed descriptions inside each patch.
**Trac**:
**Username**: tomek@pipebreaker.plTor: 0.2.6.x-final