Nick Mathewson [Wed, 5 Jul 2017 20:10:45 +0000 (16:10 -0400)]
Only disable -Wfloat-conversion on mingw when it exists.
The 22081 fix disabled -Wfloat-conversion, but -Wfloat-conversion
didn't exist in every relevant mingw; it was added in GCC 4.9.x some
time, if the documentation can be trusted.
Nick Mathewson [Mon, 3 Jul 2017 14:59:31 +0000 (10:59 -0400)]
Fix -Wfloat-conversion C warnings on mingw in clamp_double_to_int64.
We just have to suppress these warnings: Mingw's math.h uses gcc's
__builtin_choose_expr() facility to declare isnan, isfinite, and
signbit. But as implemented in at least some versions of gcc,
__builtin_choose_expr() can generate type warnings even from
branches that are not taken.
Nick Mathewson [Thu, 29 Jun 2017 14:09:06 +0000 (10:09 -0400)]
Adjust unit tests to account for fix to bug 22753.
Our mock network put all the guards on the same IPv4 address, which
doesn't fly when we start applying EnforceDistinctSubnets. So in
this commit, I disable EnforceDistinctSubnets when running the old
guard_restriction_t test.
This commit also adds a regression test for #22753.
Nick Mathewson [Wed, 28 Jun 2017 15:41:50 +0000 (11:41 -0400)]
Consider the exit family when applying guard restrictions.
When the new path selection logic went into place, I accidentally
dropped the code that considered the _family_ of the exit node when
deciding if the guard was usable, and we didn't catch that during
code review.
This patch makes the guard_restriction_t code consider the exit
family as well, and adds some (hopefully redundant) checks for the
case where we lack a node_t for a guard but we have a bridge_info_t
for it.
Fixes bug 22753; bugfix on 0.3.0.1-alpha. Tracked as TROVE-2016-006
and CVE-2017-0377.
Nick Mathewson [Tue, 27 Jun 2017 14:45:29 +0000 (10:45 -0400)]
Fix an errant memset() into the middle of a struct in cell_pack().
This mistake causes two possible bugs. I believe they are both
harmless IRL.
BUG 1: memory stomping
When we call the memset, we are overwriting two 0 bytes past the end
of packed_cell_t.body. But I think that's harmless in practice,
because the definition of packed_cell_t is:
So we will overwrite either two bytes of inserted_time, or two bytes
of padding, depending on how the platform handles alignment.
If we're overwriting padding, that's safe.
If we are overwriting the inserted_time field, that's also safe: In
every case where we call cell_pack() from connection_or.c, we ignore
the inserted_time field. When we call cell_pack() from relay.c, we
don't set or use inserted_time until right after we have called
cell_pack(). SO I believe we're safe in that case too.
BUG 2: memory exposure
The original reason for this memset was to avoid the possibility of
accidentally leaking uninitialized ram to the network. Now
remember, if wide_circ_ids is false on a connection, we shouldn't
actually be sending more than 512 bytes of packed_cell_t.body, so
these two bytes can only leak to the network if there is another bug
somewhere else in the code that sends more data than is correct.
Fortunately, in relay.c, where we allocate packed_cell_t in
packed_cell_new() , we allocate it with tor_malloc_zero(), which
clears the RAM, right before we call cell_pack. So those
packed_cell_t.body bytes can't leak any information.
That leaves the two calls to cell_pack() in connection_or.c, which
use stack-alocated packed_cell_t instances.
In or_handshake_state_record_cell(), we pass the cell's contents to
crypto_digest_add_bytes(). When we do so, we get the number of
bytes to pass using the same setting of wide_circ_ids as we passed
to cell_pack(). So I believe that's safe.
In connection_or_write_cell_to_buf(), we also use the same setting
of wide_circ_ids in both calls. So I believe that's safe too.
Nick Mathewson [Tue, 20 Jun 2017 15:55:18 +0000 (11:55 -0400)]
If we successfully decompress an HTTP body, return immediately.
This prevents us from calling
allowed_anonymous_connection_compression_method() on the unused
guessed method (if any), and rejecting something that was already
safe to use.
Nick Mathewson [Tue, 20 Jun 2017 15:49:54 +0000 (11:49 -0400)]
If a _guessed_ compression method fails, it is never PROTOCOL_WARN.
Rationale: When use a guessed compression method, we already gave a
PROTOCOL_WARN when our guess differed from the declared method,
AND we gave a PROTOCOL_WARN when the declared method failed. It is
not a protocol problem that the guessed method failed too; it's just
a recovery attempt that failed.
Nick Mathewson [Tue, 20 Jun 2017 15:26:51 +0000 (11:26 -0400)]
Send the correct content-encoding when serving cached_dir_t objects
A cached_dir_t object (for now) is always compressed with
DEFLATE_METHOD, but in handle_get_status_vote() to we were using the
general compression-negotiation code decide what compression to
claim we were using.
projects / thirdparty / tor.git / log
