Unlike tor_assert(), these macros don't abort the process. They're
good for checking conditions we want to warn about, but which don't
warrant a full crash.
This commit also changes the default implementation for
tor_fragile_assert() to tor_assert_nonfatal_unreached_once().
Closes ticket 18613.
This marks some lines as unreachable by the unit tests, and as
therefore excluded from test coverage.
(Note: This convention is only for lines that are absolutely
unreachable. Don't use it anywhere you wouldn't add a
tor_fragile_assert().)
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.
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
This changes simply renames them by removing "Testing" in front of them and
they do not require TestingTorNetwork to be enabled anymore.
Fixes#18481
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Yes, we could cast to unsigned char first, but it's probably safest
to just use our own (in test_util), or remove bad-idea features that
we don't use (in readpassphrase.c).
Fixes 18728.
Only when we were actually flushing the cell stats to a controller
would we free them. Thus, they could stay in RAM even after the
circuit was freed (eg if we didn't have any controllers).
Fixes bug 18673; bugfix on 0.2.5.1-alpha.
Otherwise coverity complains that we're checking an whether an int64 is
less than INT64_MIN, which of course it isn't.
Fixes CID 1357176. Not in any released Tor.
They incorrectly summarized what the function was planning to do,
leading to wrong behavior like making an http request to an orport,
or making a begindir request to a dirport.
This change backs out some of the changes made in commit e72cbf7a, and
most of the changes made in commit ba6509e9.
This patch resolves bug 18625. There more changes I want to make
after this one, for code clarity.
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.
Commit e72cbf7a4 introduced a change to directory_initiate_command_rend()
that made tor use the ORPort when making a directory request to the DirPort.
The primary consequence was that a relay couldn't selftest its DirPort thus
failing to work and join the network properly.
The main issue was we were always considering an anonymized connection to be
an OR connection which is not true.
Fixes#18623
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Regardless of the setting of ExtendAllowPrivateAddresses.
This fixes a bug with pluggable transports that ignore the
(potentially private) address in their bridge line.
Fixes bug 18517; bugfix on 23b088907f in tor-0.2.8.1-alpha.
When requesting extrainfo descriptors from a trusted directory
server, check whether it is an authority or a fallback directory
which supports extrainfo descriptors.
Fixes bug 18489; bugfix on 90f6071d8d in tor-0.2.4.7-alpha.
Reported by "atagar", patch by "teor".
Make it clearer that they are about outgoing connection attempts.
Specify the options involved where they were missing from one log
message.
Clarify a comment.
Downgrade logs and backtraces about IP versions to
info-level. Only log backtraces once each time tor runs.
Assists in diagnosing bug 18351; bugfix on c3cc8e16e in
tor-0.2.8.1-alpha.
Reported by "sysrqb" and "Christian", patch by "teor".
The fd would leak when the User wasn't recogniezed by
getpwnam(). Since we'd then go on to exit, this wasn't a terribad
leak, but it's still not as nice as no leak at all.
CID 1355640; bugfix on no released Tor.
commit edeba3d4 removed a switch, but left the "break" lines in
from that switch. fortunately the resulting behavior was not wrong,
since there was an outer switch that it was ok to break from.
no actual changes here -- but the new indenting makes it clear
that the fixes in #18332 were not as good as they should have been.
the next commit will deal with that.
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.
If we're a server with no address configured, resolve_my_hostname
will need this. But not otherwise. And the preseeding itself can
consume a few seconds if like tails we have no resolvers.
Fixes bug 18548.
I didn't want to grant blanket permissions for chmod() and chown(),
so here's what I had to do:
* Grant open() on all parent directories of a unix socket
* Write code to allow chmod() and chown() on a given file only.
* Grant chmod() and chown() on the unix socket.
This is a part of a fix for 18253; bugfix on 0.2.8.1-alpha.
Alternatively, we could permit chmod/chown in the sandbox, but I
really don't like giving the sandbox permission to alter
permissions.
Launching 7 descriptor fetches makes a connection to each HSDir that is 6
and the seventh one fails to pick an HSDir because they are all being used
already so it was killing all pending connections at once.
Fixes#15937
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
When we made HidServDirectoryV2 always 1, we removed the situation
where a relay could choose not to be an HSDir. Now simplify the
rest of the code to reflect this decision.
(We have to remove two apparently unrelated free() calls in the unit
tests, since they used to free stuff that we created as a side effect
of calling router_get_my_routerinfo(), and now we no longer call that.)
This simplifies relay behavior, because the relay offers the hsdir
functionality independent of whether the directory authorities have
decided this relay is suitable for clients to use yet.
Implements ticket 18332.
The transproxy feature is only enabled when __FreeBSD__ is defined, and
only regular FreeBSD does that. Change this to __FreeBSD_kernel__ which
is defined on derivatives as well.
This enables the relevant options/validate__transproxy test on FreeBSD
derivatives.
