| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
It had been a directory authority since 0.2.1.20.
|
|
|
|
In dirserv_compute_performance_thresholds, we allocate arrays based
on the length of 'routers', a list of routerinfo_t, but loop over
the nodelist. The 'routers' list may be shorter when relays were
filtered by routers_make_ed_keys_unique, leading to an out-of-bounds
write on directory authorities.
This bug was originally introduced in 26e89742, but it doesn't look
possible to trigger until routers_make_ed_keys_unique was introduced
in 13a31e72.
Fixes bug 19032; bugfix on tor 0.2.8.2-alpha.
|
|
|
|
|
|
Documentation-only patch. Issue 17668.T6.
|
|
This ensures that if we can't use published_on to decide an ed,rsa
mapping, we at least decide deterministically.
Resolves 17668.T3
|
|
Fix for 17668.S2.
|
|
We've got to make sure that every single subsequent calculation in
dirserv_generate_networkstatus_vote_obj() are based on the list of
routerinfo_t *after* we've removed possible duplicates, not before.
Fortunately, none of the functions that were taking a routerlist_t
as an argument were actually using any fields other than this list
of routers.
Resolves issue 18318.DG3.
|
|
I had a half-built mechanism to track, during the voting process,
whether the Ed25519 value (or lack thereof) reflected a true
consensus among the authorities. But we never actually inserted this
field in the consensus.
The key idea here is that we first attempt to match up votes by pairs
of <Ed,RSA>, where <Ed> can be NULL if we're told that there is no
Ed key. If this succeeds, then we can treat all those votes as 'a
consensus for Ed'. And we can include all other votes with a
matching RSA key and no statement about Ed keys as being "also about
the same relay."
After that, we look for RSA keys we haven't actually found an entry
for yet, and see if there are enough votes for them, NOT considering
Ed keys. If there are, we match them as before, but we treat them
as "not a consensus about ed".
When we include an entry in a consensus, if it does not reflect a
consensus about ed keys, then we include a new NoEdConsensus flag on
it.
This is all only for consensus method 22 or later.
Also see corresponding dir-spec patch.
|
|
|
|
When generating a vote, and we have two routerinfos with the same ed
key, omit the one published earlier.
This was supposed to have been solved by key pinning, but when I
made key pinning optional, I didn't realize that this would jump up
and bite us. It is part of bug 18318, and the root cause of 17668.
|
|
Some of these messages called the thing being parsed a "vote" whether
it is a vote or a consensus.
Fixes bug 18368.
|
|
|
|
|
|
|
|
Add a changes file.
|
|
Fixes bug 16248. Patch from cypherpunks. Bugfix on 0.2.0.1-alpha.
|
|
Previously, I had left in some debugging code with /*XXX*/ after it,
which nobody noticed. Live and learn! Next time I will use /*XXX
DO NOT COMMIT*/ or something.
We need to define a new consensus method for this; consensus method
21 shouldn't actually be used.
Fixes bug 17702; bugfix on 0.2.7.2-alpha.
|
|
|
|
Otherwise, relays publish a descriptor with DirPort 0 when the DirPort
reachability test takes longer than the ORPort reachability test.
Closes bug #18050. Reported by "starlight", patch by "teor".
Bugfix on 0.1.0.1-rc, commit a1f1fa6ab on 27 Feb 2005.
|
|
Conflicts:
src/or/config.c
|
|
|
|
Conflicts:
src/or/config.c
|
|
This new identity key was changed on 18 November 2015.
|
|
Fixes bug 17675; bugfix on 0.2.7.3-alpha.
|
|
Using the AM_TESTS_ENVIRONMENT variable ensures the environment
variables are only set during test execution and not during the
compilation phase.
|
|
|
|
|
|
|
|
|
|
|
|
There was a dead check when we made sure that an array member of a
struct was non-NULL. Tor has been doing this check since at least
0.2.3, maybe earlier.
Fixes bug 17781.
|
|
Previously we'd suppressed the mask-bits field in the output when
formatting a policy if it was >=32. But that should be a >=128 if
we're talking about IPv6.
Since we didn't put these in descriptors, this bug affects only log
messages and controller outputs.
Fix for bug 16056. The code in question was new in 0.2.0, but the
bug was introduced in 0.2.4 when we started supporting IPv6 exits.
|
|
The tor_cert_get_checkable_sig function uses the signing key included in
the certificate (if available) when a separate public key is not given.
When the signature is valid, the tor_cert_checksig function copies the
public key from the checkable structure to the public key field of the
certificate signing key.
In situations where the separate public key is not given but the
certificate includes a signing key, the source and destination pointers
in the copy operation are equal and invoke undefined behavior.
Undefined behaviour is avoided by ensuring both pointers are different.
|
|
The wrong list was used when looking up expired intro points in a rend
service object causing what we think could be reachability issues and
triggering a BUG log.
Fixes #16702
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
|
|
Closes 17403.
|
|
|
|
Bug 17402.
|
|
The 0.2.8 unit tests provoke this leak, though I don't think it can
happen IRL.
|
|
valgrind
|
|
|
|
Fixes #17354
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
|
|
BSD make takes spaces around = literally
and produces a "TESTING_TOR_BINARY "
variable with a trailing space, which leads
to test_keygen.sh failure.
Fixes 17154
|
|
|
|
Fixes bug 17149; bug not in any released Tor.
|
|
Implements ticket #17135. We're going to need this one to avoid
chaos as everybody figures out how ed25519 keys work.
|
