Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:10:40Zhttps://gitlab.torproject.org/legacy/trac/-/issues/22720Don't exit(0) on error: exit(1) instead2020-06-13T15:10:40ZNick MathewsonDon't exit(0) on error: exit(1) insteadper recent tor-talk thread, there are several places in our code where we exit(0) on an error, and we should exit(1) instead.
When fixing this, it's a good idea to check every exit(0) to see whether it's an error or an expected exit con...per recent tor-talk thread, there are several places in our code where we exit(0) on an error, and we should exit(1) instead.
When fixing this, it's a good idea to check every exit(0) to see whether it's an error or an expected exit condition.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22719Bug: src/common/compress.c:576: tor_compress_process:2020-06-13T15:14:00ZtoralfBug: src/common/compress.c:576: tor_compress_process:Got this today (used latest git version) at a stable Gentoo Linux server:
```
Jun 24 11:01:47.000 [warn] tor_bug_occurred_(): Bug: src/common/compress.c:576: tor_compress_process: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len ...Got this today (used latest git version) at a stable Gentoo Linux server:
```
Jun 24 11:01:47.000 [warn] tor_bug_occurred_(): Bug: src/common/compress.c:576: tor_compress_process: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig) failed. (on Tor 0.3.2.0-alpha-dev dc47d936d47ffc25)
```Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22702Never send a consensus which the downloader already has2020-06-13T15:10:34ZNick MathewsonNever send a consensus which the downloader already hasFWICT, we have a regression in our new consensus code: we no longer check the if-modified-since date when serving consensuses, since that field isn't set in the consensus_cache_entry_t case of .
Additionally, if somebody says X-Or-Diff-...FWICT, we have a regression in our new consensus code: we no longer check the if-modified-since date when serving consensuses, since that field isn't set in the consensus_cache_entry_t case of .
Additionally, if somebody says X-Or-Diff-From the consensus which we currently have, then instead of telling them "That's up-to-date", we also send the current consensus. That's also bad.
These problems make the most trouble in test networks, where the consensus update rate is so fast that relays frequently try to download a consensus before it's there.
Diagnosed with help from ahf.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22672Defensive programming: ensure no infinite COMPRESS_OK loops2020-06-13T15:10:23ZNick MathewsonDefensive programming: ensure no infinite COMPRESS_OK loopsThere's a possible failure mode if we've screwed up in our compression backends: we might say "COMPRESS_OK" over and over, while not making any progress. The changes I'm suggesting in #22629 turn this possible bug into a possible infini...There's a possible failure mode if we've screwed up in our compression backends: we might say "COMPRESS_OK" over and over, while not making any progress. The changes I'm suggesting in #22629 turn this possible bug into a possible infinite loop.
I don't think this failure mode actually exists today, but let's prevent it anyway, by treating a COMPRESS_OK that makes no progress as if it were an error, and a BUG.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22670Clean up warning behavior of decompression code in connection_dir_client_reac...2020-06-13T15:10:22ZNick MathewsonClean up warning behavior of decompression code in connection_dir_client_reached_eof()There are several goofy things about the code that handles decompression in the above function.
First, when it decides to try two decompression methods, it logs failures from either one, even though it's only a big problem when they bot...There are several goofy things about the code that handles decompression in the above function.
First, when it decides to try two decompression methods, it logs failures from either one, even though it's only a big problem when they both fail.
Second, it treats a mismatched content-encoding as "info" when it should probably be "protocol_warn".
Third, it should be in its own function.
Fourth, the second call to warn_disallowed_anonymous_compression should probably only happen when we are about to call tor_uncompress() the second time.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22669When sending cached_dir_t objects compressed with zlib, do not claim zstd com...2020-06-13T15:10:22ZNick MathewsonWhen sending cached_dir_t objects compressed with zlib, do not claim zstd compression.Right now our code in handle_status_vote sends cached_dir_t objects in their deflated variant when compression is negotiated... but it claims to have compressed them with zstd when both sides support that.
This has been a bit of a heise...Right now our code in handle_status_vote sends cached_dir_t objects in their deflated variant when compression is negotiated... but it claims to have compressed them with zstd when both sides support that.
This has been a bit of a heisenbug, since it only happens when we're downloading votes, which doesn't happen with the usual timing on chutney.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22638Typo in compress_none.c header comment2020-06-13T15:10:16ZteorTypo in compress_none.c header commentThe file name is wrong:
```
* \file compress_lzma.c
* \brief Compression backend for identity compression.
```The file name is wrong:
```
* \file compress_lzma.c
* \brief Compression backend for identity compression.
```Tor: 0.3.1.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/22629tor_compress_impl() ignores trailing input garbage when decompressing2020-06-13T15:10:14Zteortor_compress_impl() ignores trailing input garbage when decompressingIn `case TOR_COMPRESS_OK:`, it will happily report success when in_len is non-zero.In `case TOR_COMPRESS_OK:`, it will happily report success when in_len is non-zero.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22628ZSTD_decompressStream doesn't ever say TOR_COMPRESS_BUFFER_FULL2020-06-13T15:10:13ZteorZSTD_decompressStream doesn't ever say TOR_COMPRESS_BUFFER_FULLInstead, it causes an error if it runs out of buffer space.Instead, it causes an error if it runs out of buffer space.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22626Missing stream NULL check in tor_compress_impl2020-06-13T15:10:13ZteorMissing stream NULL check in tor_compress_implThe second time we create a stream in tor_compress_impl, we don't check if it's NULL.The second time we create a stream in tor_compress_impl, we don't check if it's NULL.Tor: 0.3.1.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22623New compression options require pkg-config2020-06-13T15:10:12ZteorNew compression options require pkg-configPreviously, tor only required pkg-config to build with systemd support. So only Linux distributions with systemd needed to worry about pkg-config.
Now the compression options also require pkg-config, making it a new dependency on a sign...Previously, tor only required pkg-config to build with systemd support. So only Linux distributions with systemd needed to worry about pkg-config.
Now the compression options also require pkg-config, making it a new dependency on a significant number of platforms.
We need to put this in the release announcement.
See:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219864#c1Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22550pkg-config fails to find static library for zstd2020-06-13T15:10:06Zyurivict271pkg-config fails to find static library for zstdStatic build fails to find the libzstd.a library. This is because it uses pkg-config, and zstd's .pc file is missing .private tag. Please see the ticket I submitted: https://github.com/facebook/zstd/issues/719
You probably didn't test t...Static build fails to find the libzstd.a library. This is because it uses pkg-config, and zstd's .pc file is missing .private tag. Please see the ticket I submitted: https://github.com/facebook/zstd/issues/719
You probably didn't test the static build with zstd. In any case, static build is broken due to this problem.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22520Incorrect encoding for error message2020-06-13T15:10:04ZTracIncorrect encoding for error messageWhen you try to run "tor --service install" in russian Windows 7 x64 SP1 without administrative priviliges, you will get following error: "OpenSCManager() failed : ╬Єърчрэю т фюёЄєях."
But this is incorrect. Correct message should be "Op...When you try to run "tor --service install" in russian Windows 7 x64 SP1 without administrative priviliges, you will get following error: "OpenSCManager() failed : ╬Єърчрэю т фюёЄєях."
But this is incorrect. Correct message should be "OpenSCManager() failed : Отказано в доступе.".
**Trac**:
**Username**: VortTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22502Investigate Zstandard decompression error2020-06-13T15:10:02ZAlexander Færøyahf@torproject.orgInvestigate Zstandard decompression error`make test-network` with current tor `HEAD` yields a number of warning related to Zstandard decompression, which indicates we have a bug somewhere. The relevant error snippet is:
```
Warning: Error while uncompresing data: bad input? Nu...`make test-network` with current tor `HEAD` yields a number of warning related to Zstandard decompression, which indicates we have a bug somewhere. The relevant error snippet is:
```
Warning: Error while uncompresing data: bad input? Number: 2
Warning: Zstandard decompression didn't finish: Unknown frame descriptor. Number: 2
```
Both Nick and I are able to reproduce this issue on FC and Debian stretch with different versions of libzstd, which probably indicate that this issue is in our code.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22494Fix TROVE-2017-0052020-06-13T15:10:00ZNick MathewsonFix TROVE-2017-005Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22493Fix TROVE-2017-0042020-06-13T15:09:59ZNick MathewsonFix TROVE-2017-004Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22460Link handshake trouble: certificates and keys can get out of sync2020-06-13T15:09:51ZteorLink handshake trouble: certificates and keys can get out of syncI'm running a recent tor master as an authority in a tor testing network:
```
[notice] Tor 0.3.1.0-alpha-dev (git-0266c4ac819d9c83) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2k, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
...I'm running a recent tor master as an authority in a tor testing network:
```
[notice] Tor 0.3.1.0-alpha-dev (git-0266c4ac819d9c83) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2k, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
```
I get this warning every so often:
```
[warn] Received a bad CERTS cell: Link certificate does not match TLS certificate
```
Is this expected?Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22424Always check for usage underflows in the storage API2020-06-13T15:09:40ZteorAlways check for usage underflows in the storage APITor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22421Update fallback config comment for exponential backoff2020-06-13T15:09:39ZteorUpdate fallback config comment for exponential backoffWe modified the fallback behaviour when we merged the exponential backoff code in 0.2.9.1-alpha, and again in #17750:
```
/* With the ClientBootstrapConsensus*Download* below:
* Clients with only authorities will try:
* - 3 author...We modified the fallback behaviour when we merged the exponential backoff code in 0.2.9.1-alpha, and again in #17750:
```
/* With the ClientBootstrapConsensus*Download* below:
* Clients with only authorities will try:
* - 3 authorities over 10 seconds, then wait 60 minutes.
* Clients with authorities and fallbacks will try:
* - 2 authorities and 4 fallbacks over 21 seconds, then wait 60 minutes.
* Clients will also retry when an application request arrives.
* After a number of failed reqests, clients retry every 3 days + 1 hour.
*
* Clients used to try 2 authorities over 10 seconds, then wait for
* 60 minutes or an application request.
*
* When clients have authorities and fallbacks available, they use these
* schedules: (we stagger the times to avoid thundering herds) */
V(ClientBootstrapConsensusAuthorityDownloadSchedule, CSV_INTERVAL,
"6, 11, 3600, 10800, 25200, 54000, 111600, 262800" /* 3 days + 1 hour */),
V(ClientBootstrapConsensusFallbackDownloadSchedule, CSV_INTERVAL,
"0, 1, 4, 11, 3600, 10800, 25200, 54000, 111600, 262800"),
/* When clients only have authorities available, they use this schedule: */
V(ClientBootstrapConsensusAuthorityOnlyDownloadSchedule, CSV_INTERVAL,
"0, 3, 7, 3600, 10800, 25200, 54000, 111600, 262800"),
```
The behaviour is now:
```
/* With the ClientBootstrapConsensus*Download* below:
* Clients with only authorities will try:
* - at least 3 authorities over 10 seconds, then exponentially backoff,
* with the next attempt 3-21 seconds later,
* Clients with authorities and fallbacks will try:
* - at least 2 authorities and 4 fallbacks over 21 seconds, then
* exponentially backoff, with the next attempts 4-33 seconds later,
* Clients will also retry when an application request arrives.
* After a number of failed requests, clients retry every 3 days + 1 hour.
*
* Clients used to try 2 authorities over 10 seconds, then wait for
* 60 minutes or an application request.
```Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22417crash: double free or corruption (fasttop):2020-06-13T15:09:38Ztoralfcrash: double free or corruption (fasttop):stable hardened Gentoo Linux server with 0.3.1.1_alpha2 while reloading config (splitted torrc into smaller files) :
and again I had to attach the trace isntead just putting it here into ` ` b/c TRAC rejected the input as being spam :-/stable hardened Gentoo Linux server with 0.3.1.1_alpha2 while reloading config (splitted torrc into smaller files) :
and again I had to attach the trace isntead just putting it here into ` ` b/c TRAC rejected the input as being spam :-/Tor: 0.3.1.x-finalJigsaw52Jigsaw52