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.
Decide to advertise begindir support in a similar way to how
we decide to advertise DirPort.
Fix up the associated descriptor-building unit tests.
Resolves#18616, bugfix on 0c8e042c30 in #12538 in 0.2.8.1-alpha.
When the directory authorities refuse a bad relay's descriptor,
encourage the relay operator to contact us. Many relay operators
won't notice this line in their logs, but it's a win if even a
few learn why we don't like what their relay was doing.
Resolves ticket 18760.
I didn't specify a contact mechanism (e.g. an email address), because
every time we've done that in the past, a few years later we noticed
that the code was pointing people to an obsolete contact address.
This change allows us to simplify path selection for clients, and it
should have minimal effect in practice since >99% of Guards already have
the Stable flag. Implements ticket 18624.
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.
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.
They are no longer "all" digests, but only the "common" digests.
Part of 17795.
This is an automated patch I made with a couple of perl one-liners:
perl -i -pe 's/crypto_digest_all/crypto_common_digests/g;' src/*/*.[ch]
perl -i -pe 's/\bdigests_t\b/common_digests_t/g;' src/*/*.[ch]
Avoid using a pronoun where it makes comments unclear.
Avoid using gender for things that don't have it.
Avoid assigning gender to people unnecessarily.
When a relay does not have an open directory port but it has an
orport configured and is accepting client connections then it can
now service tunnelled directory requests, too. This was already true
of relays with an dirport configured.
We also conditionally stop advertising this functionality if the
relay is nearing its bandwidth usage limit - same as how dirport
advertisement is determined.
Partial implementation of prop 237, ticket 12538
In validate_recommended_package_line, at this point in the function,
n_entries is always >= 1. Coverity doesn't like us checking it for
0.
CID 1268063.
Make it easier to unit test TestingDirAuthVote{Exit,Guard,HSDir}
by refactoring the code which sets flags based on them into a
new function dirserv_set_routerstatus_testing.
"option to prevent guard,exit,hsdir flag assignment"
"A node will never receive the corresponding flag unless
that node is specified in the
TestingDirAuthVote{Exit,Guard,HSDir} list, regardless of
its uptime, bandwidth, exit policy, or DirPort".
Patch modified by "teor": VoteOnHidServDirectoriesV2
is now obsolete, so TestingDirAuthVoteHSDir always
votes on HSDirs.
Closes ticket 14882. Patch by "robgjansen".
Commit message and changes file by "teor"
with quotes from "robgjansen".
When we removed Running/Valid checks from Fast and Stable in 8712, I
removed them from HSDir too, which apparently wasn't a good idea.
Reverts part of a65e835800. Fixes bug 16524. Bugfix
on 0.2.7.2-alpha.
* Include ed25519 identities in votes
* Include "no ed25519 identity" in votes
* Include some commented-out code about identity voting. (This
will disappear.)
* Include some functions for identity voting (These will disappear.)
* Enforce uniqueness in ed25519 keys within a vote
With this patch:
* Authorities load the key-pinning log at startup.
* Authorities open a key-pinning log for writing at startup.
* Authorities reject any router with an ed25519 key where they have
previously seen that ed25519 key with a different RSA key, or vice
versa.
* Authorities warn about, but *do not* reject, RSA-only descriptors
when the RSA key has previously gone along with an Ed25519 key.
(We should make this a 'reject' too, but we can't do that until we're
sure there's no legit reason to downgrade to 0.2.5.)
Fixes#15850, part of #15801. Change file is added by this commit. The
original comment in the reverted commit is removed because right now we
*need* a DirPort until #15849 is implemented so no doubt nor confusion there
anymore.
This reverts commit 80bed1ac96.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Parse the file just before voting and apply its information to the
provided vote_routerstatus_t. This follows the same logic as when
dirauths parse bwauth files.
TestingDirAuthVoteHSDir ensures that authorities vote the HSDir flag
for the listed relays regardless of uptime or ORPort connectivity.
Respects the value of VoteOnHidServDirectoriesV2.
Partial fix for bug 14067.
Stop requiring exits to have non-zero bandwithcapacity in a
TestingTorNetwork. Instead, when TestingMinExitFlagThreshold is 0,
ignore exit bandwidthcapacity.
This assists in bootstrapping a testing Tor network.
Fixes bugs 13718 & 13839.
Makes bug 13161's TestingDirAuthVoteExit non-essential.
We add a compression level argument to tor_zlib_new, and use it to
determine how much memory to allocate for the zlib object. We use the
existing level by default, but shift to smaller levels for small
requests when we have been over 3/4 of our memory usage in the past
half-hour.
Closes ticket 11791.
One pain point in evolving the Tor design and implementing has been
adding code that makes clients reject directory documents that they
previously would have accepted, if those descriptors actually exist.
When this happened, the clients would get the document, reject it,
and then decide to try downloading it again, ad infinitum. This
problem becomes particularly obnoxious with authorities, since if
some authorities accept a descriptor that others don't, the ones
that don't accept it would go crazy trying to re-fetch it over and
over. (See for example ticket #9286.)
This patch tries to solve this problem by tracking, if a descriptor
isn't parseable, what its digest was, and whether it is invalid
because of some flaw that applies to the portion containing the
digest. (This excludes RSA signature problems: RSA signatures
aren't included in the digest. This means that a directory
authority can still put another directory authority into a loop by
mentioning a descriptor, and then serving that descriptor with an
invalid RSA signatures. But that would also make the misbehaving
directory authority get DoSed by the server it's attacking, so it's
not much of an issue.)
We already have a mechanism to mark something undownloadable with
downloadstatus_mark_impossible(); we use that here for
microdescriptors, extrainfos, and router descriptors.
Unit tests to follow in another patch.
Closes ticket #11243.
Add the TestingDirAuthVoteExit option, a list of nodes to vote Exit for,
regardless of their uptime, bandwidth, or exit policy.
TestingTorNetwork must be set for this option to have any effect.
Works around an issue where authorities would take up to 35 minutes to
give nodes the Exit flag in a test network, despite short consensus
intervals. Partially implements ticket 13161.
Avoid 4 null pointer errors under clang shallow analysis (the default when
building under Xcode) by using tor_assert() to prove that the pointers
aren't null. Resolves issue 13284 via minor code refactoring.
"At this point in the code, msg has been set to a string
constant. But the tor code checks that msg is not NULL, and the
redundant NULL check confuses the analyser[...] To avoid this
spurious warning, the patch initialises msg to NULL."
Patch from teor. another part of 13157.
This implements the meat of #12899. This commit should simply remove the
parts of Tor dirauths used to check whether a relay was supposed to be
named or not, it doesn't yet convert to a new mechanism for
reject/invalid/baddir/badexiting relays.
This function never returns non-null, but its usage doesn't reflect
that. Let's make it explicit. This will be mostly overridden by later
commits, so no changes file here.
This is in preparation for a big patch series removing the entire Naming
system from Tor. In its wake, the approved-routers file is being
deprecated, and a replacement option to allow only pre-approved routers
is not being implemented.
This implements a feature from bug 13000. Instead of starting a bwauth
run with this wrong idea about their bw, relays should do the self-test
and then get measured.
Authorities now assign the Guard flag to the fastest 25% of the
network (it used to be the fastest 50%). Also raise the consensus
weight that guarantees the Guard flag from 250 to 2000. For the
current network, this results in about 1100 guards, down from 2500.
This step paves the way for moving the number of entry guards
down to 1 (proposal 236) while still providing reasonable expected
performance for most users.
Implements ticket 12690.
We should only assign a relay the HSDir flag if it is currently
considered valid. We can accomplish this by only considering active
relays, and as a consequence of this we also exclude relays that are
currently hibernating. Fixes#12573
On OpenBSD 5.4, time_t is a 32-bit integer. These instances contain
implicit treatment of long and time_t as comparable types, so explicitly
cast to time_t.
There are still quite a few 0.2.3.2x relays running for x<5, and while I
agree they should upgrade, I don't think cutting them out of the network
is a net win on either side.
