Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:12:11Zhttps://gitlab.torproject.org/legacy/trac/-/issues/23071test_hs_ntor.sh fails with recent pysha32020-06-13T15:12:11ZNick Mathewsontest_hs_ntor.sh fails with recent pysha3Right now the recommended sha3 in python is pysha3, which emulates the same sha3 API as is added in python 3.6. But hs_ntor_ref.py doesn't work there.Right now the recommended sha3 in python is pysha3, which emulates the same sha3 API as is added in python 3.6. But hs_ntor_ref.py doesn't work there.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22804Refactor circuit_send_next_onionskin() to be less horribly large2020-06-13T15:11:11ZNick MathewsonRefactor circuit_send_next_onionskin() to be less horribly largeThere are three big sections to the abovementioned function: "CREATE", "EXTEND", and "Done." They should be separate functions.
See branch `onionskin_refactor` in my public repository. Said branch is optimized for readability :)There are three big sections to the abovementioned function: "CREATE", "EXTEND", and "Done." They should be separate functions.
See branch `onionskin_refactor` in my public repository. Said branch is optimized for readability :)Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20966Parts of deployed shared random protocol are specified only in the proposal2020-06-13T15:04:22ZRoger DingledineParts of deployed shared random protocol are specified only in the proposalIn dir-spec.txt, commit c4ae4dd31 gave us lines like
```
+ Denotes a directory authority commit for the shared randomness
+ protocol, containing the commitment value and potentially also the
+ reveal value. See secti...In dir-spec.txt, commit c4ae4dd31 gave us lines like
```
+ Denotes a directory authority commit for the shared randomness
+ protocol, containing the commitment value and potentially also the
+ reveal value. See sections [COMMITREVEAL] and [VALIDATEVALUES] of
+ proposal 250 on how to generate and validate these values.
```
That's a great improvement over just leaving it implicit. But if we have a goal of having Tor specified in the spec files (is that true?), then we should migrate the key sections from the proposal file to either dir-spec or a new srv-spec file.Tor: 0.3.0.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/17624Extend NEWNYM to also clear rendezvous caches and rendezvous connections2020-06-13T14:51:08ZKarsten LoesingExtend NEWNYM to also clear rendezvous caches and rendezvous connectionsRob and I would like to measure hidden/onion/rendezvous service performance by running two local tor clients to host and repeatedly access a service, respectively. In order to make subsequent requests as independent as possible, we'd wa...Rob and I would like to measure hidden/onion/rendezvous service performance by running two local tor clients to host and repeatedly access a service, respectively. In order to make subsequent requests as independent as possible, we'd want to clear all rendezvous caches and forget about rendezvous connections before making the next request. [Roger suggests on #1944](https://trac.torproject.org/projects/tor/ticket/1944#comment:42) to add the necessary functionality to the NEWNYM control command.
Here's the current patch that we're using, which is loosely based on arma's bug1944 branch and rebased to master from a year or so ago (4c8b809). Of course, the downside of using this patch is that we can't just use a recent-enough tor but have to patch a tor and also maintain the patch. The patch is pretty simple:
```
diff --git a/src/or/main.c b/src/or/main.c
index 094120f..ad7fa0b 100644
--- a/src/or/main.c
+++ b/src/or/main.c
@@ -2102,9 +2102,13 @@ process_signal(uintptr_t sig)
control_event_signal(sig);
break;
case SIGUSR2:
- switch_logs_debug();
- log_debug(LD_GENERAL,"Caught USR2, going to loglevel debug. "
- "Send HUP to change back.");
+ /* Replace the USR2 functionality with bug1944-specific plans.
+ * Ugly hack, but it'll do. */
+ log_info(LD_GENERAL, "Clearing all rendezvous caches and "
+ "forgetting about rendezvous connections...");
+ rend_cache_purge();
+ rend_client_purge_last_hid_serv_requests();
+ circuit_mark_all_dirty_circs_as_unusable();
control_event_signal(sig);
break;
case SIGHUP:
```
If there are no major concerns against this idea, I'll prepare and test a branch that actually does things when receiving a NEWNYM command, not when receiving SIGUSR2.
Thanks for considering this!Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17354hidserv-stats file name not handled by our sandbox2020-06-13T14:50:27ZDavid Gouletdgoulet@torproject.orghidserv-stats file name not handled by our sandboxThis bug is self explainable:
```
Oct 15 13:30:56.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /chutney/net/nodes/000a/stats/hidserv-stats (on Tor 0.2.8.0-alpha-dev 9c39a11f866223f0)
```
Branch is co...This bug is self explainable:
```
Oct 15 13:30:56.000 [warn] sandbox_intern_string(): Bug: No interned sandbox parameter found for /chutney/net/nodes/000a/stats/hidserv-stats (on Tor 0.2.8.0-alpha-dev 9c39a11f866223f0)
```
Branch is coming up after opening the ticket.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17041Memory corruption in the HS client2020-06-13T14:49:00ZDavid Gouletdgoulet@torproject.orgMemory corruption in the HS clientThis is in git master and hasn't been released.
Here is how the bug is triggered. You download a descriptor of a valid HS. Then restart that HS (thus making the current descriptor obsolete) and retry right away to download the descripto...This is in git master and hasn't been released.
Here is how the bug is triggered. You download a descriptor of a valid HS. Then restart that HS (thus making the current descriptor obsolete) and retry right away to download the descriptor for that HS. The tor client stops with a segfault in `malloc()` (you sometime need couple of tries to trigger the issue).
Now I believe this is a memory corruption of some sort since during the git bisect, I was able to trigger bad free() and other segfaults with `tor_memcmp()` in some other non related functions with the same usecase. Bisect gave me this commit as the first bad commit:
```
commit ab9a0e340728abd96128da726f67b4ccca10ba52
Author: David Goulet <dgoulet@ev0ke.net>
Date: Thu Jun 18 16:09:18 2015 -0400
Add rend failure cache
[...]
```
That precise commit introduces a memory corruption somewhere somehow, I can't find it for now so I'm filling this ticket. Attached is a debug log (3.3M) of the issue being triggered. It's also quite easy to run tor in gdb and catch the issue.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16543Retire VoteOnHidServDirectoriesV2 ?2020-06-13T14:47:19ZRoger DingledineRetire VoteOnHidServDirectoriesV2 ?The VoteOnHidServDirectoriesV2 config option has been 1 for a long time. Nobody ever sets it to anything else. I don't think we'd ever want them to.
Should we just replace it with always-on?The VoteOnHidServDirectoriesV2 config option has been 1 for a long time. Nobody ever sets it to anything else. I don't think we'd ever want them to.
Should we just replace it with always-on?Tor: 0.2.7.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/16524Don't vote HSDir if we aren't voting Valid2020-06-13T14:47:14ZRoger DingledineDon't vote HSDir if we aren't voting ValidSimilar to #15963 and #8243, if we end up taking away the Valid flag from a relay, I would like us to take away the HSDir flag too.
(I think there may still be some bug where if you take away the Valid flag, you end up taking away the R...Similar to #15963 and #8243, if we end up taking away the Valid flag from a relay, I would like us to take away the HSDir flag too.
(I think there may still be some bug where if you take away the Valid flag, you end up taking away the Running flag soon after, accidentally. But I think that bug is different and orthogonal to this one.)
In particular, there are relays currently that are running malicious HSDirs, but I'd like the opportunity to still make use of them for other (less sensitive) positions.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16399Create rendcache.{c|h} for hidden service descriptor cache2020-06-13T14:47:01ZDavid Gouletdgoulet@torproject.orgCreate rendcache.{c|h} for hidden service descriptor cacheFor developers and reviewers mental sanity, it would be great to move the ABI/API of both service and client hidden service descriptor cache to its own set of files.
Furthermore, to resolve #16389, it would help a lot to do that so we c...For developers and reviewers mental sanity, it would be great to move the ABI/API of both service and client hidden service descriptor cache to its own set of files.
Furthermore, to resolve #16389, it would help a lot to do that so we can ease development, maintenance, review and have better documentation in one single file.
I propose `rendcache.{c|h}`.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16389Redesign the HS client descriptor cache2020-06-13T14:48:43ZDavid Gouletdgoulet@torproject.orgRedesign the HS client descriptor cache**We merged a patch here, but see arma's comment below.**
Bug #16381 vs #14219 demonstarted an important issue with the current design of the HS client descriptor cache.
In a nutshell, we can't rely on the timestamp to order descriptor...**We merged a patch here, but see arma's comment below.**
Bug #16381 vs #14219 demonstarted an important issue with the current design of the HS client descriptor cache.
In a nutshell, we can't rely on the timestamp to order descriptors because the timestamp is rounded down to the nearest hour thus any change in that time period will never be seen by the client (#16381). Furthermore, we can't rely on comparing the descriptor content because we have two replicas with the same content but have different descriptor ID (#14219).
One solution proposed by arma (and +1 by special) is to redesign the logic to be cleaner, and keep an intro point failure cache. It seems like every time we encounter this "we keep state about the previous hs desc by keeping a copy of it, and then seeing if the new one is different, get it?" logic, somebody finds it confusing. Maybe now is a good time for it to die? :)Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16381Bad timestamp check when storing an HS descriptor on the client2020-06-13T17:47:51ZDavid Gouletdgoulet@torproject.orgBad timestamp check when storing an HS descriptor on the clientFortunately, this bug "should" happen rarely in the real Tor network but still could lead to reachability issues for high traffic hidden service.
Let's assume that all introduction points (IP) of an hidden service need to be changed (in...Fortunately, this bug "should" happen rarely in the real Tor network but still could lead to reachability issues for high traffic hidden service.
Let's assume that all introduction points (IP) of an hidden service need to be changed (intro2 max count or expiring) in a single `RendPostPeriod` (default is 1 hour), we do the intro dance with our newly picked introduction points, close the old ones and upload the new descriptor. The usual.
Now, let's say we have a client that did connect to the service before in the same hour so the client has the descriptor in its cache. Then, the client tries to connect again, the IPs located in the cached descriptor are used and the client will eventually get a NACK from all of them since the service just cycled them all. This will eventually trigger a refetch of the descriptor since we have no more IP that we can use. So far so good.
Here is when it goes wrong, when receiving the new descriptor just published by the HS, we do a series of check in `rend_cache_store_v2_desc_as_client()` which all passes correctly in our case except this one:
```
e = (rend_cache_entry_t*) strmap_get_lc(rend_cache, key);
if (e && e->parsed->timestamp >= parsed->timestamp) {
log_info(LD_REND, "We already have a new enough service descriptor for "
"service ID %s with the same desc ID and version.",
safe_str_client(service_id));
goto okay;
}
```
The HS protocol speficies that the timestamp in the descriptor MUST be rounded down to the nearest hour. For instance, if it's 16h54, it will be set to 16h00. See `rend_service_update_descriptor()`:
```
d->timestamp = time(NULL);
d->timestamp -= d->timestamp % 3600; /* Round down to nearest hour */
```
The side effect of this is that if an HS uploads a new descriptor with a new set of IPs, they won't be usable until the next hour because the tor client doesn't keep the new descriptor even though the intro points did actually change. Thus this means that anything that changes in a time period of one hour will not be seen by the client if the descriptor was already cached before.
Keep in mind that a client reuses a rendez-vous circuit but stops after `MaxCircuitDirtiness` (default: 10 minutes) so after 10 minutes it will redo the introduction and rendezvous circuits.
(I was able to trigger this in a chutney network by setting a lifetime of 30 seconds for introduction point which creates a lot of rotation.)
I think the fix here should look like this (fun fact, it's what `rend_cache_store_v2_desc_as_dir()` does):
```
- if (e && e->parsed->timestamp >= parsed->timestamp) {
+ if (e && e->parsed->timestamp > parsed->timestamp) {
```Tor: 0.2.7.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16260HS can repick an expired intro points or one that we've already picked2020-06-13T14:46:43ZDavid 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/legacy/trac/-/issues/16052Hidden service socket exhaustion by opening many connections2020-06-13T14:46:13ZGeorge KadianakisHidden service socket exhaustion by opening many connectionsHello,
it seems that some HSes are getting DoSed by an attacker who establishes a few circuits and then sends thousands of `RELAY_BEGIN` cells through them. It's basically a variant of #15515, but fortunately this can be fixed by patchi...Hello,
it seems that some HSes are getting DoSed by an attacker who establishes a few circuits and then sends thousands of `RELAY_BEGIN` cells through them. It's basically a variant of #15515, but fortunately this can be fixed by patching the HS.
Here are some fixes ideas from Yawning:
a) Some variation on "implement a hard cap on the number of simultaneous streams that can be associated to a given circuit before we start rejecting RELAY_BEGINs". Will break apps if the hard cap is too low due to web browsers wanting to open tons of TCP/IP connections (limiting it to something like... 16/32/64 with it being tunable may be ok, consult Mike?)
b) Apply throttling to RELAY_BEGINs over a given circuit. Something like "allow up to N streams to complete immediately, then each subsequent stream will be delayed for x seconds, doubling for each additional RELAY_BEGIN, resetting after y seconds". Annoying since queuing is required (OOM hazard here?).
c) "If you want to be more resilient to this, use an AF_UNIX backed HS". This should shift the part that crumples to the app code, at which point it's kind of not our problem (the HS code might fall down for other reasons in this case, so I don't see this as being a real solution...)Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16023HS_DESC's UPLOADED action reports descriptor ids as UNKNOWN2020-06-13T14:46:07ZDamian JohnsonHS_DESC's UPLOADED action reports descriptor ids as UNKNOWNMoved from #15881. When running ADD_ONION it triggers UPLOAD events with the descriptor, followed by UPLOADED that lack it...
```
>>> SETEVENTS HS_DESC
250 OK
>>> controller.create_ephemeral_hidden_service(12456)
<stem.response.add_oni...Moved from #15881. When running ADD_ONION it triggers UPLOAD events with the descriptor, followed by UPLOADED that lack it...
```
>>> SETEVENTS HS_DESC
250 OK
>>> controller.create_ephemeral_hidden_service(12456)
<stem.response.add_onion.AddOnionResponse object at 0x8f0b0cc>
[ wait a bit ]
>>> /events
HS_DESC UPLOAD nxb77rbtdsvw7c3o UNKNOWN $0FA72BDDCDA850B92EF15CD94054AD8FEF4E766D~hammett b6gjiv5neliin4vl56opd4zfdcioxe2i
HS_DESC UPLOAD nxb77rbtdsvw7c3o UNKNOWN $0FAA299792826179730905EB8A33905AB52B48B1~anothermiddlefinger b6gjiv5neliin4vl56opd4zfdcioxe2i
HS_DESC UPLOAD nxb77rbtdsvw7c3o UNKNOWN $0FAB3FF0C765BE433EB99537FF8CA99495C675B2~DidntStartFlamewar b6gjiv5neliin4vl56opd4zfdcioxe2i
HS_DESC UPLOAD nxb77rbtdsvw7c3o UNKNOWN $3933C8E3C0C2DBC1860FA0C11A492F4E1028FF00~MyLittleTorRelay2 heztcsuk75jgl2zi7kydbbnnr2u74n5u
HS_DESC UPLOAD nxb77rbtdsvw7c3o UNKNOWN $39426CE7402CB62F04F5DFABA5CFBBAD08693900~pansomatik heztcsuk75jgl2zi7kydbbnnr2u74n5u
HS_DESC UPLOAD nxb77rbtdsvw7c3o UNKNOWN $394BEFDD8E78727802D3B4874170FB3D5D630E76~dotjhw heztcsuk75jgl2zi7kydbbnnr2u74n5u
HS_DESC UPLOADED UNKNOWN UNKNOWN $0FA72BDDCDA850B92EF15CD94054AD8FEF4E766D~hammett
HS_DESC UPLOADED UNKNOWN UNKNOWN $0FAA299792826179730905EB8A33905AB52B48B1~anothermiddlefinger
HS_DESC UPLOADED UNKNOWN UNKNOWN $0FAB3FF0C765BE433EB99537FF8CA99495C675B2~DidntStartFlamewar
HS_DESC UPLOADED UNKNOWN UNKNOWN $39426CE7402CB62F04F5DFABA5CFBBAD08693900~pansomatik
HS_DESC UPLOADED UNKNOWN UNKNOWN $3933C8E3C0C2DBC1860FA0C11A492F4E1028FF00~MyLittleTorRelay2
HS_DESC UPLOADED UNKNOWN UNKNOWN $394BEFDD8E78727802D3B4874170FB3D5D630E76~dotjhw
```
Yawning and I would like this so we can wait for descriptor publication when making ephemeral services. Doable right now since we can infer the descriptor id based on the UPLOAD events, but this is both a hack and can be error prone if there's multiple controllers.Tor: 0.2.8.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/16021Test: add unit test for rend_data_t create/free/dup/* functions.2020-06-13T14:46:06ZDavid Gouletdgoulet@torproject.orgTest: add unit test for rend_data_t create/free/dup/* functions.We've recently added `rend_data_service_create()` and `rend_data_client_create()` but without tests. Also, #15881 changed `rend_data_dup()` and `rend_data_free` a bit so we badly need unit testing for those to avoid future issue we might...We've recently added `rend_data_service_create()` and `rend_data_client_create()` but without tests. Also, #15881 changed `rend_data_dup()` and `rend_data_free` a bit so we badly need unit testing for those to avoid future issue we might have by adding stuff to `rend_data_t`Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15975HS_DESC's HSAddress can be 'UNKNOWN'2020-06-13T14:45:58ZDamian JohnsonHS_DESC's HSAddress can be 'UNKNOWN'```
09:39 < atagar> dgoulet, DonnchaC, nickm: In the recent spec commit (https://gitweb.torproject.org/torspec.git/commit/?id=ba30c1d) we're dropping the 'UNKNOWN' value from HSAddress. That was recently added for
HSFETC...```
09:39 < atagar> dgoulet, DonnchaC, nickm: In the recent spec commit (https://gitweb.torproject.org/torspec.git/commit/?id=ba30c1d) we're dropping the 'UNKNOWN' value from HSAddress. That was recently added for
HSFETCH (https://gitweb.torproject.org/torspec.git/commit/?id=aaf2434). Looks like a mistake.
09:40 < dgoulet> atagar: oh good catch there
09:41 < dgoulet> atagar: don't you have commit access to torspec upstream to fix it?
09:42 < atagar> Last I checked I didn't. nickm talked about granting me access but don't think that ever happened.
09:42 < dgoulet> :(
```
Will add a patch in a sec.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15963Don't vote HSDir if we aren't voting Fast2020-06-13T14:47:14ZRoger DingledineDon't vote HSDir if we aren't voting FastRight now when you spin up a new relay, it gets the HSDir flag before it gets measured. So for the sybil attackers that are aiming to mess with hidden service descriptors in some way, we have to notice them faster than we have to notice ...Right now when you spin up a new relay, it gets the HSDir flag before it gets measured. So for the sybil attackers that are aiming to mess with hidden service descriptors in some way, we have to notice them faster than we have to notice other sybils. This is no fun, and easy to fix with very few downsides.Tor: 0.2.7.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/15881Missing descriptor ID in some HS_DESC control event2020-06-13T14:45:44ZDavid Gouletdgoulet@torproject.orgMissing descriptor ID in some HS_DESC control eventThe control-spec does have it specified (see section 4.1.25) but Tor doesn't provide it for both RECEIVED and FAILED.The control-spec does have it specified (see section 4.1.25) but Tor doesn't provide it for both RECEIVED and FAILED.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15816HS Descriptor Fetch retry behavior is broken.2020-06-13T14:45:39ZYawning AngelHS Descriptor Fetch retry behavior is broken.#14847 broke the HS descriptor retry logic.
rendclient.c:lookup_last_hid_serv_request()
```
base32_encode(hsdir_id_base32, sizeof(hsdir_id_base32),
hs_dir->identity_digest, DIGEST_LEN);
tor_snprintf(hsdir_desc_comb_i...#14847 broke the HS descriptor retry logic.
rendclient.c:lookup_last_hid_serv_request()
```
base32_encode(hsdir_id_base32, sizeof(hsdir_id_base32),
hs_dir->identity_digest, DIGEST_LEN);
tor_snprintf(hsdir_desc_comb_id, sizeof(hsdir_desc_comb_id), "%s%s",
hsdir_id_base32,
desc_id_base32);
```
This used to be onion address based, but was changed to be the descriptor ID, which is ok.
rendclient.c:purge_hid_serv_from_last_hid_serv_requests()
```
if (tor_memeq(key + LAST_HID_SERV_REQUEST_KEY_LEN -
REND_SERVICE_ID_LEN_BASE32,
onion_address,
REND_SERVICE_ID_LEN_BASE32)) {
iter = strmap_iter_next_rmv(last_hid_serv_requests, iter);
tor_free(val);
} else {
```
This needs a corresponding change. The routine is called from `rend_client_desc_trynow()` if the fetch 404s to ensure that applications aren't stuck waiting for 15 mins if a fetch happens to fail.
Fixing this will also fix "HSFETCH" not always actually sending all the events back (particularly if the descriptor is missing, and a subsequent HSFETCH is issued).Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15801Relay with HSDir flag but no DirPort fail to respond to BEGIN_DIR2020-06-13T14:45:38ZDavid Gouletdgoulet@torproject.orgRelay with HSDir flag but no DirPort fail to respond to BEGIN_DIRBecause of #14202, directory authorities now can assign HSDir flag to a relay without a DirPort. However, relays don't accept BEGIN_DIR cells if `options->DirPort_set` is set to 0 (see `directory_permits_begindir_requests()`).
This is v...Because of #14202, directory authorities now can assign HSDir flag to a relay without a DirPort. However, relays don't accept BEGIN_DIR cells if `options->DirPort_set` is set to 0 (see `directory_permits_begindir_requests()`).
This is very problematic right now because as I'm opening this bug, we currently have 4348 HSDir in the consensus but 1497 of them (34%) of them don't have a DirPort thus not working.
Unless all relay updates with the patch, this situation will continue thus we should maybe bring back the need for a DirPort to get the HSDir flag on the autority sides?Tor: 0.2.8.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org