GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  1. 23 Feb, 2021 1 commit
  2. 03 Feb, 2021 8 commits
  3. 29 Jan, 2021 3 commits
  4. 28 Jan, 2021 7 commits
  5. 21 Jan, 2021 2 commits
  6. 19 Jan, 2021 2 commits
  7. 13 Jan, 2021 2 commits
    • David Goulet's avatar
      7a82fbfd
    • 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
      abort().
      
      Fixes bug 40241 again.  Bugfix on earlier fix for 40241, which was
      merged into maint-0.3.5 and forward, and released in 0.4.5.3-rc.
      fa8ecf88
  8. 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
      straight.
      
      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 #40237Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      04b02639
  9. 11 Jan, 2021 2 commits
  10. 17 Dec, 2020 1 commit
  11. 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 0.3.5.1-alpha.
      c4fe66e3
  12. 17 Nov, 2020 1 commit
  13. 12 Nov, 2020 1 commit
  14. 09 Nov, 2020 2 commits
  15. 05 Nov, 2020 1 commit
  16. 28 Oct, 2020 5 commits