1. 27 Oct, 2020 5 commits
  2. 01 Oct, 2020 1 commit
  3. 17 Sep, 2020 2 commits
    • Nick Mathewson's avatar
      Fix wide lines · 22643272
      Nick Mathewson authored
    • Nick Mathewson's avatar
      Rename tor_cert_create to tor_cert_create_ed25519 · c92e1926
      Nick Mathewson authored
      This is an automated commit, generated by this command:
      ./scripts/maint/rename_c_identifier.py \
              tor_cert_create tor_cert_create_ed25519
      It was generated with --no-verify, so it probably breaks some commit hooks.
      The commiter should be sure to fix them up in a subsequent commit.
  4. 20 Aug, 2020 1 commit
  5. 19 Aug, 2020 1 commit
    • David Goulet's avatar
      hs: Don't overwrite DoS parameters on circuit with consensus params · f5c9f6d4
      David Goulet authored
      Turns out that the HS DoS defenses parameters were overwritten by the
      consensus parameters everytime a new consensus would arrive.
      This means that a service operator can still enable the defenses but as soon
      as the intro point relay would get a new consensus, they would be overwritten.
      And at this commit, the network is entirely disabling DoS defenses.
      Fix this by introducing an "explicit" flag that indicate if the
      ESTABLISH_INTRO cell DoS extension set those parameters or not. If set, avoid
      using the consenus at once.
      We are not bumping the protover HSIntro value for this because 0.4.2.x series
      is EOL in 1 month and thus 0.4.3.x would be the only series with this bug. We
      are confident that a backport and then upgrade path to the latest 0.4.4.x
      stable coming up soon is enough to mitigate this problem in the coming months.
      It avoids the upgrade path on the service side by keeping the requirement for
      protover HSIntro=5.
      Fixes #40109
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
  6. 11 Aug, 2020 1 commit
  7. 05 Aug, 2020 1 commit
    • Nick Mathewson's avatar
      Replace several C identifiers for ticket 18106. · b417594d
      Nick Mathewson authored
      We used to have a single boolean, "FascistFirewall".  Ages ago, in
      tickets #17840 and #9067, we added an improved "ReachableAddresses"
      mechanism.  It's time to rename related identifiers in the code for
      consistency.  This closes #18106.
      This is an automated commit, generated by this command:
      ./scripts/maint/rename_c_identifier.py \
              fascist_firewall_allows_address reachable_addr_allows \
              fascist_firewall_use_ipv6 reachable_addr_use_ipv6 \
              fascist_firewall_prefer_ipv6_impl reachable_addr_prefer_ipv6_impl \
              fascist_firewall_prefer_ipv6_orport reachable_addr_prefer_ipv6_orport \
              fascist_firewall_prefer_ipv6_dirport reachable_addr_prefer_ipv6_dirport \
              fascist_firewall_allows_address_addr reachable_addr_allows_addr \
              fascist_firewall_allows_address_ap reachable_addr_allows_ap \
              fascist_firewall_allows_base reachable_addr_allows_base \
              fascist_firewall_allows_ri_impl reachable_addr_allows_ri_impl \
              fascist_firewall_allows_rs_impl reachable_addr_allows_rs_impl \
              fascist_firewall_allows_rs reachable_addr_allows_rs \
              fascist_firewall_allows_md_impl reachable_addr_allows_md_impl \
              fascist_firewall_allows_node reachable_addr_allows_node \
              fascist_firewall_allows_dir_server reachable_addr_allows_dir_server \
              fascist_firewall_choose_address_impl reachable_addr_choose_impl \
              fascist_firewall_choose_address reachable_addr_choose \
              fascist_firewall_choose_address_base reachable_addr_choose_base \
              fascist_firewall_choose_address_rs reachable_addr_choose_from_rs \
              fascist_firewall_choose_address_ls reachable_addr_choose_from_ls \
              fascist_firewall_choose_address_node reachable_addr_choose_from_node \
              fascist_firewall_choose_address_dir_server reachable_addr_choose_from_dir_server
  8. 30 Jul, 2020 1 commit
  9. 16 Jul, 2020 1 commit
  10. 14 Jul, 2020 1 commit
  11. 09 Jul, 2020 3 commits
  12. 07 Jul, 2020 1 commit
  13. 02 Jul, 2020 1 commit
  14. 06 Jun, 2020 1 commit
  15. 28 May, 2020 1 commit
  16. 27 May, 2020 1 commit
  17. 21 May, 2020 1 commit
    • George Kadianakis's avatar
      Fix an enum comparison that was blowing up jenkins. · baee2fed
      George Kadianakis authored
      The warning was:
          11:23:10 ../tor/src/feature/hs/hs_service.c: In function 'log_cant_upload_desc':
          11:23:10 ../tor/src/feature/hs/hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
      See #34254 for more info.
      I guess this means that gcc assigned an unsigned type to the
      `log_desc_upload_reason_t` enum and it warned if we compared it against 0...
      For now I think it's simpler to remove that check instead of turning the enum
      to a signed type, or trying to hack it some other way.
      From what it seems, enum is up to the compiler on whether it's signed/unsigned:
  18. 06 May, 2020 1 commit
  19. 01 May, 2020 1 commit
    • Nick Mathewson's avatar
      Fix a GCC 10.0.1 compilation error. · b1c383e3
      Nick Mathewson authored
      Do not try to stuff "HS_DESC_DECODE_GENERIC_ERROR" (-1) into a
      socks5_reply_status_t (enum).  It doesn't actually make sense, and
      isn't one of our documented extensions.
      (This can only happen on a nonfatal assertion that we haven't seen,
      so it probably isn't happening in practice.)
      Fixes another case of bug 34077; bugfix on
  20. 29 Apr, 2020 1 commit
  21. 13 Apr, 2020 2 commits
    • George Kadianakis's avatar
      hs-v3: Change all-zeroes hard-assert to a BUG-and-err. · f2f718bc
      George Kadianakis authored and Nick Mathewson's avatar Nick Mathewson committed
      And also disallow all-zeroes keys from the filesystem; add a test for it too.
    • George Kadianakis's avatar
      hs-v3: Don't allow registration of an all-zeroes client auth key. · 37bcc9f3
      George Kadianakis authored and Nick Mathewson's avatar Nick Mathewson committed
      The client auth protocol allows attacker-controlled x25519 private keys being
      passed around, which allows an attacker to potentially trigger the all-zeroes
      assert for client_auth_sk in hs_descriptor.c:decrypt_descriptor_cookie().
      We fixed that by making sure that an all-zeroes client auth key will not be
      There are no guidelines for validating x25519 private keys, and the assert was
      there as a sanity check for code flow issues (we don't want to enter that
      function with an unitialized key if client auth is being used). To avoid such
      crashes in the future, we also changed the assert to a BUG-and-err.
  22. 09 Apr, 2020 1 commit
  23. 08 Apr, 2020 4 commits
  24. 07 Apr, 2020 1 commit
  25. 01 Apr, 2020 1 commit
  26. 30 Mar, 2020 4 commits