Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:08:26Zhttps://gitlab.torproject.org/legacy/trac/-/issues/22138Crash on connecting to address2020-06-13T15:08:26ZTracCrash on connecting to addressTor built from git:master crashes with the following stack on accessing address.
```
#0 tor_memcmp (a=0x5662880, b=b@entry=0x0, len=len@entry=20) at src/common/di_[ops.c:49 ops.c:49]
v1 = 17v2 = <optimized out>equal_p = <optimized o...Tor built from git:master crashes with the following stack on accessing address.
```
#0 tor_memcmp (a=0x5662880, b=b@entry=0x0, len=len@entry=20) at src/common/di_[ops.c:49 ops.c:49]
v1 = 17v2 = <optimized out>equal_p = <optimized out>x = 0x5662880 "\217\"\257\335\006\252B8\255\331:\216\246\373»\234e'\021"y = 0x0i = 19retval = 0
#1 0x00000000004dd3c6 in get_desc_id_from_query (hsdir_fp=0x0, rend_data=0x4f57ba0) at src/or/control.c:6934
fingerprint_sl_idx = <optimized out>fingerprint_sl_len = <optimized out>fingerprint = <optimized out>digest = 0x4f57bd9 "\217\034,\251\245Y\210\262", <incomplete sequence \370\227\027\270>replica = 0desc_id = 0x0
#2 control_event_hs_descriptor_receive_end (action=action@entry=0x7ba4aa <compress_diffs_with+9258> "FAILED",
onion_address=0x4f57bc8 "g7pz322wcy6jnn4r", rend_data=rend_data@entry=0x4f57ba0, id_digest=id_digest@entry=0x0,reason=reason@entry=0x7746aa <__FUNCTION__.56891+842> "QUERY_NO_HSDIR") at src/or/control.c:7022
desc_id_field = 0x0reason_field = 0x0desc_id_base32 = "\240\262\212\000\000\000\000\000\360\366\"\000\000\000\000\000@\370\"\000\000\000\000\000T\b\360#\341\270", <incomplete sequence \312>desc_id = 0x0__FUNCTION__ = "control_event_hs_descriptor_receive_end"
#3 0x00000000004dd856 in control_event_hs_descriptor_failed (rend_data=rend_data@entry=0x4f57ba0,
id_digest=id_digest@entry=0x0, reason=reason@entry=0x7746aa <__FUNCTION__.56891+842> "QUERY_NO_HSDIR")at src/or/control.c:7136
__FUNCTION__ = "control_event_hs_descriptor_failed"
#4 0x00000000004313d6 in directory_get_from_hs_dir (desc_id=<optimized out>, rend_query=0x4f57ba0, rs_hsdir=<optimized out>)
at src/or/rendclient.c:727
hs_dir = <optimized out>hsdir_fp = <optimized out>desc_id_base32 = "r4oczknflgelf6exc64aackbgnmnd4gr"descriptor_cookie_base64 = "\000\224!\001", '\000' <repeats 20 times>, "\001\000\000\000\000\000\000\000\200\234!\001\000\000\000\000T\b\360#\341\270,\312\067ߝ\353V\026<\226\267\221T\000\000\000\000\000x\220"__func__ = "directory_get_from_hs_dir"__FUNCTION__ = "directory_get_from_hs_dir"req = <optimized out>
#5 0x00000000004319b1 in fetch_v2_desc_by_addr (hsdirs=0x0, rend_query=0x4f57ba0) at src/or/rendclient.c:870
rand_val = <optimized out>chosen_replica = <optimized out>descriptor_id = "\217\034,\251\245Y\210\262\370\227\027\270\000\tA3X\321", <incomplete sequence \360\321>i = 2ret = <optimized out>replicas_left_to_try = {1, 1}tries_left = 1
#6 rend_client_fetch_v2_desc (query=0x4f57ba0, hsdirs=0x0) at src/or/rendclient.c:911
onion_address = <optimized out>
#7 0x00000000004322e4 in rend_client_refetch_v2_renddesc (rend_query=0x4f57ba0) at src/or/rendclient.c:951
e = 0x0onion_address = 0x4f57bc8 "g7pz322wcy6jnn4r"__func__ = "rend_client_refetch_v2_renddesc"__FUNCTION__ = "rend_client_refetch_v2_renddesc"
#8 0x00000000004e9173 in connection_dir_about_to_close (dir_conn=dir_conn@entry=0x48bd320) at src/or/directory.c:3071
conn = 0x48bd320
#9 0x00000000004b85c7 in connection_about_to_close_connection (conn=conn@entry=0x48bd320) at src/or/connection.c:722
__func__ = "connection_about_to_close_connection"
#10 0x0000000000403dbf in connection_unlink (conn=0x48bd320) at src/or/main.c:350
No locals.
#11 0x0000000000404562 in conn_close_if_marked (i=<optimized out>) at src/or/main.c:906
conn = <optimized out>retval = <optimized out>
#12 close_closeable_connections () at src/or/main.c:698
conn = <optimized out>i = 0
#13 0x0000000000594592 in event_base_loop ()
No symbol table info available.
#14 0x0000000000405965 in run_main_loop_once () at src/or/main.c:2560
loop_result = <optimized out>
#15 run_main_loop_until_done () at src/or/main.c:2614
No locals.
#16 do_main_loop () at src/or/main.c:2527
__FUNCTION__ = "do_main_loop"__func__ = "do_main_loop"
#17 0x000000000040951f in tor_main (argc=argc@entry=5, argv=argv@entry=0x1207ef0) at src/or/main.c:3683
result = <optimized out>hMod = <optimized out>__FUNCTION__ = "tor_main"
#18 0x000000000074406c in main (argc=5, argv=0x1207ef0) at src/or/tor_[main.c:34 main.c:34]
r = <optimized out>
```
**Trac**:
**Username**: harigTor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22128Refactor body of connection_dir_client_reached_eof()2020-06-13T15:08:25ZNick MathewsonRefactor body of connection_dir_client_reached_eof()What's this 630-line function doing in our codebase?What's this 630-line function doing in our codebase?Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22114Fix wrong comments in doc/torrc_format.txt2020-06-13T15:08:23ZGeorg KoppenFix wrong comments in doc/torrc_format.txtI had the pleasure to look at the `torrc` format recently and while reading about it in more depth in `torrc_format.txt` and playing with the test, I realized two of the comments in that .txt file need to get updated as the value shown i...I had the pleasure to look at the `torrc` format recently and while reading about it in more depth in `torrc_format.txt` and playing with the test, I realized two of the comments in that .txt file need to get updated as the value shown in them is wrong.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22111lzma and zstd configure options have the same description2020-06-13T15:08:23Zteorlzma and zstd configure options have the same descriptionWhen I run ./configure, I get:
```
--enable-lzma enable support for the Zstandard compression scheme.
--enable-zstd enable support for the Zstandard compression scheme.
```When I run ./configure, I get:
```
--enable-lzma enable support for the Zstandard compression scheme.
--enable-zstd enable support for the Zstandard compression scheme.
```Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22105define a more generic LIBFUZZER = ... in Makefile.in2020-06-13T15:08:20Ztoralfdefine a more generic LIBFUZZER = ... in Makefile.inThe current value
```
LIBFUZZER = /home/nickm/build/libfuzz/libFuzzer.a
```
isn't portable enough IMO.
BTW if I configure the sources (with clang 3.9.1):
```
CC="clang" ./configure --config-cache --enable-expensive-hardening --enable-lib...The current value
```
LIBFUZZER = /home/nickm/build/libfuzz/libFuzzer.a
```
isn't portable enough IMO.
BTW if I configure the sources (with clang 3.9.1):
```
CC="clang" ./configure --config-cache --enable-expensive-hardening --enable-libfuzzer
```
then I run during make into
```
$ make
make all-am
make[1]: Entering directory '/home/tfoerste/devel/tor'
AR src/ext/keccak-tiny/libkeccak-tiny.a
AR src/trunnel/libor-trunnel.a
CC src/ext/trunnel/src_trunnel_libor_trunnel_testing_a-trunnel.o
clang-3.9: error: unsupported argument 'trace-pc-guard' to option 'fsanitize-coverage='
clang-3.9: error: unsupported argument 'trace-div' to option 'fsanitize-coverage='
make[1]: *** [Makefile:7704: src/ext/trunnel/src_trunnel_libor_trunnel_testing_a-trunnel.o] Error 1
make[1]: Leaving directory '/home/tfoerste/devel/tor'
make: *** [Makefile:3044: all] Error 2
```
at a stable (hardened) Gentoo Linux.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22103confparse.c checks pointer instead of value (!ok)2020-06-13T15:08:20ZTracconfparse.c checks pointer instead of value (!ok)## Description
In `src/or/confparse.c`, functions `conf_parse_msec_interval()` and `conf_parse_interval()` incorrectly check a pointer instead of the pointed-to value. Patch attached.
## Impact
When `config_parse_units()` hits an err...## Description
In `src/or/confparse.c`, functions `conf_parse_msec_interval()` and `conf_parse_interval()` incorrectly check a pointer instead of the pointed-to value. Patch attached.
## Impact
When `config_parse_units()` hits an error, these functions may return `0` as a valid value instead of `-1` as an error.
## Security evaluation
Far worse could be done by any attacker with sufficient access to feed malicious data to these functions. Thus, I don’t see how it could be exploited as a practical matter.
## `note[0]`
From my `~/tor/BUGS.txt` with mtime 2014-03-19T03:07:45Z. So sorry I did not report it sooner. I could have been rich and famous!
```
#include <stdio.h>
#define ME "nullius@nym.zone"
#define PGP "0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C"
int
main(int argc, char *argv[])
{
printf("Hello, world! <%s>\nPGP: %s\n", ME, PGP);
return (0);
}
```
## `note[1]`
Use of the variable `ok` is inconsistent in `confparse.c`. In `config_assign_value()`, `ok` is an `int`. Elsewhere, pointer to `int`. That’s not ok! Also, there is a confusing `tor_assert(ok);` to check for non-`NULL` pointer; KNF style would prescribe the check to be explicit `tor_assert(ok != NULL);`, for a reason. (The actual bug concerns a Boolean check, so `if (!*ok)` is stylistically sane.) I could open a separate bug and/or do some minor refactoring, if committers were to express an interest in making `ok` more ok.
**Trac**:
**Username**: nulliusTor: 0.3.1.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/22096Increase MALLOC_MP_LIM in sandbox.c2020-06-13T15:08:16ZNick MathewsonIncrease MALLOC_MP_LIM in sandbox.cSee diagnosis at comment:15:ticket:21648 . Now that worker threads can malloc a bit more, they can need to mprotect(...PROT_WRITE) larger chunks. This requires an increase in MALLOC_MP_LIM.
In the longer term, we should replace our sa...See diagnosis at comment:15:ticket:21648 . Now that worker threads can malloc a bit more, they can need to mprotect(...PROT_WRITE) larger chunks. This requires an increase in MALLOC_MP_LIM.
In the longer term, we should replace our sandbox's string-interning hack with a privileged helper hack.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21406The channel is_client flag is inaccurate2020-06-13T15:08:15ZteorThe channel is_client flag is inaccurateThe channel_t is_client flag is inaccurate: relays set it when the other end uses a CREATE_FAST cell, but usecreatefast is set to 0 in the consensus.
This means that the only time CREATE_FAST is used is when a relay gets an extend reque...The channel_t is_client flag is inaccurate: relays set it when the other end uses a CREATE_FAST cell, but usecreatefast is set to 0 in the consensus.
This means that the only time CREATE_FAST is used is when a relay gets an extend request *without* an ntor key, and the purpose of the circuit is *not* one of the hidden service purposes where TAP is allowed.
See should_use_create_fast_for_circuit() for details.Tor: 0.3.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/22086Make NO_METHOD a real legit compression method2020-06-13T15:08:14ZNick MathewsonMake NO_METHOD a real legit compression methodThere are a few places in the code that do something like
```
if (compressing) {
tor_compress(...)
} else {
memcpy(...)
}
```
Wouldn't it be great if they could just call tor_compress unconditionally?
They can, if NO_ME...There are a few places in the code that do something like
```
if (compressing) {
tor_compress(...)
} else {
memcpy(...)
}
```
Wouldn't it be great if they could just call tor_compress unconditionally?
They can, if NO_METHOD is treated as a real compression method!Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22085Refactor and simplify compression tests2020-06-13T15:08:14ZAlexander Færøyahf@torproject.orgRefactor and simplify compression testsThe current compression tests contains a lot of copy and pasted source code. We should unify that to ensure that all the compression backends are tested at different compression levels.The current compression tests contains a lot of copy and pasted source code. We should unify that to ensure that all the compression backends are tested at different compression levels.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22069Fix two coverity false positives2020-06-13T15:08:13ZSebastian HahnFix two coverity false positivesBranch coverity in my repoBranch coverity in my repoTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22066Add memory measurement code in LZMA and Zstandard compression backends2020-06-13T15:08:12ZAlexander Færøyahf@torproject.orgAdd memory measurement code in LZMA and Zstandard compression backendsThe current LZMA and Zstandard compression backends lacks support for run-time measurements of their memory usage.The current LZMA and Zstandard compression backends lacks support for run-time measurements of their memory usage.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22065prop278: Parse the Accept-Encoding header and pass it to "get" handlers2020-06-13T15:08:12ZNick Mathewsonprop278: Parse the Accept-Encoding header and pass it to "get" handlersI need this for my prop140 work.I need this for my prop140 work.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22061prop140/prop278: use atomic counters to track memory usage2020-06-13T15:08:11ZNick Mathewsonprop140/prop278: use atomic counters to track memory usageI want to be able to compress things in subthreads, but that means that using plain old statics for our allocation counters won't work.I want to be able to compress things in subthreads, but that means that using plain old statics for our allocation counters won't work.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22052Synchronize prop224 spec with implementation2020-06-13T15:08:10ZGeorge KadianakisSynchronize prop224 spec with implementationIn our ed25519 key blinding code we have a few pieces that are not in the spec. At the very least we have the following constant strings that get hashed, which are not mentioned in the spec:
```
const char str[] = "Derive temporary sig...In our ed25519 key blinding code we have a few pieces that are not in the spec. At the very least we have the following constant strings that get hashed, which are not mentioned in the spec:
```
const char str[] = "Derive temporary signing key";
...
const char str[] = "Derive temporary signing key hash input";
```
We should eye the implementation for any other unspecified parts, and bake them in the spec.Tor: 0.3.1.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/22051Use streaming compression API in the non-streaming compression API2020-06-13T15:08:09ZAlexander Færøyahf@torproject.orgUse streaming compression API in the non-streaming compression APIWe currently have some code duplication in tor's compress/uncompress API and the streaming compression/decompression API.
It could make sense to check if the streaming API could be used to implement `tor_gzip_compress()` and `tor_gzip_u...We currently have some code duplication in tor's compress/uncompress API and the streaming compression/decompression API.
It could make sense to check if the streaming API could be used to implement `tor_gzip_compress()` and `tor_gzip_uncompress()` (and the new LZMA & Zstandard implementations when they land).Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22042HSFETCH not followed by HS_DESC_CONTENT event2020-06-13T15:08:08ZTracHSFETCH not followed by HS_DESC_CONTENT eventHi,
I'm trying to periodically get a hidden service descriptor to monitor changes. I tried using stem with the following python script:
```
from stem.control import Controller
import datetime
import time
ONION = 'expyuzz4wqqyqhjn'
w...Hi,
I'm trying to periodically get a hidden service descriptor to monitor changes. I tried using stem with the following python script:
```
from stem.control import Controller
import datetime
import time
ONION = 'expyuzz4wqqyqhjn'
with Controller.from_port(port = 9051) as controller:
controller.authenticate()
while True:
print(datetime.datetime.now())
desc = controller.get_hidden_service_descriptor(ONION)
time.sleep(60)
```
However, after about six iterations the get_hidden_service_descriptor blocks indefinitely (I waited up to 24 hours). I manually recreated what stem sends to the control port:
```
% nc 127.0.0.1 9051
AUTHENTICATE
250 OK
SETEVENTS HS_DESC_CONTENT HS_DESC
250 OK
HSFETCH expyuzz4wqqyqhjn
250 OK
650 HS_DESC REQUESTED expyuzz4wqqyqhjn NO_AUTH $D0B232E732DD69F181815EE6648E9AB8A67F73BA~ididntedittheconfig 2baufgsbt3a2jolhmvrsmd3ufdg72cyz
650 HS_DESC RECEIVED expyuzz4wqqyqhjn NO_AUTH $D0B232E732DD69F181815EE6648E9AB8A67F73BA~ididntedittheconfig 2baufgsbt3a2jolhmvrsmd3ufdg72cyz
650+HS_DESC_CONTENT expyuzz4wqqyqhjn 2baufgsbt3a2jolhmvrsmd3ufdg72cyz $D0B232E732DD69F181815EE6648E9AB8A67F73BA~ididntedittheconfig
<...>
650 OK
HSFETCH expyuzz4wqqyqhjn
250 OK
650 HS_DESC REQUESTED expyuzz4wqqyqhjn NO_AUTH $D05A37450AB9950181124563D3A7DBC5EE7D30BB~r3dn3ck 2baufgsbt3a2jolhmvrsmd3ufdg72cyz
650 HS_DESC RECEIVED expyuzz4wqqyqhjn NO_AUTH $D05A37450AB9950181124563D3A7DBC5EE7D30BB~r3dn3ck 2baufgsbt3a2jolhmvrsmd3ufdg72cyz
650+HS_DESC_CONTENT expyuzz4wqqyqhjn 2baufgsbt3a2jolhmvrsmd3ufdg72cyz $D05A37450AB9950181124563D3A7DBC5EE7D30BB~r3dn3ck
<...>
650 OK
HSFETCH expyuzz4wqqyqhjn
250 OK
650 HS_DESC REQUESTED expyuzz4wqqyqhjn NO_AUTH $707C1B61AC72227B34487B56D04BAA3BA1179CE8~BrassHornExit04 oalrv2mxdne6gfwikalgyl47sktjwxte
650 HS_DESC RECEIVED expyuzz4wqqyqhjn NO_AUTH $707C1B61AC72227B34487B56D04BAA3BA1179CE8~BrassHornExit04 nyuijvpn63lgfbupw5vqyfdhzbllyk7v
650+HS_DESC_CONTENT expyuzz4wqqyqhjn oalrv2mxdne6gfwikalgyl47sktjwxte $707C1B61AC72227B34487B56D04BAA3BA1179CE8~BrassHornExit04
<...>
650 OK
HSFETCH expyuzz4wqqyqhjn
250 OK
650 HS_DESC REQUESTED expyuzz4wqqyqhjn NO_AUTH $D06CD6EDAA93F4656E0C9F6347B26A2828D6CB25~Unnamed 2baufgsbt3a2jolhmvrsmd3ufdg72cyz
650 HS_DESC RECEIVED expyuzz4wqqyqhjn NO_AUTH $D06CD6EDAA93F4656E0C9F6347B26A2828D6CB25~Unnamed 2baufgsbt3a2jolhmvrsmd3ufdg72cyz
650+HS_DESC_CONTENT expyuzz4wqqyqhjn 2baufgsbt3a2jolhmvrsmd3ufdg72cyz $D06CD6EDAA93F4656E0C9F6347B26A2828D6CB25~Unnamed
<...>
650 OK
HSFETCH expyuzz4wqqyqhjn
250 OK
650 HS_DESC REQUESTED expyuzz4wqqyqhjn NO_AUTH $7056EA2E99144613694F0264C80579AAFEA6E1CD~ozora oalrv2mxdne6gfwikalgyl47sktjwxte
650 HS_DESC RECEIVED expyuzz4wqqyqhjn NO_AUTH $7056EA2E99144613694F0264C80579AAFEA6E1CD~ozora 2baufgsbt3a2jolhmvrsmd3ufdg72cyz
650+HS_DESC_CONTENT expyuzz4wqqyqhjn oalrv2mxdne6gfwikalgyl47sktjwxte $7056EA2E99144613694F0264C80579AAFEA6E1CD~ozora
<...>
650 OK
HSFETCH expyuzz4wqqyqhjn
250 OK
650 HS_DESC REQUESTED expyuzz4wqqyqhjn NO_AUTH $7044955A4D7B04CF70011D73B467B13CE5E69D41~L29Ah oalrv2mxdne6gfwikalgyl47sktjwxte
650 HS_DESC RECEIVED expyuzz4wqqyqhjn NO_AUTH $7044955A4D7B04CF70011D73B467B13CE5E69D41~L29Ah 2baufgsbt3a2jolhmvrsmd3ufdg72cyz
650+HS_DESC_CONTENT expyuzz4wqqyqhjn oalrv2mxdne6gfwikalgyl47sktjwxte $7044955A4D7B04CF70011D73B467B13CE5E69D41~L29Ah
<...>
650 OK
HSFETCH expyuzz4wqqyqhjn
250 OK
```
No HS_DESC or HS_DESC_CONTENT is received after the last HSFETCH (I waited about an hour). The control port spec (https://gitweb.torproject.org/torspec.git/tree/control-spec.txt) states that "On success, Tor replies "250 OK" then Tor MUST eventually follow this with both a HS_DESC and HS_DESC_CONTENT events with the results.".
I guess that stem blocks because it waits for the event. If I send another HSFETCH expyuzz4wqqyqhjn after a couple of minutes, the corresponding events are emitted just fine. Also I noticed that when the sleep in the above python script is increased to 10 minutes, get_hidden_service_descriptor continues to return a result quickly.
**Trac**:
**Username**: nicklerTor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22032[warn] Hidden service fn3xxgdv5skhtza2 launched 0 intro points in the last 31...2020-06-13T15:08:07ZRoger Dingledine[warn] Hidden service fn3xxgdv5skhtza2 launched 0 intro points in the last 3193 seconds (delayed). Intro circuit launches are limited to 8 per 300 seconds.Running Tor 0.3.1.0-alpha-dev (git-b081a7ed21ae729f), as a client with a random hidden service I configured and then forgot about.
(there isn't a trac version of Tor for 0.3.1.0-alpha-dev?)
My tor got bit by #21969 (and who knows, mayb...Running Tor 0.3.1.0-alpha-dev (git-b081a7ed21ae729f), as a client with a random hidden service I configured and then forgot about.
(there isn't a trac version of Tor for 0.3.1.0-alpha-dev?)
My tor got bit by #21969 (and who knows, maybe others):
```
Apr 20 21:12:20.069 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for some of our primary entry guards
Apr 20 21:12:20.069 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for some of our primary entry guards
Apr 20 21:12:20.799 [notice] We now have enough directory information to build circuits.
Apr 20 22:02:03.592 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Apr 20 22:02:03.592 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
```
and then when it came back, it told me:
```
Apr 20 22:02:04.208 [warn] Hidden service fn3xxgdv5skhtza2 launched 0 intro points in the last 3193 seconds (delayed). Intro circuit launches are limited to 8 per 300 seconds.
Apr 20 22:02:04.208 [warn] Service configured in "/tmp/hidden_service/":
Apr 20 22:02:04.208 [warn] Intro point 0 at InFlames: circuit is open
Apr 20 22:02:04.208 [warn] Intro point 1 at wulfspider2: circuit is open
Apr 20 22:02:04.208 [warn] Intro point 2 at rortor1: circuit is open
```
Last I checked, 0 was a lot less than 8. Why the warning?Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21980prop224: Implement time period functions2020-06-13T15:07:59ZDavid Gouletdgoulet@torproject.orgprop224: Implement time period functionsTime period functions that we need in order to know where to upload/download the descriptor.Time period functions that we need in order to know where to upload/download the descriptor.Tor: 0.3.1.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/21978hs: Decouple adding and validating a service2020-06-13T15:07:58ZDavid Gouletdgoulet@torproject.orghs: Decouple adding and validating a serviceOne commit that splits the `rend_add_service()` function into two functions. One actually adding the service to the global list and the second one to validate the service thus adding a new function: `rend_validate_service()`
We need thi...One commit that splits the `rend_add_service()` function into two functions. One actually adding the service to the global list and the second one to validate the service thus adding a new function: `rend_validate_service()`
We need this for prop224 code that will in two steps validate and then add the service when loading a service from configuration.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org