The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-03-07T23:49:55Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33018Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix2022-03-07T23:49:55ZRoger DingledineDir auths using an unsustainable 400+ mbit/s, need to diagnose and fixWe've been having problems establishing a consensus lately. We realized that maatuska was rate limiting to only 10MBytes/s, and asked Linus to bump it up, so he did.
Then today we realized that moria1 was unable to serve dirport answers...We've been having problems establishing a consensus lately. We realized that maatuska was rate limiting to only 10MBytes/s, and asked Linus to bump it up, so he did.
Then today we realized that moria1 was unable to serve dirport answers because it was maxed out at its BandwidthRate of 30MBytes. I raised that to 50MBytes and it stayed maxed out. I have put it back down to 30MBytes so my host doesn't get too upset.
This is not a sustainable situation. We need to figure out what is asking the dir auths for so many bytes, and get it to stop or slow down.
This is a ticket to collect info and to brainstorm ideas.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33019Allow dynamically and statically linked PTs to be loaded into a Tor binary2022-06-16T18:05:36ZAlexander Færøyahf@torproject.orgAllow dynamically and statically linked PTs to be loaded into a Tor binaryCurrently PTs are always executed as subprocesses of Tor. This have its downsides on certain platforms such as iOS where we cannot have actual subprocesses and people have to do various hacks for them to work well on the platform.
It wo...Currently PTs are always executed as subprocesses of Tor. This have its downsides on certain platforms such as iOS where we cannot have actual subprocesses and people have to do various hacks for them to work well on the platform.
It would be useful if we had a mechanism for loading PTs as plug-ins of the Tor process (via .so's and .dll's), but also to allow developers to statically link in the PT into the Tor binary to save space.https://gitlab.torproject.org/tpo/core/tor/-/issues/33024can not connect to TOR please help2020-07-29T14:23:18ZTraccan not connect to TOR please helpEvery time I open TorBrowser on my system running Win 10, it says "Tor unexpectedly exited. This might be due to a bug in Tor itself, another program on your system, or faulty hardware. Until you restart Tor, the Tor Browser will not be ...Every time I open TorBrowser on my system running Win 10, it says "Tor unexpectedly exited. This might be due to a bug in Tor itself, another program on your system, or faulty hardware. Until you restart Tor, the Tor Browser will not be able to reach any websites. If the problem persists, please send a copy of your Tor Log to the support team."
When I try to restart it, shows the same result. I tried to delete the TorBrowser and reinstall and nothing. I can't copy a log to the clipboard because there are no logs therefore nothing to send to support team.
i have tried everything turning off my firewall adding tor to firewall accepted apps ect ect. not sure if my ISP is blocking it or what. please help me. thanks
**Trac**:
**Username**: brottousn@gmail.comhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33029dir-auth: Dir auths should resume sending 503's but never to relays or other ...2020-06-27T13:48:27ZDavid Gouletdgoulet@torproject.orgdir-auth: Dir auths should resume sending 503's but never to relays or other dir authsThis is a child ticket from legacy/trac#33018.
The idea here is that even if we hit the global write limit (bw), we should not return 503 code but rather answer another directory authority.
Dirauth _must_ be able to talk to each other ...This is a child ticket from legacy/trac#33018.
The idea here is that even if we hit the global write limit (bw), we should not return 503 code but rather answer another directory authority.
Dirauth _must_ be able to talk to each other at all time regardless of the bandwidth state.
Setting 043 milestone because this should be considered a bug and could even be considered for backport since dirauth are suffering from this at the moment.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33032Decode key files with Unix or Windows newlines2020-07-09T15:03:04ZTracDecode key files with Unix or Windows newlinesUpdate:
> In my case culprit was the line endings in PEM, lines were terminated Windows-style - {CR}{LF}. Changed them to {LF} and keys were read just fine.
After the upgrade to v 0.3.5.8 my onion wasn't available anymore.
This is t...Update:
> In my case culprit was the line endings in PEM, lines were terminated Windows-style - {CR}{LF}. Changed them to {LF} and keys were read just fine.
After the upgrade to v 0.3.5.8 my onion wasn't available anymore.
This is the info I get when attempting to start tor:
Jan 23 00:29:34.000 [warn] Error decoding PEM wrapper while reading private key
Jan 23 00:29:34.000 [warn] Unable to decode private key from file "/var/lib/tor/hidden_service//private_key"
Jan 23 00:29:34.000 [err] Error loading private key.
Jan 23 00:29:34.000 [warn] Error loading rendezvous service keys
Jan 23 00:29:34.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.3.5.8 )
Jan 23 00:29:34.000 [err] Reading config failed--see warnings above.
More users are having the same issue, that their Scallion generated keys cannot be read by the most recent version of TOR.
Any ideas?
**Trac**:
**Username**: larshilseTor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33039Memory leaks in handle_control_getconf2020-06-27T13:48:27ZNick MathewsonMemory leaks in handle_control_getconfFound while investigating legacy/trac#33006:
```
=================================================================
==180005==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x...Found while investigating legacy/trac#33006:
```
=================================================================
==180005==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fb54c5cdc58 in __interceptor_malloc (/lib64/libasan.so.5+0x10dc58)
#1 0x55a4af274f3a in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55a4af274fd0 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x55a4af2371ca in config_line_append src/lib/encoding/confline.c:40
#4 0x55a4aeffaec7 in control_reply_add_one_kv src/feature/control/control_proto.c:345
#5 0x55a4aefdd2ae in handle_control_getconf src/feature/control/control_cmd.c:307
#6 0x55a4aefe54b2 in handle_single_control_command src/feature/control/control_cmd.c:2376
#7 0x55a4aefe54b2 in handle_control_command src/feature/control/control_cmd.c:2407
#8 0x55a4aefd6e01 in connection_control_process_inbuf src/feature/control/control.c:508
#9 0x55a4aeee0e01 in connection_handle_read_impl src/core/mainloop/connection.c:3737
#10 0x55a4aeee0e01 in connection_handle_read src/core/mainloop/connection.c:3777
#11 0x55a4aeeecf00 in conn_read_callback src/core/mainloop/mainloop.c:892
#12 0x7fb54c32abb6 (/lib64/libevent-2.1.so.6+0x25bb6)
Indirect leak of 26 byte(s) in 1 object(s) allocated from:
#0 0x7fb54c55652d in strdup (/lib64/libasan.so.5+0x9652d)
#1 0x55a4af2751d0 in tor_strdup_ src/lib/malloc/malloc.c:165
#2 0x55a4af2371d5 in config_line_append src/lib/encoding/confline.c:41
#3 0x55a4aeffaec7 in control_reply_add_one_kv src/feature/control/control_proto.c:345
#4 0x55a4aefdd2ae in handle_control_getconf src/feature/control/control_cmd.c:307
#5 0x55a4aefe54b2 in handle_single_control_command src/feature/control/control_cmd.c:2376
#6 0x55a4aefe54b2 in handle_control_command src/feature/control/control_cmd.c:2407
#7 0x55a4aefd6e01 in connection_control_process_inbuf src/feature/control/control.c:508
#8 0x55a4aeee0e01 in connection_handle_read_impl src/core/mainloop/connection.c:3737
#9 0x55a4aeee0e01 in connection_handle_read src/core/mainloop/connection.c:3777
#10 0x55a4aeeecf00 in conn_read_callback src/core/mainloop/mainloop.c:892
#11 0x7fb54c32abb6 (/lib64/libevent-2.1.so.6+0x25bb6)
Indirect leak of 7 byte(s) in 1 object(s) allocated from:
#0 0x7fb54c55652d in strdup (/lib64/libasan.so.5+0x9652d)
#1 0x55a4af2751d0 in tor_strdup_ src/lib/malloc/malloc.c:165
#2 0x55a4af2371f5 in config_line_append src/lib/encoding/confline.c:42
#3 0x55a4aeffaec7 in control_reply_add_one_kv src/feature/control/control_proto.c:345
#4 0x55a4aefdd2ae in handle_control_getconf src/feature/control/control_cmd.c:307
#5 0x55a4aefe54b2 in handle_single_control_command src/feature/control/control_cmd.c:2376
#6 0x55a4aefe54b2 in handle_control_command src/feature/control/control_cmd.c:2407
#7 0x55a4aefd6e01 in connection_control_process_inbuf src/feature/control/control.c:508
#8 0x55a4aeee0e01 in connection_handle_read_impl src/core/mainloop/connection.c:3737
#9 0x55a4aeee0e01 in connection_handle_read src/core/mainloop/connection.c:3777
#10 0x55a4aeeecf00 in conn_read_callback src/core/mainloop/mainloop.c:892
#11 0x7fb54c32abb6 (/lib64/libevent-2.1.so.6+0x25bb6)
SUMMARY: AddressSanitizer: 65 byte(s) leaked in 3 allocation(s).
Exit code was 1
success (15.21s)
```Tor: 0.4.3.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33051O1.4 - Measure the number of Tor relays that support IPv6 reachability checks2020-08-14T12:34:03ZGabagaba@torproject.orgO1.4 - Measure the number of Tor relays that support IPv6 reachability checksSee Proposal 313: Relay IPv6 Statistics:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt
Tor's IPv6 reachability checks are described in:
Proposal 311: Tor Relay IPv6 Reachability:
https://gitweb.torpro...See Proposal 313: Relay IPv6 Statistics:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt
Tor's IPv6 reachability checks are described in:
Proposal 311: Tor Relay IPv6 Reachability:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt
The child tickets are in proposal section order, but they will probably be implemented in this order:
Dependencies:
* Prop 311: 5. Declare Support for Subprotocol Version "Relay=3" (O1.1, legacy/trac#33226)
Implementation:
* Write a Script that Counts IPv6 Relays in the Consensus
Metrics Review:
* Check IPv6 Relay Consensus Counts Script
Internal Testing:
* Test IPv6 Relay Consensus Counts using Chutney (O1.3, legacy/trac#33267)
Public Tor Network Testing:
* Test IPv6 Relay Consensus Counts on the Tor Network
Monitoring:
* Monitor IPv6 Relay Counts in the Consensus
Children:
* [x] tor#33262 Prop 313: 3. Write a Script that Counts IPv6 Relays in the Consensus
* [x] trac#33266 [Prop 313: 7.2. Show IPv6 Relay Counts on Consensus Health ](https://gitlab.torproject.org/tpo/metrics/consensus-health/-/issues/33266)
* [x] tor#33268 Prop 313: 8.1. Test IPv6 Relay Consensus Counts on the Tor Network
* [x] trac#33269 [Prop 313: 8.1. Check IPv6 Relay Consensus Counts Script](https://gitlab.torproject.org/tpo/metrics/analysis/-/issues/33269)
* [x] tor#33270 Prop 313: 8.1. Monitor IPv6 Relay Counts in the ConsensusSponsor 55: Improving the Tor network’s IPv6 supporthttps://gitlab.torproject.org/tpo/core/tor/-/issues/33052O1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 ...2020-08-14T12:38:04ZGabagaba@torproject.orgO1.5 - Measure the number of connections, and consumed bandwidth, using IPv4 and IPv6See Proposal 313: Relay IPv6 Statistics:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt
The child tickets are in proposal section order, but they will probably be implemented in this order:
Pre-Implem...See Proposal 313: Relay IPv6 Statistics:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt
The child tickets are in proposal section order, but they will probably be implemented in this order:
Pre-Implementation Bugs:
* Fix: Tor relays ignore some local bytes in their statistics
* Diagnose: ConnDirectionStatistics is off by default, but most relays report it
Dependencies:
* (None)
Implementation:
* Collect IPv6 Bandwidth Stats on Relays and Bridges
* Collect IPv6 Connection Stats on Relays
* Update Directory Spec for IPv6 Stats
Internal Testing:
* Test IPv6 Statistics using Chutney (O1.3, legacy/trac#33271)
Public Tor Network Testing:
* Test IPv6 Stats on the Tor Network
Metrics Analysis:
* Analyse and Monitor IPv6 Stats
Children:
* [x] tor#33159 Write a proposal for monitoring IPv6
* [x] tor#33263 Prop 313: 4. Collect IPv6 Bandwidth Stats on Relays and Bridges
* [x] tor#33264 Prop 313: 5. Collect IPv6 Connection Stats on Relays
* [x] tor#33201 Tor relays ignore some local bytes in their statistics
* [x] tor#33265 Prop 313: 6. Update Directory Spec for IPv6 Stats
* [ ] tor#33617 Add a BandwidthStatistics option and consensus parameter
* [x] tor#33272 Prop 313: 8.2. Test IPv6 Stats on the Tor Network
* [ ] #33273 [Prop 313: 8.2. Analyse and Monitor IPv6 Stats ](https://gitlab.torproject.org/tpo/metrics/analysis/-/issues/33273)
* [x] tor#33214 ConnDirectionStatistics is off by default, but most relays report itSponsor 55: Improving the Tor network’s IPv6 supporthttps://gitlab.torproject.org/tpo/core/tor/-/issues/33056Tor relays fail to understand /etc/resolv.conf ipv6 lines with % in them2020-06-27T13:48:26ZRoger DingledineTor relays fail to understand /etc/resolv.conf ipv6 lines with % in themWe had a relay operator on irc just now who has this line in their /etc/resolv.conf:
```
nameserver fe80::7e2ebdff:fe99:4cb9%enp2s0
```
Apparently this is a totally normal thing: the % indicates a link local name server.
Two more hints...We had a relay operator on irc just now who has this line in their /etc/resolv.conf:
```
nameserver fe80::7e2ebdff:fe99:4cb9%enp2s0
```
Apparently this is a totally normal thing: the % indicates a link local name server.
Two more hints that % is a standard thing:
* https://bugs.launchpad.net/ubuntu/+source/wide-dhcpv6/+bug/1620221 "The link local name servers should be suffixed with the scope, e.g. "%eth0"."
* https://tools.ietf.org/html/rfc4007#section-11 "to specify an IPv6 non-global address without ambiguity, an intended scope zone should be specified as well."
Tor is unable to handle this % syntax in a resolv.conf line:
```
Jan 25 17:03:00.171 [warn] eventdns: Unable to parse nameserver address fe80::7e2ebdff:fe99:4cb9%enp2s0
```
It's not as bad as it could be, because Tor skips that line and uses whatever other lines there are. But (a) maybe we're not doing as well as we can do, and (b) maybe there are situations where that's the only configured nameserver and everything works on the host except Tor doesn't.
I think technically this might be a libevent bug (aka missing feature), since it's libevent's evdns_base_nameserver_ip_add() which calls evutil_parse_sockaddr_port() which helpfully explains that
```
/* recognized formats are:
* [ipv6]:port
* ipv6
* [ipv6]
* ipv4:port
* ipv4
*/
```
none of which are the % syntax. But I will file it here as a Tor ticket, since it's a Tor bug too, and then we can figure out where best to fix it.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33069Init sk if loaded from service blob to be on the curve2020-06-27T13:48:26ZTracInit sk if loaded from service blob to be on the curvediff --git a/src/feature/hs/hs_service.c b/src/feature/hs/hs_service.c
index 81b37eab4..300fedc4f 100644
--- a/src/feature/hs/hs_service.c
+++ b/src/feature/hs/hs_service.c
@@ -3548,6 +3548,12 @@ hs_service_add_ephemeral(ed25519_secret_k...diff --git a/src/feature/hs/hs_service.c b/src/feature/hs/hs_service.c
index 81b37eab4..300fedc4f 100644
--- a/src/feature/hs/hs_service.c
+++ b/src/feature/hs/hs_service.c
@@ -3548,6 +3548,12 @@ hs_service_add_ephemeral(ed25519_secret_key_t *sk, smartlist_t *ports,
/* Handle the keys. */
memcpy(&service->keys.identity_sk, sk, sizeof(service->keys.identity_sk));
+
+ /* QAD make sure the scalar is on the curve since ed25519_donna_pubkey will probably return 0 */
+ service->keys.identity_sk[0] &= 248;
+ service->keys.identity_sk[31] &= 127;
+ service->keys.identity_sk[31] |= 64;
+
if (ed25519_public_key_generate(&service->keys.identity_pk,
&service->keys.identity_sk) < 0) {
log_warn(LD_CONFIG, "Unable to generate ed25519 public key"
**Trac**:
**Username**: saibatoTor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33073Write a proposal for Tor Relays to Automatically Find their IPv6 Address2020-06-27T13:48:25ZteorWrite a proposal for Tor Relays to Automatically Find their IPv6 AddressFor Sponsor 55, I need to write a proposal for IPv6 address detection on relays.For Sponsor 55, I need to write a proposal for IPv6 address detection on relays.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33074tor opens multiple ports if `ExtORPort auto` is used multiple times; only use...2020-06-27T13:48:25ZDavid Fifielddcf@torproject.orgtor opens multiple ports if `ExtORPort auto` is used multiple times; only uses one of themCreate a file `logenv` and make it executable:
```
#!/bin/sh
env >> env.txt
```
Run tor with this torrc:
```
SocksPort 0
ORPort auto
BridgeRelay 1
PublishServerDescriptor 0
ServerTransportPlugin logenv exec ./logenv
ExtORPort auto
ExtO...Create a file `logenv` and make it executable:
```
#!/bin/sh
env >> env.txt
```
Run tor with this torrc:
```
SocksPort 0
ORPort auto
BridgeRelay 1
PublishServerDescriptor 0
ServerTransportPlugin logenv exec ./logenv
ExtORPort auto
ExtORPort auto
ExtORPort auto
ExtORPort auto
ExtORPort auto
```
The 5 instances of `ExtORPort auto` cause tor to open 5 separate ports:
```
Jan 28 02:13:57.497 [notice] Opening Extended OR listener on 127.0.0.1:0
Jan 28 02:13:57.497 [notice] Extended OR listener listening on port 45725.
Jan 28 02:13:57.497 [notice] Opened Extended OR listener on 127.0.0.1:0
Jan 28 02:13:57.497 [notice] Opening Extended OR listener on 127.0.0.1:0
Jan 28 02:13:57.497 [notice] Extended OR listener listening on port 38173.
Jan 28 02:13:57.497 [notice] Opened Extended OR listener on 127.0.0.1:0
Jan 28 02:13:57.497 [notice] Opening Extended OR listener on 127.0.0.1:0
Jan 28 02:13:57.497 [notice] Extended OR listener listening on port 34313.
Jan 28 02:13:57.497 [notice] Opened Extended OR listener on 127.0.0.1:0
Jan 28 02:13:57.497 [notice] Opening Extended OR listener on 127.0.0.1:0
Jan 28 02:13:57.498 [notice] Extended OR listener listening on port 44593.
Jan 28 02:13:57.498 [notice] Opened Extended OR listener on 127.0.0.1:0
Jan 28 02:13:57.498 [notice] Opening Extended OR listener on 127.0.0.1:0
Jan 28 02:13:57.498 [notice] Extended OR listener listening on port 40255.
Jan 28 02:13:57.498 [notice] Opened Extended OR listener on 127.0.0.1:0
```
Only one of them (the first one logged) is actually given to the pluggable transport:
```
$ grep ^TOR_PT_EXTENDED_SERVER_PORT env.txt
TOR_PT_EXTENDED_SERVER_PORT=127.0.0.1:45725
```
I expected that tor would report an error if `ExtORPort` were used more than once, or perhaps deduplicate multiple identical `ExtORPort` lines.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33075Travis: Remove stem from the list of allow_failure jobs2020-06-27T13:48:25ZteorTravis: Remove stem from the list of allow_failure jobsIt looks like `make test-stem` is working now. So let's make sure we see any failures.It looks like `make test-stem` is working now. So let's make sure we see any failures.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33078Explicit Congestion Control Meta-Proposal2020-07-27T18:35:57ZMike PerryExplicit Congestion Control Meta-ProposalWe should review all of the past congestion control attempts in tor, and go through new options that haven't been tried yet.We should review all of the past congestion control attempts in tor, and go through new options that haven't been tried yet.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33086Support brotli compression for directory requests2022-06-17T19:03:32ZNick MathewsonSupport brotli compression for directory requestsBrotli seems to outperform zstd in compression, and claims performance comparable to deflate. We should investigate using it for directory requests.Brotli seems to outperform zstd in compression, and claims performance comparable to deflate. We should investigate using it for directory requests.rl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/33087closing stdio fds on exit can interfere with LeakSanitizer, etc2020-10-22T17:30:56ZTaylor Yuclosing stdio fds on exit can interfere with LeakSanitizer, etcAt tor exit time, `tor_log_close_sigsafe_err_fds()` winds up closing stderr or stdout if they're being log destinations. This can close stderr before tools like LeakSanitizer can output useful information, e.g., if there's a config sett...At tor exit time, `tor_log_close_sigsafe_err_fds()` winds up closing stderr or stdout if they're being log destinations. This can close stderr before tools like LeakSanitizer can output useful information, e.g., if there's a config setting like `Log notice stderr`. (valgrind doesn't seem to have this problem, maybe because it runs a separate process?)
Is it correct for us to close a default fd like stderr or stdout if we're not running as a daemon? Other tools that do runtime interception might also be affected. If we think we have a good reason to explicitly close these fds, we probably should document how tor's closing of these fds can interfere with debugging tools.
nickm thinks this behavior might be new in 0.4.2 with the signal safety work. I haven't had time to investigate further.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33091Remove redundant checks in ip_address_changed()2021-09-16T14:22:17ZteorRemove redundant checks in ip_address_changed()ip_address_changed() does a separate exit policy check, but all relays need to refresh their descriptors when their address changes.ip_address_changed() does a separate exit policy check, but all relays need to refresh their descriptors when their address changes.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33092Pass -bind_at_load on macOS2020-06-27T13:48:24ZteorPass -bind_at_load on macOSHere is a PR from a new contributor:
https://github.com/torproject/tor/pull/1655Here is a PR from a new contributor:
https://github.com/torproject/tor/pull/1655Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33093Use IF_BUG_ONCE in buf_flush_to_tls()2021-08-23T15:12:43ZNick MathewsonUse IF_BUG_ONCE in buf_flush_to_tls()See parent: the BUG() messages in this function caused dgoulet to run out of disk.See parent: the BUG() messages in this function caused dgoulet to run out of disk.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33095Don't say "future instances of this warning will be suppressed" when we don't...2020-07-09T15:03:04ZNick MathewsonDon't say "future instances of this warning will be suppressed" when we don't mean it.Some of our definitions of the BUG() macro pass 1 as `once` to tor_bug_occurred_(), causing it to claim that we're only warning once.Some of our definitions of the BUG() macro pass 1 as `once` to tor_bug_occurred_(), causing it to claim that we're only warning once.Tor: 0.4.2.x-finalNick MathewsonNick Mathewson