David Goulet [Thu, 24 Jan 2019 15:52:08 +0000 (10:52 -0500)]
kist: Don't write above the highwater outbuf mark
KIST works by computing how much should be allowed to write to the kernel for
a given socket, and then it writes that amount to the outbuf.
The problem is that it could be possible that the outbuf already has lots of
data in it from a previous scheduling round (because the kernel is full/busy
and Tor was not able to flush the outbuf yet). KIST ignores that the outbuf
has been filling (is above its "highwater") and writes more anyway. The end
result is that the outbuf length would exceed INT_MAX, hence causing an
assertion error and a corresponding "Bug()" message to get printed to the
logs.
This commit makes it for KIST to take into account the outbuf length when
computing the available space.
Bug found and patch by Rob Jansen.
Closes #29168. TROVE-2019-001.
Signed-off-by: David Goulet <dgoulet@torproject.org>
teor [Wed, 9 Jan 2019 08:00:34 +0000 (18:00 +1000)]
rend: stop warning when clients send multiple rend establish cells
Stop logging "Tried to establish rendezvous on non-OR circuit..." as
a warning. Instead, log it as a protocol warning, because there is
nothing that relay operators can do to fix it.
teor [Mon, 10 Dec 2018 06:56:29 +0000 (16:56 +1000)]
Fallbacks: Update the hard-coded fallback list in December 2018
Merge Phoul's two lists into teor's list.
Replace the 150 fallbacks originally introduced in Tor 0.3.3.1-alpha in
January 2018 (of which ~115 were still functional), with a list of
157 fallbacks (92 new, 65 existing, 85 removed) generated in
December 2018.
teor [Fri, 7 Dec 2018 06:43:10 +0000 (16:43 +1000)]
Fallbacks: Update the hard-coded fallback list in December 2018
Replace the 150 fallbacks originally introduced in Tor 0.3.3.1-alpha in
January 2018 (of which ~115 were still functional), with a list of
148 fallbacks (89 new, 59 existing, 91 removed) generated in
December 2018.
Nick Mathewson [Thu, 25 Oct 2018 13:06:13 +0000 (09:06 -0400)]
Fix possible UB in an end-of-string check in get_next_token().
Remember, you can't check to see if there are N bytes left in a
buffer by doing (buf + N < end), since the buf + N computation might
take you off the end of the buffer and result in undefined behavior.
Occasionally, key pinning doesn't catch a relay that shares an ed25519
ID with another relay. Log the identity fingerprints and the shared ed25519 ID when this happens, instead of making a BUG() warning.
David Goulet [Mon, 10 Sep 2018 19:04:22 +0000 (15:04 -0400)]
hs-v3: Silence some logging for client authorization
If a tor client gets a descriptor that it can't decrypt, chances are that the
onion requires client authorization.
If a tor client is configured with client authorization for an onion but
decryption fails, it means that the configured keys aren't working anymore.
In both cases, we'll log notice the former and log warn the latter and the
rest of the decryption errors are now at info level.
Two logs statement have been removed because it was redundant and printing the
fetched descriptor in the logs when 80% of it is encrypted wat not helping.
Fixes #27550
Signed-off-by: David Goulet <dgoulet@torproject.org>
rust/protover: return C-allocated string in protover_all_supported()
The result of CString::into_raw() is not safe to free
with free() except under finicky and fragile circumstances
that we definitely don't meet right now.
David Goulet [Wed, 19 Sep 2018 14:56:15 +0000 (10:56 -0400)]
hs-v3: Close all SOCKS request on descriptor failure
Client side, when a descriptor is finally fetched and stored in the cache, we
then go over all pending SOCKS request for that descriptor. If it turns out
that the intro points are unusable, we close the first SOCKS request but not
the others for the same .onion.
This commit makes it that we'll close all SOCKS requests so we don't let
hanging the other ones.
It also fixes another bug which is having a SOCKS connection in RENDDESC_WAIT
state but with a descriptor in the cache. At some point, tor will expire the
intro failure cache which will make that descriptor usable again. When
retrying all SOCKS connection (retry_all_socks_conn_waiting_for_desc()), we
won't end up in the code path where we have already the descriptor for a
pending request causing a BUG().
Bottom line is that we should never have pending requests (waiting for a
descriptor) with that descriptor in the cache (even if unusable).
Fixees #27410.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Use the Travis Homebrew addon to install packages on macOS. The package
list is the same, but the Homebrew addon does not do a `brew update` by
default.
This makes builds faster, at the cost of using slightly older packages.
Nick Mathewson [Mon, 17 Sep 2018 15:36:59 +0000 (11:36 -0400)]
Make CacheDirectoryGroupReadable an autobool.
Since the default cache directory is the same as the default data
directory, we don't want the default CacheDirectoryGroupReadable
value (0) to override an explicitly set "DataDirectoryGroupReadable
1".
To fix this, I'm making CacheDirectoryGroupReadable into an
autobool, and having the default (auto) value mean "Use the value of
DataDirectoryGroupReadable if the directories are the same, and 0
otherwise."
Fixes bug 26913; bugfix on 0.3.3.1-alpha when the CacheDirectory
option was introduced.
David Goulet [Fri, 14 Sep 2018 14:56:34 +0000 (10:56 -0400)]
hs-v3: Don't BUG() on directory permission check failure
In hs_config.c, we do validate the permission of the hidden service directory
but we do not try to create it. So, in the event that the directory doesn't
exists, we end up in the loading key code path which checks for the
permission and possibly creates the directory. On failure, don't BUG() since
there is a perfectly valid use case for that function to fail.
Fixes #27335
Signed-off-by: David Goulet <dgoulet@torproject.org>
Nick Mathewson [Fri, 14 Sep 2018 15:39:37 +0000 (11:39 -0400)]
Revise our assertion and bug macros to work with -Wparentheses
On GCC and Clang, there's a feature to warn you about bad
conditionals like "if (a = b)", which should be "if (a == b)".
However, they don't warn you if there are extra parentheses around
"a = b".
Unfortunately, the tor_assert() macro and all of its kin have been
passing their inputs through stuff like PREDICT_UNLIKELY(expr) or
PREDICT_UNLIKELY(!(expr)), both of which expand to stuff with more
parentheses around "expr", thus suppressing these warnings.
To fix this, this patch introduces new macros that do not wrap
expr. They're only used when GCC or Clang is enabled (both define
__GNUC__), since they require GCC's "({statement expression})"
syntax extension. They're only used when we're building the
unit-test variant of the object files, since they suppress the
branch-prediction hints.
I've confirmed that tor_assert(), tor_assert_nonfatal(),
tor_assert_nonfatal_once(), BUG(), and IF_BUG_ONCE() all now give
compiler warnings when their argument is an assignment expression.
Fixes bug 27709.
Bugfix on 0.0.6, where we first introduced the "tor_assert()" macro.
projects / thirdparty / tor.git / log
