Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-10-11T23:40:04Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25193dos: Avoid blacklisting Exit relays2022-10-11T23:40:04ZDavid Gouletdgoulet@torproject.orgdos: Avoid blacklisting Exit relaysIt is possible to do "tor-in-tor" meaning a tor client connection can exit the network and come back at a Guard node.
And if this happens to be detected by the DoS subsystem, we'll blacklist the Exit relay for a while. That is *NOT* goo...It is possible to do "tor-in-tor" meaning a tor client connection can exit the network and come back at a Guard node.
And if this happens to be detected by the DoS subsystem, we'll blacklist the Exit relay for a while. That is *NOT* good.
Now that we have legacy/trac#25183, we can lookup the inbound address to learn if we know it. And if we do, don't consider it a potential malicious client that we need to look at.
That is one part of the solution, the second part is legacy/trac#2667 so we actually prevent reentry from Exit but that part won't be backported just yet (if ever).
This work will be part of legacy/trac#24902 so once merge_ready, it will be merged into my branch `ticket24902_029_05`.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25183Implement a way to tell if an IP address is a known relay2022-10-11T23:40:04ZDavid Gouletdgoulet@torproject.orgImplement a way to tell if an IP address is a known relayFor the DoS mitigation subsystem (legacy/trac#24902), we need a way to lookup the connection address and *quickly* know if it is a known relay or not. This is also needed for legacy/trac#2667 which would prevent Exit to reenter the netwo...For the DoS mitigation subsystem (legacy/trac#24902), we need a way to lookup the connection address and *quickly* know if it is a known relay or not. This is also needed for legacy/trac#2667 which would prevent Exit to reenter the network.
nickm has started a branch to have IP addresses with bloom filter: `address_set_029`.
Next step is to use that and bridge it with the nodelist so we can lookup an IP address and learn if it is known or not (not get the `node_t` back, that would require more work and probably lose in performance).Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25128Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circui...2022-10-11T23:40:04ZDavid Gouletdgoulet@torproject.orgBug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circuit_bucket_count >= stats->circuit_bucket failedI changed the `DoSCircuitCreationBurst` value in my torrc and this BUG() was triggered:
```
Feb 02 21:52:55.902 [warn] tor_bug_occurred_(): Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circuit_bucket_count >= s...I changed the `DoSCircuitCreationBurst` value in my torrc and this BUG() was triggered:
```
Feb 02 21:52:55.902 [warn] tor_bug_occurred_(): Bug: src/or/dos.c:312: cc_stats_refill_bucket: Non-fatal assertion new_circuit_bucket_count >= stats->circuit_bucket failed. (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
Feb 02 21:52:55.903 [warn] Bug: Non-fatal assertion new_circuit_bucket_count >= stats->circuit_bucket failed in cc_stats_refill_bucket at src/or/dos.c:312. Stack trace: (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
Feb 02 21:52:55.903 [warn] Bug: /root/git/tor/src/or/tor(log_backtrace+0x42) [0x557248c2bbd2] (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
Feb 02 21:52:55.903 [warn] Bug: /root/git/tor/src/or/tor(tor_bug_occurred_+0xb9) [0x557248c46f69] (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
Feb 02 21:52:55.903 [warn] Bug: /root/git/tor/src/or/tor(dos_cc_new_create_cell+0x263) [0x557248bf1e63] (on Tor 0.3.3.1-alpha-dev eafa252b26ecf83a)
```
This is because of:
```
/* This function is not allowed to make the bucket count smaller */
tor_assert_nonfatal(new_circuit_bucket_count >= stats->circuit_bucket);
```
We actually can make it smaller if the Burst or Rate is changed at runtime.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25122geoip: Hook the client geoip cache into the OOM handler2022-10-11T23:40:03ZDavid Gouletdgoulet@torproject.orggeoip: Hook the client geoip cache into the OOM handlerThe geoip cache can possibly grow quite a bit so it would be wise to make our OOM aware of it.The geoip cache can possibly grow quite a bit so it would be wise to make our OOM aware of it.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25095Update dir-spec.txt with recent consensus param additions2022-10-11T23:40:03ZRoger DingledineUpdate dir-spec.txt with recent consensus param additionsWe have a section in dir-spec.txt that tries to describe the possible consensus parameters, and their ranges, and their meanings.
We just added a bunch of new ones in legacy/trac#24902. And maybe we missed a few recently, like hs_servic...We have a section in dir-spec.txt that tries to describe the possible consensus parameters, and their ranges, and their meanings.
We just added a bunch of new ones in legacy/trac#24902. And maybe we missed a few recently, like hs_service_max_rdv_failures.
We should patch dir-spec.txt to specify all of them.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/2509424902 fix breaks on clang2022-10-11T23:40:03ZTaylor Yu24902 fix breaks on clanghttps://travis-ci.org/torproject/tor/jobs/335395212#L1716
```
src/or/dos.c:277:40: error: implicit conversion loses integer precision: 'long'
to 'uint32_t' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
num_token = elapsed_tim...https://travis-ci.org/torproject/tor/jobs/335395212#L1716
```
src/or/dos.c:277:40: error: implicit conversion loses integer precision: 'long'
to 'uint32_t' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
num_token = elapsed_time_last_refill * circuit_rate;
~ ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
```Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24902Denial of Service mitigation subsystem2022-10-11T23:40:03ZDavid Gouletdgoulet@torproject.orgDenial of Service mitigation subsystemThis ticket is for adding a denial of service mitigation subsystem to tor.
Because of the latest issues we've been having on the network with 1 million users most likely resulting in the huge loads on the relays we've been seeing, this ...This ticket is for adding a denial of service mitigation subsystem to tor.
Because of the latest issues we've been having on the network with 1 million users most likely resulting in the huge loads on the relays we've been seeing, this subsystem is to provide a framework in order to add defense to tor for potential (voluntary or not) denial of service.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24782Set a lower default MaxMemInQueues value2022-10-11T23:40:02ZteorSet a lower default MaxMemInQueues valueThe default MaxMemInQueues value of 0.75*RAM assumes:
* there is one tor instance per machine, and
* MaxMemInQueues covers most queue memory.
If we instead assumed:
* two tor instances, and
* MaxMemInQueues covers half of queue memorym
...The default MaxMemInQueues value of 0.75*RAM assumes:
* there is one tor instance per machine, and
* MaxMemInQueues covers most queue memory.
If we instead assumed:
* two tor instances, and
* MaxMemInQueues covers half of queue memorym
this would make Tor more resilient to attacks.
To do this, we should set MaxMemInQueues to 0.2*RAM, at least if we have a lot of RAM (like 4-8GB or more).Tor: 0.3.3.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24767All relays are constantly connecting to down relays and failing over and over2022-10-11T23:40:02ZRoger DingledineAll relays are constantly connecting to down relays and failing over and overStarlight at
https://lists.torproject.org/pipermail/tor-relays/2017-December/014001.html
points out that when a relay is receiving many extend cells to extend circuits to a relay that's down, it will try over and over to make a new conne...Starlight at
https://lists.torproject.org/pipermail/tor-relays/2017-December/014001.html
points out that when a relay is receiving many extend cells to extend circuits to a relay that's down, it will try over and over to make a new connection to that next relay:
```
650 ORCONN $5E2975B380F6E908AFB29E0D8D0B967AF73B41C2~WombleNode01 LAUNCHED ID=61580092
650 ORCONN $5E2975B380F6E908AFB29E0D8D0B967AF73B41C2~WombleNode01 FAILED REASON=CONNECTREFUSED NCIRCS=4 ID=61580092
650 ORCONN $5E2975B380F6E908AFB29E0D8D0B967AF73B41C2~WombleNode01 LAUNCHED ID=61580095
650 ORCONN $5E2975B380F6E908AFB29E0D8D0B967AF73B41C2~WombleNode01 FAILED REASON=CONNECTREFUSED NCIRCS=3 ID=61580095
650 ORCONN $5E2975B380F6E908AFB29E0D8D0B967AF73B41C2~WombleNode01 LAUNCHED ID=61580098
[...]
```
It seems to me that if just a moment ago you tried to connect to a relay and you failed for reason connectrefused, then maybe you already know what the answer is going to be for other circuits that show up in that second.
How long should we cache the answer for? And, are there any anonymity implications to this design change? (We already batch circuit extend requests as they're waiting for the connect request to finish or fail, so I think whatever the anonymity implications are, maybe we already have them?)Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25824Integrate circuit max_cell_queue_size killer with DoS heartbeats2022-10-11T23:39:49ZRoger DingledineIntegrate circuit max_cell_queue_size killer with DoS heartbeatsWe just merged legacy/trac#25226 so relays can kill circuits that queue up too many cells.
But we're nervous about picking a threshold that isn't super high, since there's no feedback about whether relays are hitting this event in the w...We just merged legacy/trac#25226 so relays can kill circuits that queue up too many cells.
But we're nervous about picking a threshold that isn't super high, since there's no feedback about whether relays are hitting this event in the wild: the logs are protocol-warn, so nobody, not us not them, will even know if it happens.
teor suggested that we could tie the circuit killing into the DoS heartbeat logs. Something like "and I killed x circuits that had too many cells queued".
This sounds to me like a great idea.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25248DoS mitgation: improve documentation2022-10-11T23:39:49ZcypherpunksDoS mitgation: improve documentation(some reason for opening this is: a relay operator seemed confused and started to modify the source instead of using these torrc settings)
https://lists.torproject.org/pipermail/tor-relays/2018-February/014503.html
building on top of le...(some reason for opening this is: a relay operator seemed confused and started to modify the source instead of using these torrc settings)
https://lists.torproject.org/pipermail/tor-relays/2018-February/014503.html
building on top of legacy/trac#25236
Lets add a high level overview of available DoS mitigations at the beginning of the section next to "The following options are useful only for a public relay. They control the Denial of Service mitigation subsystem."
as you did in the changelog already before going into the specific settings.
We could start by using a copy from your changelog:
https://gitweb.torproject.org/tor.git/tree/ChangeLog?h=tor-0.3.3.2-alpha#n8
something like:
"
Tor has 3 build-in mitigation options that can be individually enabled/disabled and fine-tuned, but by default Tor directory authorities will define reasonable values for relays and no explicit configuration is required to make use of these protections.
The mitigations are:
* First: if a single client address makes too many concurrent connections (~~>100~~ "too many" is configurable via XXX), hang up on further connections.
* Second: if a
single client IP address (v4 and v6 or does it just work with IPv4?) makes circuits too quickly (more than 3 per
second, with an allowed burst of 90) while also having too many
connections open (3), refuse new create cells for the next while
(1-2 hours).
* Third: if a client asks to establish a rendezvous
point to you directly, ignore the request. These defenses can be
manually controlled by new torrc options, but relays will also
take guidance from consensus parameters, so there's no need to
configure anything manually.
"
instead of the static values add the config options in brackets.
https://www.torproject.org/docs/tor-manual-dev.html.en#DoSCircuitCreationEnabled
Does not say what 0 and 1 means. Maybe use the same wording as you use for most other boolean settings:
"If this option is set to 1, ...
* The section "DENIAL OF SERVICE MITIGATION OPTIONS" refers to the consensus
for default values, lets tell the operator how to find the current consensus values so he has actually some information where they can say "that value is to low for me my system is idle" or "oh that is not defined in consensus" -> legacy/trac#25236
will these values show on https://consensus-health.torprojec.org?Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25236dos: Document torrc default values in the man page when not in the consensus2022-10-11T23:39:48ZDavid Gouletdgoulet@torproject.orgdos: Document torrc default values in the man page when not in the consensusFrom:
https://trac.torproject.org/projects/tor/ticket/24902#comment:68From:
https://trac.torproject.org/projects/tor/ticket/24902#comment:68Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25226Circuit cell queue can fill up memory2022-10-11T23:39:48ZDavid Gouletdgoulet@torproject.orgCircuit cell queue can fill up memoryA relay operator just reported this on 0.3.3.2-alpha:
https://lists.torproject.org/pipermail/tor-relays/2018-February/014496.html
In a nutshell, the OOM fired up with these logs:
```
Feb 12 18:54:55 tornode2 Tor[6362]: We're low on me...A relay operator just reported this on 0.3.3.2-alpha:
https://lists.torproject.org/pipermail/tor-relays/2018-February/014496.html
In a nutshell, the OOM fired up with these logs:
```
Feb 12 18:54:55 tornode2 Tor[6362]: We're low on memory (cell queues total alloc: 1602579792 buffer total alloc: 1388544, tor compress total alloc: 1586784 rendezvous cache total alloc: 489909). Killing circuits withover-long queues. (This behavior is controlled by MaxMemInQueues.)
Feb 12 18:54:56 tornode2 Tor[6362]: Removed 1599323088 bytes by killing 1 circuits; 39546 circuits remain alive. Also killed 0 non-linked directory connections.
```
Notice the ~1GB of cells for one single circuit? Somehow, there is an issue in tor that makes it possible to fill up the circuit cell queue while the scheduler is just not emptying that queue.
This really looks like the Sniper Attack: http://www.robgjansen.com/publications/sniper-ndss2014.pdfTor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25223dos: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed2022-10-11T23:39:48ZDavid Gouletdgoulet@torproject.orgdos: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failedI just got this report from a relay operator who got this on tor-0.3.3.2-alpha but that relay is an obfs4 bridge! DoS mitigation is not suppose to be running on bridges for now...
```
Feb 12 18:14:55.000 [notice] Tor 0.3.3.2-alpha (git-...I just got this report from a relay operator who got this on tor-0.3.3.2-alpha but that relay is an obfs4 bridge! DoS mitigation is not suppose to be running on bridges for now...
```
Feb 12 18:14:55.000 [notice] Tor 0.3.3.2-alpha (git-7b1d356bdb76607d) opening log file.
Feb 12 18:47:09.000 [warn] tor_bug_occurred_(): Bug: ../src/or/dos.c:679: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: Non-fatal assertion !(entry == NULL) failed in dos_new_client_conn at ../src/or/dos.c:679. Stack trace: (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x44) [0x55e0314a7de4] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x55e0314c3479] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(channel_do_open_actions+0x1de) [0x55e0313e933e] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(channel_change_state_open+0x2a) [0x55e0313e93ba] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_state_change_on_orconn+0x102) [0x55e0313ee2f2] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(connection_or_set_state_open+0x22) [0x55e031437872] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x185) [0x55e0313ee535] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(+0x115a01) [0x55e031434a01] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(+0x10c52e) [0x55e03142b52e] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(+0x537ae) [0x55e0313727ae] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7f6f4e6c55a0] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x2bc) [0x55e03137381c] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x275) [0x55e031374f25] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x55e03136e36a] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x55e03136e0d9] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f6f4cc9f2b1] (on Tor 0.3.3.2-alpha )
Feb 12 18:47:09.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x55e03136e12a] (on Tor 0.3.3.2-alpha )
Feb 12 18:59:37.000 [warn] Onion service connection to [scrubbed] failed (connection refused)
```Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25202Check the calculations in cc_stats_refill_bucket using non fatal assertions2022-10-11T23:39:48ZteorCheck the calculations in cc_stats_refill_bucket using non fatal assertionsIn legacy/trac#25128, we removed an incorrect non-fatal assertion in cc_stats_refill_bucket() to silence a warning:
```
/* This function is not allowed to make the bucket count smaller */
tor_assert_nonfatal(new_circuit_bucket_count ...In legacy/trac#25128, we removed an incorrect non-fatal assertion in cc_stats_refill_bucket() to silence a warning:
```
/* This function is not allowed to make the bucket count smaller */
tor_assert_nonfatal(new_circuit_bucket_count >= stats->circuit_bucket);
```
But we could have fixed the check instead, and added another check:
```
/* This function is not allowed to make the bucket count larger than the burst value */
tor_assert_nonfatal(new_circuit_bucket_count <= dos_cc_circuit_burst);
/* This function is not allowed to make the bucket count smaller, unless it is
* decreasing it to a newly configured, lower burst value. We allow the bucket to
* stay the same size, in case the circuit rate is zero. */
tor_assert_nonfatal(new_circuit_bucket_count >= stats->circuit_bucket ||
new_circuit_bucket_count == dos_cc_circuit_burst);
```
We could be even more clever, and skip parts of the function if the rate is zero. That's probably unnecessary. I'll think about it.
I should get a chance to turn this into a proper branch over the next week or so. If someone else wants to do it before then, go for it!Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/12062Audit DisableNetwork, we_are_hibernating usage2022-05-07T06:54:09ZNick MathewsonAudit DisableNetwork, we_are_hibernating usageI think a lot of our DisableNetwork checks should instead check net_is_disabled, since so much of what we're doing turning off when the network is disabled is also something we're trying to turn off when we're hibernating.
And probably ...I think a lot of our DisableNetwork checks should instead check net_is_disabled, since so much of what we're doing turning off when the network is disabled is also something we're trying to turn off when we're hibernating.
And probably some of our DisableNetwork checks should call should_delay_dir_fetches or something similar, if they're related to fetching non-bridge-descriptor directory stuff.
Possibly there should be a better designed hierarchy here.
Possibly, most of the fixes here should wait for 0.2.6, since this code is tricky.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28973Disable TLS1.3 when openssl bug 7712 is present2022-03-07T00:00:01ZNick MathewsonDisable TLS1.3 when openssl bug 7712 is presentSee legacy/trac#28616 for the impact of the bug in tor; see https://github.com/openssl/openssl/issues/7712 for the openssl issue.See legacy/trac#28616 for the impact of the bug in tor; see https://github.com/openssl/openssl/issues/7712 for the openssl issue.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25108hs: nodelist_recompute_all_hsdir_indices() is not used2021-09-30T13:50:08ZDavid Gouletdgoulet@torproject.orghs: nodelist_recompute_all_hsdir_indices() is not usedDead code that we should remove.Dead code that we should remove.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24972Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal assert...2021-09-30T13:50:08ZGeorge KadianakisBug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed.My HSv3 is unable to encode its own descriptor with the following fail:
```
Jan 21 08:00:49.000 [info] connection_free_minimal(): Freeing linked Socks connection [open] with 0 bytes on inbuf, 0 on outbuf.
Jan 21 08:00:49.000 [info] handl...My HSv3 is unable to encode its own descriptor with the following fail:
```
Jan 21 08:00:49.000 [info] connection_free_minimal(): Freeing linked Socks connection [open] with 0 bytes on inbuf, 0 on outbuf.
Jan 21 08:00:49.000 [info] handle_response_upload_hsdesc(): Uploaded hidden service descriptor (status 200 ("HS descriptor stored successfully."))
Jan 21 08:00:49.000 [info] handle_response_upload_hsdesc(): Uploading hidden service descriptor: finished with status 200 ("HS descriptor stored successfully.")
Jan 21 08:00:49.000 [info] connection_free_minimal(): Freeing linked Directory connection [client finished] with 0 bytes on inbuf, 0 on outbuf.
Jan 21 08:00:49.000 [info] circuit_finish_handshake(): Finished building circuit hop:
Jan 21 08:00:49.000 [info] internal (high-uptime) circ (length 4, last hop damita): $E2920D7419B7601CF82D43400D042DA70E0675B2(open) $CA58EB617C6CA2F351AEFD56C84B8A7AF7704B22(open) $0E3D3FCE26F6969B7AE80E4CA6C4CFA97988F31E(open) $A9F7185499C5784E35B5C25744ED4AB75437CE5D(open)
Jan 21 08:00:49.000 [info] entry_guards_note_guard_success(): Recorded success for primary confirmed guard papadouka ($E2920D7419B7601CF82D43400D042DA70E0675B2)
Jan 21 08:00:49.000 [info] circuit_build_no_more_hops(): circuit built!
Jan 21 08:00:49.000 [info] pathbias_count_build_success(): Got success count 224.332749/291.637758 for guard papadouka ($E2920D7419B7601CF82D43400D042DA70E0675B2)
Jan 21 08:01:06.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after 5296 ms. Delta -4ms
Jan 21 08:01:12.000 [info] routerlist_remove_old_routers(): We have 0 live routers and 0 old router descriptors.
Jan 21 08:01:19.000 [info] or_state_save(): Saved state to "/home/f/.tor/state"
Jan 21 08:01:25.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after 5996 ms. Delta 2ms
Jan 21 08:01:32.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after 6840 ms. Delta -2ms
Jan 21 08:01:43.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after 2096 ms. Delta 0ms
Jan 21 08:01:51.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after 7912 ms. Delta 0ms
Jan 21 08:01:57.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after 6456 ms. Delta 0ms
Jan 21 08:02:05.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after 7952 ms. Delta 3ms
Jan 21 08:02:07.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after 2280 ms. Delta 1ms
Jan 21 08:02:12.000 [info] routerlist_remove_old_routers(): We have 0 live routers and 0 old router descriptors.
Jan 21 08:02:20.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after 3756 ms. Delta 2ms
Jan 21 08:02:33.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after 8344 ms. Delta 0ms
Jan 21 08:03:00.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 58 to 86.106.137.6:443 (E2920D7419B7601CF82D43400D042DA70E0675B2) after 4508 ms. Delta 2ms
Jan 21 08:03:04.000 [info] run_upload_descriptor_event(): Initiating upload for hidden service current descriptor for service j2eiu2izwjpazjevu4xs3muaif3jzex3nnvnu677vz2fypmzccvhhiid with 3/3 introduction points.
Jan 21 08:03:04.000 [info] close_directory_connections(): Closed 0 active service directory connections for descriptor 9btQxrMpxWDJwnf1TU6U+5vcPmPdD2OPBVAKKmRLr7I of service j2eiu2izwjpazjevu4xs3muaif3jzex3nnvnu677vz2fypmzccvhhiid
Jan 21 08:03:04.000 [info] crypto_strongest_rand_fallback(): Reading entropy from "/dev/urandom"
Jan 21 08:03:04.000 [info] crypto_strongest_rand_fallback(): Reading entropy from "/dev/urandom"
Jan 21 08:03:04.000 [warn] Invalid signature for service descriptor signing key.
Jan 21 08:03:04.000 [warn] tor_bug_occurred_(): Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed. (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: Non-fatal assertion !(ret < 0) failed in hs_desc_encode_descriptor at src/or/hs_descriptor.c:2357. Stack trace: (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(log_backtrace+0x42) [0x7ffa9cd66ac2] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(tor_bug_occurred_+0xb7) [0x7ffa9cd81cd7] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(hs_desc_encode_descriptor+0xb2) [0x7ffa9cd4d782] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(hs_service_run_scheduled_events+0x21f3) [0x7ffa9cd570d3] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(+0x4ca31) [0x7ffa9cc30a31] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(+0x6cdc0) [0x7ffa9cc50dc0] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7ffa9c2673dc] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(do_main_loop+0x25c) [0x7ffa9cc34c9c] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(tor_run_main+0x265) [0x7ffa9cc360b5] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(tor_main+0x3a) [0x7ffa9cc2f71a] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(main+0x19) [0x7ffa9cc2f489] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7ffa9b45a2b1] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(_start+0x2a) [0x7ffa9cc2f4da] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] tor_bug_occurred_(): Bug: src/or/hs_service.c:2245: upload_descriptor_to_hsdir: Non-fatal assertion !(hs_desc_encode_descriptor(desc->desc, &desc->signing_kp, &encoded_desc) < 0) failed. (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: Non-fatal assertion !(hs_desc_encode_descriptor(desc->desc, &desc->signing_kp, &encoded_desc) < 0) failed in upload_descriptor_to_hsdir at src/or/hs_service.c:2245. Stack trace: (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(log_backtrace+0x42) [0x7ffa9cd66ac2] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(tor_bug_occurred_+0xb7) [0x7ffa9cd81cd7] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(hs_service_run_scheduled_events+0x23e7) [0x7ffa9cd572c7] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(+0x4ca31) [0x7ffa9cc30a31] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(+0x6cdc0) [0x7ffa9cc50dc0] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7ffa9c2673dc] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(do_main_loop+0x25c) [0x7ffa9cc34c9c] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(tor_run_main+0x265) [0x7ffa9cc360b5] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(tor_main+0x3a) [0x7ffa9cc2f71a] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(main+0x19) [0x7ffa9cc2f489] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7ffa9b45a2b1] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
Jan 21 08:03:04.000 [warn] Bug: ./tor/src/or/tor(_start+0x2a) [0x7ffa9cc2f4da] (on Tor 0.3.3.0-alpha-dev d69c8f7117a5975a)
```
That started happening 4 days after I started up Tor and it persists up to today: my HS is still unable to create its own desc...
FWIW, the only difference from the past is that I've been using vanguards but that should not influence the signing of the desc....Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25661RendPostPeriod and HiddenServiceAuthorizeClient are v2 only2021-09-30T13:46:29ZteorRendPostPeriod and HiddenServiceAuthorizeClient are v2 onlyRendPostPeriod and HiddenServiceAuthorizeClient only apply to v2 onion services. We should update the man page so this is clearer.RendPostPeriod and HiddenServiceAuthorizeClient only apply to v2 onion services. We should update the man page so this is clearer.Tor: 0.3.3.x-final