1. 16 Apr, 2021 1 commit
    • Nick Mathewson's avatar
      Stop calling evdns_set_random_bytes_fn() · f20f5a4e
      Nick Mathewson authored
      This function has been a no-op since Libevent 2.0.4-alpha, when
      libevent got an arc4random() implementation.  Libevent has finally
      removed it, which will break our compilation unless we stop calling
      it.  (This is currently breaking compilation in OSS-fuzz.)
      Closes #40371.
  2. 15 Mar, 2021 2 commits
  3. 19 Feb, 2021 1 commit
    • Nick Mathewson's avatar
      Disable the dump_desc() function. · ede88c37
      Nick Mathewson authored
      It can be called with strings that should have been
      length-delimited, but which in fact are not.  This can cause a
      CPU-DoS bug or, in a worse case, a crash.
      Since this function isn't essential, the best solution for older
      Tors is to just turn it off.
      Fixes bug 40286; bugfix on when dump_desc() was
  4. 03 Feb, 2021 2 commits
  5. 29 Jan, 2021 2 commits
  6. 13 Jan, 2021 1 commit
    • Nick Mathewson's avatar
      Better fix for #40241 (--enable-all-bugs-are-fatal and fallthrough) · fa8ecf88
      Nick Mathewson authored
      This one should work on GCC _and_ on Clang.  The previous version
      made Clang happier by not having unreachable "fallthrough"
      statements, but made GCC sad because GCC didn't think that the
      unconditional failures were really unconditional, and therefore
      _wanted_ a FALLTHROUGH.
      This patch adds a FALLTHROUGH_UNLESS_ALL_BUGS_ARE_FATAL macro that
      seems to please both GCC and Clang in this case: ordinarily it is a
      FALLTHROUGH, but when ALL_BUGS_ARE_FATAL is defined, it's an
      Fixes bug 40241 again.  Bugfix on earlier fix for 40241, which was
      merged into maint-0.3.5 and forward, and released in
  7. 12 Jan, 2021 1 commit
    • David Goulet's avatar
      hs-v3: Require reasonably live consensus · 04b02639
      David Goulet authored
      Some days before this commit, the network experienced a DDoS on the directory
      authorities that prevented them to generate a consensus for more than 5 hours
      That in turn entirely disabled onion service v3, client and service side, due
      to the subsystem requiring a live consensus to function properly.
      We know require a reasonably live consensus which means that the HSv3
      subsystem will to its job for using the best consensus tor can find. If the
      entire network is using an old consensus, than this should be alright.
      If the service happens to use a live consensus while a client is not, it
      should still work because the client will use the current SRV it sees which
      might be the previous SRV for the service for which it still publish
      descriptors for.
      If the service is using an old one and somehow can't get a new one while
      clients are on a new one, then reachability issues might arise. However, this
      is a situation we already have at the moment since the service will simply not
      work if it doesn't have a live consensus while a client has one.
      Fixes #40237
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
  8. 11 Jan, 2021 1 commit
  9. 07 Oct, 2020 1 commit
  10. 22 Sep, 2020 1 commit
  11. 07 Sep, 2020 1 commit
    • George Kadianakis's avatar
      statistics: Properly count all rendezvous cells (avoid undercounting). · 248cbc2d
      George Kadianakis authored
      tl;dr We were not counting cells flying from the client to the service, but we
      were counting cells flying from the service to the client.
      When a rendezvous cell arrives from the client to the RP, the RP forwards it to
      the service.
      For this to happen, the cell first passes through command_process_relay_cell()
      which normally does the statistics counting. However because the `rend_circ`
      circuit was not flagged with `circuit_carries_hs_traffic_stats` in
      rend_mid_rendezvous(), the cell is not counted there.
      Then the cell goes to circuit_receive_relay_cell() which has a special code
      block based on `rend_splice` specifically for rendezvous cells, and the cell
      gets directly passed to `rend_circ` via a direct call to
      circuit_receive_relay_cell(). The cell never passes through
      command_process_relay_cell() ever again and hence is never counted by our
      rephist module.
      The fix here is to flag the `rend_circ` circuit with
      `circuit_carries_hs_traffic_stats` so that the cell is counted as soon as it
      hits command_process_relay_cell().
      Furthermore we avoid double-counting cells since the special code block of
      circuit_receive_relay_cell() makes us count rendezvous cells only as they enter
      the RP and not as they exit it.
      Fixes #40117.
  12. 10 Aug, 2020 1 commit
  13. 22 Jul, 2020 1 commit
  14. 30 Jun, 2020 1 commit
  15. 30 May, 2020 1 commit
    • Roger Dingledine's avatar
      Preemptive circs should work with UseEntryGuards 0 · 39f2411b
      Roger Dingledine authored
      Resume being willing to use preemptively-built circuits when
      UseEntryGuards is set to 0. We accidentally disabled this feature with
      that config setting (in our fix for #24469), leading to slower load times.
      Fixes bug 34303; bugfix on
  16. 06 May, 2020 3 commits
  17. 20 Mar, 2020 2 commits
    • teor's avatar
      router: Refactor IPv6 ORPort function logic · bac8bc0f
      teor authored
      Return early when there is no suitable IPv6 ORPort.
      Show the address and port on error, using a convenience function.
      Code simplification and refactoring.
      Cleanup after 32588.
    • teor's avatar
      router: Stop advertising incorrect auto IPv6 ORPorts · 861337fd
      teor authored
      When IPv6 ORPorts are set to "auto", tor relays and bridges would
      advertise an incorrect port in their descriptor.
      This may be a low-severity memory safety issue, because the published
      port number may be derived from uninitialised or out-of-bounds memory
      Fixes bug 32588; bugfix on
  18. 17 Mar, 2020 2 commits
    • George Kadianakis's avatar
      Fix TROVE-2020-003. · 089e57d2
      George Kadianakis authored and Nick Mathewson's avatar Nick Mathewson committed
      Given that ed25519 public key validity checks are usually not needed
      and (so far) they are only necessary for onion addesses in the Tor
      protocol, we decided to fix this specific bug instance without
      modifying the rest of the codebase (see below for other fix
      In our minimal fix we check that the pubkey in
      hs_service_add_ephemeral() is valid and error out otherwise.
    • George Kadianakis's avatar
      Trivial bugfixes found during TROVE investigation. · c940b7cf
      George Kadianakis authored and Nick Mathewson's avatar Nick Mathewson committed
  19. 12 Feb, 2020 2 commits
  20. 05 Feb, 2020 2 commits
  21. 14 Jan, 2020 1 commit
    • Nick Mathewson's avatar
      Replace an assertion with a check-and-log · 165a92e3
      Nick Mathewson authored
      We hit this assertion with bug 32868, but I'm stymied figuring out
      how we wound up with a routerstatus like this.  This patch is a
      diagnostic to attempt to figure out what is going on, and to avoid a
      crash in the meantime.
  22. 24 Oct, 2019 1 commit
    • David Goulet's avatar
      hs-v3: Remove a BUG() caused by an acceptable race · ed57a04a
      David Goulet authored
      hs_client_purge_state() and hs_cache_clean_as_client() can remove a descriptor
      from the client cache with a NEWNYM or simply when the descriptor expires.
      Which means that for an INTRO circuit being established during that time, once
      it opens, we lookup the descriptor to get the IP object but hey surprised, no
      more descriptor.
      The approach here is minimalist that is accept the race and close the circuit
      since we can not continue. Before that, the circuit would stay opened and the
      client wait the SockTimeout.
      Fixers #28970.
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
  23. 07 Oct, 2019 1 commit
    • David Goulet's avatar
      hs-v3: Make service pick the exact amount of intro points · 984a28f3
      David Goulet authored and Nick Mathewson's avatar Nick Mathewson committed
      When encoding introduction points, we were not checking if that intro points
      had an established circuit.
      When botting up, the service will pick, by default, 3 + 2 intro points and the
      first 3 that establish, we use them and upload the descriptor.
      However, the intro point is removed from the service descriptor list only when
      the circuit has opened and we see that we have already enough intro points, it
      is then removed.
      But it is possible that the service establishes 3 intro points successfully
      before the other(s) have even opened yet.
      This lead to the service encoding extra intro points in the descriptor even
      though the circuit is not opened or might never establish (#31561).
      Fixes #31548
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
  24. 18 Sep, 2019 2 commits
  25. 06 Sep, 2019 1 commit
  26. 02 Sep, 2019 1 commit
  27. 23 Aug, 2019 3 commits
  28. 19 Jul, 2019 1 commit
    • Nick Mathewson's avatar
      Set 'routerlist' global to NULL before freeing it. · a9379d67
      Nick Mathewson authored
      There is other code that uses this value, and some of it is
      apparently reachable from inside router_dir_info_changed(), which
      routerlist_free() apparently calls.  (ouch!)  This is a minimal fix
      to try to resolve the issue without causing other problems.
      Fixes bug 31003. I'm calling this a bugfix on, where
      the call to router_dir_info_changed() was added to routerlist_free().