Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:57:00Zhttps://gitlab.torproject.org/legacy/trac/-/issues/18956Trivial memory leak when reading truncated ed25519 key files2020-06-13T14:57:00ZNick MathewsonTrivial memory leak when reading truncated ed25519 key filesFound while working on #16794. Will fix on that branch. Opening this ticket to give it a number.Found while working on #16794. Will fix on that branch. Opening this ticket to give it a number.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18920Make consensus GETINFO return 551 when using microdescs2020-06-13T14:56:49ZteorMake consensus GETINFO return 551 when using microdescsThe tor control-spec says that 551 should be returned for "dir/status" queries where microdescs are in use, and so full descriptors are unavailable.
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n737
This doesn't happe...The tor control-spec says that 551 should be returned for "dir/status" queries where microdescs are in use, and so full descriptors are unavailable.
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n737
This doesn't happen for dir/status-vote/current/consensus when tor only has a microdesc consensus, instead, tor returns "552 Unrecognized key "dir/status-vote/current/consensus".
https://gitweb.torproject.org/tor.git/tree/src/or/control.c#n2004
The 552 is misleading and not to spec, instead, we should return 551 with a helpful error message.
Credit to s0rlxmh0 for reporting this issue.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18815Clients don't use optimistic data to fetch their first consensus, because we ...2020-06-13T14:56:23ZRoger DingledineClients don't use optimistic data to fetch their first consensus, because we told them to ask the consensus whether they should```
static int
optimistic_data_enabled(void)
{
const or_options_t *options = get_options();
if (options->OptimisticData < 0) {
/* XXX023 consider having auto default to 1 rather than 0 before
* the 0.2.3 branch goes stable....```
static int
optimistic_data_enabled(void)
{
const or_options_t *options = get_options();
if (options->OptimisticData < 0) {
/* XXX023 consider having auto default to 1 rather than 0 before
* the 0.2.3 branch goes stable. See bug 3617. -RD */
const int32_t enabled =
networkstatus_get_param(NULL, "UseOptimisticData", 0, 0, 1);
return (int)enabled;
}
return options->OptimisticData;
}
```
OptimisticData is "auto" by default, aka -1, so we look at networkstatus_get_param, but since there *is* no consensus on first boot, we pick 0.
For one, this means we're opting not to save a round-trip on the Tor user's first bootstrap (the one where they judge Tor first).
For another, it would seem that we're telling the directory mirror whether this is our first bootstrap, because all the other clients do it differently.
For three, it increases the set of possible behaviors by normal clients that we need to consider during bootstrapping, which is how I found it (working on #18809).
We should make it default default to 1 when there's no consensus.
See https://trac.torproject.org/projects/tor/ticket/3617#comment:8 where it seems I looked into the future and saw this bug coming.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18761Make logging of rendezvous to private address quieter2020-06-13T14:56:14ZteorMake logging of rendezvous to private address quieterIn #8976, we blocked rendezvous from hidden services to private addresses.
But the warning is log_warn LD_REND, when arma wonders if it should be a protocol warning to avoid excessive logging on busy services:
```
log_warn(LD_REND, "%...In #8976, we blocked rendezvous from hidden services to private addresses.
But the warning is log_warn LD_REND, when arma wonders if it should be a protocol warning to avoid excessive logging on busy services:
```
log_warn(LD_REND, "%s on circ %u", err_msg,
(unsigned)circuit->base_.n_circ_id);
```
There's also a whitespace issue we might as well fix while we're there:
```
if (err_msg_out) *err_msg_out = err_msg;
else tor_free(err_msg);
```Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18312MapAddress should recommend fingerprints, not nicknames2020-06-13T14:54:19ZteorMapAddress should recommend fingerprints, not nicknamesSince we stopped voting on nicknames, they've become even less reliable as a way to identify a relay.
MapAddress (and similar man page entries) should be updated to recommend the use of fingerprints, not nicknames.Since we stopped voting on nicknames, they've become even less reliable as a way to identify a relay.
MapAddress (and similar man page entries) should be updated to recommend the use of fingerprints, not nicknames.Tor: 0.2.8.x-finalNick MathewsonNick Mathewson