Fortunately, the arithmetic cannot actually overflow, so long as we
*always* check for the size of potentially hostile input before
copying it. I think we do, though. We do check each line against
MAX_LINE_LENGTH, and each object name or object against
MAX_UNPARSED_OBJECT_SIZE, both of which are 128k. So to get this
overflow, we need to have our memarea allocated way way too high up
in RAM, which most allocators won't actually do.
Bugfix on 0.2.1.1-alpha, where memarea was introduced.
Found by Guido Vranken.
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.
This makes our compilation options checks in autoconf work better on
systems that already define _FORTIFY_SOURCE.
Fixes at least one case of bug 18841; bugfix on 0.2.3.17-beta. Patch
from "trudokal".
Also, put libor-testing.a at a better position in the list of
libraries, to avoid linker errors.
This is a fix, or part of a fix, for 18490.
Conflicts:
src/test/include.am
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.
Short version: clang asan hates the glibc strcmp macro in
bits/string2.h if you are passing it a constant string argument of
length two or less. (I could be off by one here, but that's the
basic idea.)
Closes issue 14821.
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.
