Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:25:22Zhttps://gitlab.torproject.org/legacy/trac/-/issues/26007Stop logging stack contents when reading a zero-length bandwidth file2020-06-13T15:25:22ZteorStop logging stack contents when reading a zero-length bandwidth fileWhen reading a zero-length bandwidth file, Tor directory authorities read an uninitialised buffer and log it at warning level.
There is no guarantee that the buffer contains a NUL byte.When reading a zero-length bandwidth file, Tor directory authorities read an uninitialised buffer and log it at warning level.
There is no guarantee that the buffer contains a NUL byte.Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/25803Infinite restart loop when daemon crashes2020-06-13T15:38:48ZTracInfinite restart loop when daemon crashesOn Ubuntu, using Tor from the official PPA, when the Tor daemon crashes (im my case because of this bug https://trac.torproject.org/projects/tor/ticket/23693), it is automatically restarted.
As a result Tor uses 100% CPU continuously be...On Ubuntu, using Tor from the official PPA, when the Tor daemon crashes (im my case because of this bug https://trac.torproject.org/projects/tor/ticket/23693), it is automatically restarted.
As a result Tor uses 100% CPU continuously because of its hopeless start->crash->start->crash... behavior.
A better behavior could be to detect the crash (SIGSEV, SIGABRT...) from the process return code and do not restart in that case.
The crash-restart loop behavior can also be dangerous security wise, because for example exploits against ASLR have a framework to do brute force attacks if the process automatically restarts.
I could not understand where this behavior comes from in the code, because the systemd service file in /lib/systemd/system/tor.service seem to be empty.
**Trac**:
**Username**: tiejohg2sahthTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24736Clear the address when fascist_firewall_choose_address_base() can't find an a...2020-06-13T15:19:29ZteorClear the address when fascist_firewall_choose_address_base() can't find an addressWe should do this as a precaution, so we're not re-using an uninitialised address.
This is similar to #23874.We should do this as a precaution, so we're not re-using an uninitialised address.
This is similar to #23874.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/24526Make it clear that multi-relay operators are expected to set a working Contac...2020-06-13T15:18:25ZcypherpunksMake it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamilyAs per discussion with David on bad-relays@ I'm opening this ticket as he requested.
We want to make it clear to tor relay operators that setting a proper ContactInfo (working email address) and MyFamily (fully mutual configuration) is ...As per discussion with David on bad-relays@ I'm opening this ticket as he requested.
We want to make it clear to tor relay operators that setting a proper ContactInfo (working email address) and MyFamily (fully mutual configuration) is strongly encouraged (required?) for relay operators that run more than 3 (?) tor instances, relays showing up without such configuration likely raise a red flag and might get rejected from the network.
places to update:
* manual page:
* ContactInfo
* MyFamily
* relay documentation (#24497)Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/24509circuit_can_use_tap() should only allow TAP for v2 onion services2020-06-13T15:18:23Zteorcircuit_can_use_tap() should only allow TAP for v2 onion servicescircuit_can_use_tap() checks the circuit purpose to make sure that it's an onion service circuit. But it should also check that the circuit is for a v2 onion service before allowing TAP.
There should be a field in the circuit or extend_...circuit_can_use_tap() checks the circuit purpose to make sure that it's an onion service circuit. But it should also check that the circuit is for a v2 onion service before allowing TAP.
There should be a field in the circuit or extend_info that we can use for this.
This is security-low, because it's a defence in depth mechanism that doesn't provide as much defence as we thought.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24467Enable -Wnormalized=nfkc when available to avoid source code identifier confu...2020-06-13T15:18:11ZteorEnable -Wnormalized=nfkc when available to avoid source code identifier confusionIn https://people.torproject.org/~nickm/warnings.html , nickm asks:
> We use -Wnormalized=id now; should we switch?
Yes, we should switch to `-Wnormalized=nfkc`, as a precaution against patches that are submitted with similar-looking ...In https://people.torproject.org/~nickm/warnings.html , nickm asks:
> We use -Wnormalized=id now; should we switch?
Yes, we should switch to `-Wnormalized=nfkc`, as a precaution against patches that are submitted with similar-looking characters. Ideally, we would use `-Wnormalized=ban-unicode-in-identifiers`, but that's not something gcc has implemented yet.
From https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Some characters in ISO 10646 have distinct meanings but look identical in some fonts or display methodologies, especially once formatting has been applied. For instance \u207F, “SUPERSCRIPT LATIN SMALL LETTER N”, displays just like a regular n that has been placed in a superscript. ISO 10646 defines the NFKC normalization scheme to convert all these into a standard form as well, and GCC warns if your code is not in NFKC if you use -Wnormalized=nfkc. This warning is comparable to warning about every identifier that contains the letter O because it might be confused with the digit 0, and so is not the default, but may be useful as a local coding convention if the programming environment cannot be fixed to display these characters distinctly.
clang hasn't implemented -Wnormalized yet:
https://clang.llvm.org/docs/DiagnosticsReference.htmlTor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24455messages out of order in the tor log due to stored logs2020-06-13T15:18:09ZLeonid Evdokimovmessages out of order in the tor log due to stored logsWhile checking various data for #23838 I've found some cases of logs with clock ticking backwards [a bit](https://explorer.ooni.torproject.org/measurement/20161012T024947Z_AS30722_f5qzz4lFUyWAIsaBipwkjXhNSuYn5S840SyVpJmFDn1AFcv1ws).
```...While checking various data for #23838 I've found some cases of logs with clock ticking backwards [a bit](https://explorer.ooni.torproject.org/measurement/20161012T024947Z_AS30722_f5qzz4lFUyWAIsaBipwkjXhNSuYn5S840SyVpJmFDn1AFcv1ws).
```
Oct 12 04:53:01.000 [notice] Tor 0.2.7.6 opening new log file.
Oct 12 04:53:00.963 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 1000205f: OpenSSL 1.0.2e 3 Dec 2015; running with 1000208f: OpenSSL 1.0.2h 3 May 2016).
Oct 12 04:53:00.995 [notice] Tor v0.2.7.6 running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2h and Zlib 1.2.5.
Oct 12 04:53:00.995 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Oct 12 04:53:00.995 [notice] Configuration file "/non-existant" not present, using reasonable defaults.
Oct 12 04:53:00.999 [notice] Opening Socks listener on 127.0.0.1:16025
Oct 12 04:53:00.999 [notice] Opening Control listener on 127.0.0.1:4367
Oct 12 04:53:01.000 [notice] Parsing GEOIP IPv4 file /usr/local/Cellar/tor/0.2.7.6/share/tor/geoip.
Oct 12 04:53:01.000 [notice] Parsing GEOIP IPv6 file /usr/local/Cellar/tor/0.2.7.6/share/tor/geoip6.
Oct 12 04:53:02.000 [notice] Bootstrapped 0%: Starting
```
I looked at `tor/src/common/log.c`:`log_prefix_()` and, seems, this is NOT a bug in [rounding](https://gitweb.torproject.org/tor.git/commit/?id=8c5ba9388bd372316cc18f23dcb6d41b4c1e9546). But maybe I'm wrong. Karsten, please, tell me if you need more logs like that to understand the issue better. Maybe it's really just OS clocks ticking backwards during the test, so feel free to close if you don't consider alike logs interesting.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24104Delay descriptor bandwidth reporting on established relays2020-06-13T15:27:48ZteorDelay descriptor bandwidth reporting on established relaysIn #23856, we:
* reduced the bandwidth stats interval from 4 hours to 24 hours, and
* reduced urgent (2x change) descriptor bandwidth reports from every 20 minutes to every 3 hours.
But we think we can make descriptor bandwidth reports ...In #23856, we:
* reduced the bandwidth stats interval from 4 hours to 24 hours, and
* reduced urgent (2x change) descriptor bandwidth reports from every 20 minutes to every 3 hours.
But we think we can make descriptor bandwidth reports even slower on large relays, because they have less need to ramp up their bandwidth.
Here are our options:
* don't report until the change is larger, for example, 4x
* don't report for longer, for example, every 6 hours or 24 hours
* delay the reporting of the *first* large change, as well as subsequent large changes
Here are the open questions:
* tor traffic has a daily cycle, so do we need to report large bandwidth changes multiple times a day to cope with this? (I think the answer is "no", because small changes are already reported every 18 hours on the standard descriptor schedule, and that seems to work fine. And large changes are already reported once, then the delay is imposed.)Tor: 0.2.9.x-finaljugajugahttps://gitlab.torproject.org/legacy/trac/-/issues/23415sample_laplace_distribution() should take multiple random inputs2020-06-13T15:13:20Zteorsample_laplace_distribution() should take multiple random inputsCurrently, sample_laplace_distribution() takes a random double as input, and then extracts the following random values:
* a random sign
* a random value in (0.0, 1.0]
This reduces the precision of the result. For details, see:
https://t...Currently, sample_laplace_distribution() takes a random double as input, and then extracts the following random values:
* a random sign
* a random value in (0.0, 1.0]
This reduces the precision of the result. For details, see:
https://trac.torproject.org/projects/tor/ticket/23061#comment:32
Instead, the function could take a random boolean sign and p, and the transform becomes:
```
result = mu - b * (sign ? 1.0 : -1.0)
* tor_mathlog(1.0 - p);
```
This would increase the precision by one bit, plus whatever precision is lost in `2.0 * fabs(p - 0.5)`.
This may have been introduced in dad5eb7.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23414rep_hist_format_hs_stats() should add noise, then round2020-06-13T15:13:19Zteorrep_hist_format_hs_stats() should add noise, then roundIn order to guarantee differential privacy, we need to:
* sample at the scale of the noise (not unit scale)
* add the noise to the signal
* round the noisy signal
This is the "snapping" mitigation from "On Significance of the Least Sign...In order to guarantee differential privacy, we need to:
* sample at the scale of the noise (not unit scale)
* add the noise to the signal
* round the noisy signal
This is the "snapping" mitigation from "On Significance of the Least Significant Bits For Differential Privacy" by Ilya Mironov
https://pdfs.semanticscholar.org/2f2b/7a0d5000a31f7f0713a3d20919f9703c9876.pdf
rep_hist_format_hs_stats() rounds once to the bin size, then adds noise which has been rounded to the nearest integer. This isn't ideal, because it makes the least significant bits of the noise meaningless.
Instead, we should:
* round the noise to integer precision
* add the signal to the noise
* round the noisy signal to the bin size
I think this was introduced in 14e83e6.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23412Do bandwidth authorities reset history when the relay fingerprint changes?2020-06-13T16:19:47ZTracDo bandwidth authorities reset history when the relay fingerprint changes?I deleted all the private keys from my relay and created a new one, within the day of the new one running it’s middle probability jumped up to around what the other relay had after a week of running. Is this a bug?
My relay.
https://at...I deleted all the private keys from my relay and created a new one, within the day of the new one running it’s middle probability jumped up to around what the other relay had after a week of running. Is this a bug?
My relay.
https://atlas.torproject.org/#details/CD8F43AE828C7F9A8B32C6DC9B5D7DABB4D27A97
**Trac**:
**Username**: Dbryrtfbcbhgfhttps://gitlab.torproject.org/legacy/trac/-/issues/23323sample_laplace_distribution should produce a valid result on 0.02020-06-13T15:13:02Zteorsample_laplace_distribution should produce a valid result on 0.0Destroying the signal with probability 1 in 2^-53^ isn't a great idea.
Let's pick a sensible double value, and pass it through the function instead.
I suggest 2^-54^, but it really doesn't matter exactly what value we use, as long as it...Destroying the signal with probability 1 in 2^-53^ isn't a great idea.
Let's pick a sensible double value, and pass it through the function instead.
I suggest 2^-54^, but it really doesn't matter exactly what value we use, as long as it produces valid results, because the probability is so low.
Introduced in 45bc5a0Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23318compute_weighted_bandwidths: do not add 0.5 to final_weight2020-06-13T15:17:04Zcypherpunkscompute_weighted_bandwidths: do not add 0.5 to final_weightThis extra 0.5 leads to non-zero probability to bypass bandwidth weights limitations. Like to pick Exit+Guard as Guard while there are not enough bandwidth.This extra 0.5 leads to non-zero probability to bypass bandwidth weights limitations. Like to pick Exit+Guard as Guard while there are not enough bandwidth.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23113Manage DNS state better when "All nameservers have failed"2020-06-13T15:12:26ZteorManage DNS state better when "All nameservers have failed"We should downgrade this warning when it only happens for a short period of time (or a small number of requests), or when it happens in response to a malformed request.
This warning is causing operators to make sub-optimal DNS server ch...We should downgrade this warning when it only happens for a short period of time (or a small number of requests), or when it happens in response to a malformed request.
This warning is causing operators to make sub-optimal DNS server choices: for example, avoiding using a local cache in favour of remote resolvers.
Sometimes changing the local resolver makes a difference:
https://trac.torproject.org/projects/tor/ticket/1936#comment:12
Sometimes it happens in response to malformed requests:
https://trac.torproject.org/projects/tor/ticket/11600#comment:6
Sometimes it's harmless:
https://trac.torproject.org/projects/tor/ticket/11600#comment:7
Because it's followed by:
```
[notice] eventdns: Nameserver <ISP-resolver2>:53 is back up
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23061crypto_rand_double() should produce all possible outputs on platforms with 32...2020-06-13T15:16:34Zteorcrypto_rand_double() should produce all possible outputs on platforms with 32-bit intOn 32-bit platforms, crypto_rand_double() only produces 1 in every 2 million possible values between 0 and 1.
This happens because:
* crypto_rand_double() divides a random unsigned int by UINT_MAX
* an unsigned int on 32-bit platforms i...On 32-bit platforms, crypto_rand_double() only produces 1 in every 2 million possible values between 0 and 1.
This happens because:
* crypto_rand_double() divides a random unsigned int by UINT_MAX
* an unsigned int on 32-bit platforms is 32 bits
* the mantissa on a double is 53 bits
So crypto_rand_double() doesn't fill the lower 21 bits with random values.
This makes the rep_hist_format_hs_stats() noise more predictable on 32-bit platforms.
This fix shouldn't affect the unit tests, because they pass on 64-bit.Tor: unspecified