1. 15 Mar, 2017 9 commits
  2. 14 Mar, 2017 13 commits
  3. 13 Mar, 2017 11 commits
  4. 10 Mar, 2017 1 commit
  5. 09 Mar, 2017 4 commits
    • Nick Mathewson's avatar
      Merge branch 'bug21415_testfix_030' · 118d7018
      Nick Mathewson authored
    • George Kadianakis's avatar
      Fix failing bridges+ipv6-min integration test. · 6cab0f8a
      George Kadianakis authored and Nick Mathewson's avatar Nick Mathewson committed
      The bridges+ipv6-min integration test has a client with bridges:
          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 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 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 and [::1] bridges
      correspond to the same node_t, which I guess makes sense given that it's
      actually the same underlying bridge.
    • George Kadianakis's avatar
      Revert "Restore correct behavior of with bridges+ipv6-min" · 41324b5a
      George Kadianakis authored and Nick Mathewson's avatar Nick Mathewson committed
      This reverts commit 5298ab59.
    • Nick Mathewson's avatar
  6. 08 Mar, 2017 2 commits
    • Alexander Færøy's avatar
      Remove fgets() compatbility function and related tests. · 02fc0a5e
      Alexander 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 Færøy's avatar
      Use less-than instead of not-equal-to for comparison in read loops. · 02ef0651
      Alexander 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.