GitLab

Alexander Færøy authored Mar 17, 2017 and Alexander Færøy committed Mar 17, 2017

This patch fixes a regression described in bug #21757 that first
appeared after commit 6e78ede7 which was an attempt to fix bug #21654.

When switching from buffered I/O to direct file descriptor I/O our
output strings from get_string_from_pipe() might contain newline
characters (\n). In this patch we modify tor_get_lines_from_handle() to
ensure that the function splits the newly read string at the newline
character and thus might return multiple lines from a single call to
get_string_from_pipe().

Additionally, we add a test case to test_util_string_from_pipe() to
ensure that get_string_from_pipe() correctly returns multiple lines in a
single call.

See: https://bugs.torproject.org/21757
See: https://bugs.torproject.org/21654

Windows doesn't let you check the socket error for a socket with
WSAGetLastError() and getsockopt(SO_ERROR).  But
getsockopt(SO_ERROR) clears the error on the socket, so you can't
call it more than once per error.

When we introduced recv_ni to help drain alert sockets, back in
0.2.6.3-alpha, we had the failure path for recv_ni call getsockopt()
twice, though: once to check for EINTR and one to check for EAGAIN.
Of course, we never got the eagain, so we treated it as an error,
and warned about: "No error".

The fix here is to have these functions return -errno on failure.

Fixes bug 21540; bugfix on 0.2.6.3-alpha.

Fixes bug 20059; bugfix on 0.1.0.1-rc.

The 64-bit load and store code was generating pretty bad output with
my compiler, so I extracted the code from csiphash and used that instead.

Close ticket 21737

Depends on 21594, part of 21622.

Depends on 21598, part of 21622.

Depends on 21594, part of 21622.

(Resolved merge conflict in static function declarations.

Patch from toralf; closes 21729.

Nothing big: just some const char[]s that should have been static,
and some integer truncation warnings.

Warnings not in any released Tor.

So we require that SMARTLIST_FOREACH_END() have the name of the loop
variable in it.  But right now the only enforcement for that is to
clear the variable at the end of the loop, which is really not
sufficient: I spent 45 minutes earlier today debugging an issue
where I had said:
   SMARTLIST_FOREACH_BEGIN(spool, spooled_resource_t *, spooled) {
     ...
   } SMARTLIST_FOREACH_END(spool);

This patch makes it so that ONLY loop variables can be used, by
referring to the _sl_idx variable.

People felt it could refer to the descriptor header section instead of
the plaintext of the superencrypted section.

- HS descriptors are now bigger than 10kb.
- encrypted_data_length_is_valid() is not that strict now.

[Consider starting review from desc_decrypt_all() ]

Also, relaxed the checks of encrypted_data_length_is_valid() since now
only one encrypted section has padding requirements and we don't
actually care to check that all the padding is there.

Consider starting code review from function encode_superencrypted_data().

- Refactor our HS desc crypto funcs to be able to differentiate between
  the superencrypted layer and the encrypted layer so that different
  crypto constants and padding is used in each layer.

- Introduce some string constants.

- Add some comments.

control-spec has marked it deprecated for a long time.

Closes ticket 21703.

The bridges+ipv6-min integration test has a client with bridges:
    Bridge 127.0.0.1:5003
    Bridge [::1]:5003
which got stuck in guard_selection_have_enough_dir_info_to_build_circuits()
because it couldn't find the descriptor of both bridges.

Specifically, the guard_has_descriptor() function could not find the
node_t of the [::1] bridge, because the [::1] bridge had no identity
digest assigned to it.

After further examination, it seems that during fetching the descriptor
for our bridges, we used the CERTS cell to fill the identity digest of
127.0.0.1:5003 properly. However, when we received a CERTS cell from
[::1]:5003 we actually ignored its identity digest because the
learned_router_identity() function was using
get_configured_bridge_by_addr_port_digest() which was returning the
127.0.0.1 bridge instead of the [::1] bridge (because it prioritizes
digest matching over addrport matching).

The fix replaces get_configured_bridge_by_addr_port_digest() with the
recent get_configured_bridge_by_exact_addr_port_digest() function. It
also relaxes the constraints of the
get_configured_bridge_by_exact_addr_port_digest() function by making it
return bridges whose identity digest is not yet known.

By using the _exact_() function, learned_router_identity() actually
fills in the identity digest of the [::1] bridge, which then allows
guard_has_descriptor() to find the right node_t and verify that the
descriptor is there.

FWIW, in the bridges+ipv6-min test both 127.0.0.1 and [::1] bridges
correspond to the same node_t, which I guess makes sense given that it's
actually the same underlying bridge.

This reverts commit 5298ab59.

This patch removes the `tor_fgets()` wrapper around `fgets(3)` since it
is no longer needed. The function was created due to inconsistency
between the returned values of `fgets(3)` on different versions of Unix
when using `fgets(3)` on non-blocking file descriptors, but with the
recent changes in bug #21654 we switch from unbuffered to direct I/O on
non-blocking file descriptors in our utility module.

We continue to use `fgets(3)` directly in the geoip and dirserv module
since this usage is considered safe.

This patch also removes the test-case that was created to detect
differences in the implementation of `fgets(3)` as well as the changes
file since these changes was not included in any releases yet.

See: https://bugs.torproject.org/21654