- Mar 15, 2017
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
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.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
Fixes bug 20059; bugfix on 0.1.0.1-rc.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
- Mar 14, 2017
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
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
-
Nick Mathewson authored
-
-
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.
-
Nick Mathewson authored
Patch from toralf; closes 21729.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
Nothing big: just some const char[]s that should have been static, and some integer truncation warnings. Warnings not in any released Tor.
-
- Mar 13, 2017
-
-
Nick Mathewson authored
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.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
George Kadianakis authored
People felt it could refer to the descriptor header section instead of the plaintext of the superencrypted section.
-
George Kadianakis authored
-
George Kadianakis authored
-
George Kadianakis authored
- HS descriptors are now bigger than 10kb. - encrypted_data_length_is_valid() is not that strict now.
-
George Kadianakis authored
[Consider starting review from desc_decrypt_all() ]
-
George Kadianakis authored
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().
-
George Kadianakis authored
- 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.
-
- Mar 10, 2017
-
-
Nick Mathewson authored
control-spec has marked it deprecated for a long time. Closes ticket 21703.
-
- Mar 09, 2017
-
-
Nick Mathewson authored
-
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.
-
Nick Mathewson authored
-
- Mar 08, 2017
-
-
Alexander Hansen Færøy authored
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
-
Alexander Hansen Færøy authored
This patch changes a number of read loops in the util module to use less-than comparison instead of not-equal-to comparison. We do this in the case that we have a bug elsewhere that might cause `numread` to become larger than `count` and thus become an infinite loop.
-