1. 06 May, 2020 2 commits
    • Nick Mathewson's avatar
      Use __attribute__((fallthrough)) rather than magic GCC comments. · 28ac17f4
      Nick Mathewson authored
      GCC added an implicit-fallthrough warning a while back, where it
      would complain if you had a nontrivial "case:" block that didn't end
      with break, return, or something like that.  Clang recently added
      the same thing.
      
      GCC, however, would let you annotate a fall-through as intended by
      any of various magic "/* fall through */" comments.  Clang, however,
      only seems to like "__attribute__((fallthrough))".  Fortunately, GCC
      accepts that too.
      
      A previous commit in this branch defined a FALLTHROUGH macro to do
      the right thing if GNUC is defined; here we replace all of our "fall
      through" comments with uses of that macro.
      
      This is an automated commit, made with the following perl one-liner:
      
        #!/usr/bin/perl -i -p
        s#/\* *falls? ?thr.*?\*/#FALLTHROUGH;#i;
      
      (In order to avoid conflicts, I'm applying this script separately to
      each maint branch. This is the 0.4.2 version.)
      28ac17f4
    • Nick Mathewson's avatar
      Use __attribute__((fallthrough)) rather than magic GCC comments. · 79ff2b6a
      Nick Mathewson authored
      GCC added an implicit-fallthrough warning a while back, where it
      would complain if you had a nontrivial "case:" block that didn't end
      with break, return, or something like that.  Clang recently added
      the same thing.
      
      GCC, however, would let you annotate a fall-through as intended by
      any of various magic "/* fall through */" comments.  Clang, however,
      only seems to like "__attribute__((fallthrough))".  Fortunately, GCC
      accepts that too.
      
      A previous commit in this branch defined a FALLTHROUGH macro to do
      the right thing if GNUC is defined; here we replace all of our "fall
      through" comments with uses of that macro.
      
      This is an automated commit, made with the following perl one-liner:
      
        #!/usr/bin/perl -i -p
        s#/\* *falls? ?thr.*?\*/#FALLTHROUGH;#i;
      
      (In order to avoid conflicts, I'm applying this script separately to
      each maint branch. This is the 0.4.1 version.)
      79ff2b6a
  2. 05 Sep, 2019 1 commit
  3. 11 Jun, 2019 1 commit
  4. 03 Jun, 2019 1 commit
  5. 22 May, 2019 7 commits
    • David Goulet's avatar
      sendme: Add non fatal asserts for extra safety · 0cad83be
      David Goulet authored and Nick Mathewson's avatar Nick Mathewson committed
      
      
      Two non fatal asserts are added in this commit. First one is to see if the
      SENDME digest list kept on the circuit for validation ever grows bigger than
      the maximum number of expected SENDME on a circuit (currently 10).
      
      The second one is to know if we ever send more than one SENDME at a time on a
      circuit. In theory, we shouldn't but if we ever do, the v1 implementation
      wouldn't work because we only keep one single cell digest (the previous cell
      to the SENDME) on the circuit/cpath. Thus, sending two SENDME consecutively
      will lead to a mismatch on the other side because the same cell digest would
      be use and thus the circuit would collapse.
      
      Finally, add an extra debug log in case we emit a v0 which also includes the
      consensus emit version in that case.
      
      Part of #30428
      
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      0cad83be
    • David Goulet's avatar
      sendme: Always pop last SENDME digest from circuit · 5479ffab
      David Goulet authored and Nick Mathewson's avatar Nick Mathewson committed
      
      
      We must not accumulate digests on the circuit if the other end point is using
      another SENDME version that is not using those digests like v0.
      
      This commit makes it that we always pop the digest regardless of the version.
      
      Part of #30428
      
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      5479ffab
    • David Goulet's avatar
      sendme: Clarify how sendme_circuit_cell_is_next() works · 482c4972
      David Goulet authored and Nick Mathewson's avatar Nick Mathewson committed
      
      
      Commit 4ef8470fa5480d3b was actually reverted before because in the end we
      needed to do this minus 1 check on the window.
      
      This commit clarifies that in the code, takes the useful comment changes from
      4ef8470fa5480d3b and makes sendme_circuit_cell_is_next() private since it
      behaves in a very specific way that one external caller might expect.
      
      Part of #30428.
      
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      482c4972
    • David Goulet's avatar
      sendme: Properly record SENDMEs on both edges · 3835a3ac
      David Goulet authored and Nick Mathewson's avatar Nick Mathewson committed
      
      
      Turns out that we were only recording the "b_digest" but to have
      bidirectionnal authenticated SENDMEs, we need to use the "f_digest" in the
      forward cell situation.
      
      Because of the cpath refactoring, this commit plays with the crypt_path_ and
      relay_crypto_t API a little bit in order to respect the abstractions.
      
      Previously, we would record the cell digest as the SENDME digest in the
      decrypt cell function but to avoid code duplication (both directions needs to
      record), we now do that right after iff the cell is recognized (at the edge).
      It is now done in circuit_receive_relay_cell() instead.
      
      We now also record the cell digest as the SENDME digest in both relay cell
      encryption functions since they are split depending on the direction.
      relay_encrypt_cell_outbound() and relay_encrypt_cell_inbound() need to
      consider recording the cell digest depending on their direction (f vs b
      digest).
      
      Fixes #30428
      
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      3835a3ac
    • David Goulet's avatar
      sendme: Never fallback to v0 if unknown version · 44265dd6
      David Goulet authored and Nick Mathewson's avatar Nick Mathewson committed
      
      
      There was a missing cell version check against our max supported version. In
      other words, we do not fallback to v0 anymore in case we do know the SENDME
      version.
      
      We can either handle it or not, never fallback to the unauthenticated version
      in order to avoid gaming the authenticated logic.
      
      Add a unit tests making sure we properly test that and also test that we can
      always handle the default emit and accepted versions.
      
      Fixes #30428
      
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      44265dd6
    • David Goulet's avatar
      sendme: Validate v1 SENDMEs on both client and exit side · 69e0d5bf
      David Goulet authored and Nick Mathewson's avatar Nick Mathewson committed
      
      
      The validation of the SENDME cell is now done as the very first thing when
      receiving it for both client and exit. On failure to validate, the circuit is
      closed as detailed in the specification.
      
      Part of #30428
      
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      69e0d5bf
    • David Goulet's avatar
      sendme: Record cell digest on both client and exit · 59b9eecc
      David Goulet authored and Nick Mathewson's avatar Nick Mathewson committed
      
      
      It turns out that only the exit side is validating the authenticated SENDME v1
      logic and never the client side. Which means that if a client ever uploaded
      data towards an exit, the authenticated SENDME logic wouldn't apply.
      
      For this to work, we have to record the cell digest client side as well which
      introduced a new function that supports both type of edges.
      
      This also removes a test that is not valid anymore which was that we didn't
      allow cell recording on an origin circuit (client).
      
      Part of #30428
      
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      59b9eecc
  6. 16 May, 2019 1 commit
  7. 13 May, 2019 1 commit
    • David Goulet's avatar
      sendme: Fix coverity CID 1444999 · def96ce8
      David Goulet authored
      
      
      The code flow in theory can end up with a layer_hint to be NULL but in
      practice it should never happen because with an origin circuit, we must have
      the layer_hint.
      
      Just in case, BUG() on it if we ever end up in this situation and recover by
      closing the circuit.
      
      Fixes #30467.
      
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      def96ce8
  8. 03 May, 2019 1 commit
  9. 02 May, 2019 1 commit
  10. 29 Apr, 2019 21 commits