1. 13 Apr, 2021 2 commits
  2. 16 Mar, 2021 1 commit
  3. 15 Mar, 2021 5 commits
  4. 12 Mar, 2021 4 commits
  5. 23 Feb, 2021 1 commit
  6. 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
  7. 03 Feb, 2021 8 commits
  8. 29 Jan, 2021 3 commits
  9. 28 Jan, 2021 7 commits
  10. 21 Jan, 2021 2 commits
  11. 19 Jan, 2021 2 commits
  12. 13 Jan, 2021 2 commits
    • David Goulet's avatar
    • 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