1. 03 Feb, 2021 8 commits
  2. 29 Jan, 2021 3 commits
  3. 28 Jan, 2021 7 commits
  4. 21 Jan, 2021 2 commits
  5. 19 Jan, 2021 2 commits
  6. 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
  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 2 commits
  9. 17 Dec, 2020 1 commit
  10. 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
  11. 17 Nov, 2020 1 commit
  12. 12 Nov, 2020 1 commit
  13. 09 Nov, 2020 2 commits
  14. 05 Nov, 2020 1 commit
  15. 28 Oct, 2020 5 commits
  16. 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.