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. 14 Apr, 2021 1 commit
  3. 13 Apr, 2021 2 commits
  4. 16 Mar, 2021 1 commit
  5. 15 Mar, 2021 3 commits
  6. 12 Mar, 2021 1 commit
  7. 23 Feb, 2021 1 commit
  8. 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
  9. 03 Feb, 2021 6 commits
  10. 29 Jan, 2021 3 commits
  11. 28 Jan, 2021 1 commit
  12. 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
  13. 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>
  14. 11 Jan, 2021 1 commit
  15. 17 Dec, 2020 1 commit
  16. 14 Dec, 2020 1 commit
    • Nick Mathewson's avatar
      Socks5: handle truncated client requests correctly · c4fe66e3
      Nick Mathewson authored
      Previously, our code would send back an error if the socks5 request
      parser said anything but DONE.  But there are other non-error cases,
      like TRUNCATED: we shouldn't send back errors for them.
      This patch lowers the responsibility for setting the error message
      into the parsing code, since the actual type of the error message
      will depend on what problem was encountered.
      Fixes bug 40190; bugfix on
  17. 12 Nov, 2020 1 commit
  18. 09 Nov, 2020 1 commit
  19. 05 Nov, 2020 1 commit
  20. 28 Oct, 2020 3 commits
  21. 14 Oct, 2020 1 commit
    • Nick Mathewson's avatar
      Implement proposal 318: Limit protovers to 0..63 · dd63b972
      Nick Mathewson authored
      In brief: we go through a lot of gymnastics to handle huge protover
      numbers, but after years of development we're not even close to 10
      for any of our current versions.  We also have a convenient
      workaround available in case we ever run out of protocols: if (for
      example) we someday need Link=64, we can just add Link2=0 or
      This patch is a minimal patch to change tor's behavior; it doesn't
      take advantage of the new restrictions.
      Implements #40133 and proposal 318.
  22. 07 Oct, 2020 2 commits
    • David Goulet's avatar
      hs-v2: Add deprecation warning for service · b404f085
      David Goulet authored and Nick Mathewson's avatar Nick Mathewson committed
      If at least one service is configured as a version 2, a log warning is emitted
      once and only once.
      Closes #40003
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
    • Nick Mathewson's avatar
      Parallelize src/test/test into chunks. · c5ba8b62
      Nick Mathewson authored
      First, we introduce a flag to teach src/test/test to split its work
      into chunks.  Then we replace our invocation of src/test/test in our
      "make check" target with a set of 8 scripts that invoke the first
      8th of the tests, the second 8th, and so on.
      This change makes our "make -kj4 check" target in our hardened
      gitlab build more than twice as fast, since src/test/test was taking
      the longest to finish.
      Closes 40098.
  23. 22 Sep, 2020 1 commit
  24. 17 Sep, 2020 2 commits
  25. 14 Sep, 2020 1 commit
  26. 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.