1. 07 May, 2021 2 commits
  2. 21 Apr, 2021 1 commit
  3. 19 Apr, 2021 2 commits
  4. 13 Apr, 2021 2 commits
  5. 08 Apr, 2021 1 commit
    • David Goulet's avatar
      guard: Don't check bridge transport name when selecting eligible guards · 218f9f90
      David Goulet authored
      This is related to ticket #40360 which found this problem when a Bridge entry
      with a transport name (let say obfs4) is set without a fingerprint:
        Bridge obfs4 <IP>:<PORT> cert=<...> iat-mode=0
      (Notice, no fingerprint between PORT and "cert=")
      Problem: commit 09c6d032 added a check in
      get_sampled_guard_for_bridge() that would return NULL if the selected bridge
      did not have a valid transport name (that is the Bridge transport name that
      corresponds to a ClientTransportPlugin).
      Unfortuantely, this function is also used when selecting our eligible guards
      which is done *before* the transport list is populated and so the added check
      for the bridge<->transport name is querying an empty list of transports
      resulting in always returning NULL.
      For completion, the logic is: Pick eligible guards (use bridge(s) if need be)
      then for those, initiate a connection to the pluggable transport proxy and
      then populate the transport list once we've connected.
      Back to get_sampled_guard_for_bridge(). As said earlier, it is used when
      selecting our eligible guards in a way that prevents us from selecting
      duplicates. In other words, if that function returns non-NULL, the selection
      continues considering the bridge was sampled before. But if it returns NULL,
      the relay is added to the eligible list.
      This bug made it that our eligible guard list was populated with the *same*
      bridge 3 times like so (remember no fingerprint):
        [info] entry_guards_update_primary(): Primary entry guards have changed. New primary guard list is:
        [info] entry_guards_update_primary():   1/3: [bridge] ($0000000000000000000000000000000000000000)
        [info] entry_guards_update_primary():   2/3: [bridge] ($0000000000000000000000000000000000000000)
        [info] entry_guards_update_primary():   3/3: [bridge] ($0000000000000000000000000000000000000000)
      When tor starts, it will find the bridge fingerprint by connecting to it and
      will then update the primary guard list by calling
      entry_guard_learned_bridge_identity() which then goes and update only 1 single
      entry resulting in this list:
        [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($<FINGERPRINT>) is still listed.
        [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed.
        [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed.
      And here lies the problem, now tor is stuck attempting to wait for a valid
      descriptor for at least 2 guards where the second one is a bunch of zeroes and
      thus tor will never fully bootstraps:
        [info] I learned some more directory information, but not enough to build a
        circuit: We're missing descriptors for 1/2 of our primary entry guards
        (total microdescriptors: 6671/6703). That's ok. We will try to fetch missing
        descriptors soon.
      Now, why passing the fingerprint then works? This is because the list of
      guards contains 3 times the same bridge but they all have a fingerprint and so
      the descriptor can be found and tor can bootstraps.
      The solution here is to entirely remove the transport name check in
      get_sampled_guard_for_bridge() since the transport_list is empty at that
      point. That way, the eligible guard list only gets 1 entry, the bridge, and
      can then go on to bootstrap properly.
      It is OK to do so since when launching a bridge descriptor fetch, we validate
      that the bridge transport name is OK and thus avoid connecting to a bridge
      without a ClientTransportPlugin. If we wanted to keep the check in place, we
      would need to populate the transport_list much earlier and this would require
      a much bigger refactoring.
      Fixes #40360
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
  6. 07 Apr, 2021 1 commit
    • Nick Mathewson's avatar
      Try making our configure.ac script build with AC 2.70. · 02816d60
      Nick Mathewson authored
      In versions <=2.69, according to the autoconf docs, AC_PROG_CC_C99
      is needed with some compilers, if they require extra arguments to
      build C99 programs.  In versions >=2.70, AC_PROG_CC checks for these
      compilers automatically, and so the AC_PROG_CC_C99 macro is
      So, what can you do if you want your script to work right with both
      autoconf versions?  IIUC, neither including AC_PROG_CC_C99 macro nor
      leaving it out will give you the right behavior with both versions.
      It looks like you need to look at the autoconf version explicitly.
      (Now, the autoconf manual implies that it's "against autoconf
      philosophy" to look at the autoconf version rather than trying the
      behavior to see if it works, but they don't actually tell you how to
      detect recoverably at autoconf-time whether a macro is obsolete or
      not, and I can't find a way to do that.)
      So, is it safe to use m4_version_prereq, like I do here?  It isn't
      listed in the autoconf 2.63 manual (which is the oldest version we
      support).  But a mailing list message [1] (which added the
      documentation back in 2008) implies that m4_version_prereq has been
      there since "at least back to autoconf 2.59".
      So I think this will work.
      I am basing this patch against Tor 0.3.5 since, if autoconf 2.70
      becomes widespread before 0.3.5 is unsupported, we might need this
      patch to continue 0.3.5 development.  But I don't think we should
      backport farther than 0.4.5 until/unless that actually happens.
      This is part of a fix for #40355.
  7. 26 Mar, 2021 1 commit
    • Jigsaw52's avatar
      Fix glob processing on BSD systems. #40318 · 36768b57
      Jigsaw52 authored
      On Linux systems, glob automatically ignores the errors ENOENT and
      ENOTDIR because they are expected during glob expansion. But BSD
      systems do not ignore these, resulting in glob failing when globs
      expand to invalid paths. This is fixed by adding a custom error
      handler that ignores only these two errors and removing the
      GLOB_ERR flag as it makes glob fail even if the error handler
      ignores the error and is unnecessary as the error handler will
      make glob fail on all other errors anyway.
  8. 23 Mar, 2021 1 commit
  9. 15 Mar, 2021 3 commits
  10. 12 Mar, 2021 3 commits
  11. 10 Mar, 2021 1 commit
  12. 08 Mar, 2021 2 commits
  13. 03 Mar, 2021 1 commit
  14. 23 Feb, 2021 3 commits
    • David Goulet's avatar
      Remove mallinfo() from codebase · ad4f87ed
      David Goulet authored
      Now deprecated in libc >= 2.33
      Closes #40309
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
    • David Goulet's avatar
      Remove mallinfo() from codebase · 296a557b
      David Goulet authored
      Now deprecated in libc >= 2.33
      Closes #40309
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
    • David Goulet's avatar
      relay: Avoid a directory early fetch · 39d0f69d
      David Goulet authored
      The directory_fetches_from_authorities() is used to know if a client or relay
      should fetch data from an authority early in the boot process.
      We had a condition in that function that made a relay trigger that fetch if it
      didn't know its address (so we can learn it). However, when this is called,
      the address discovery has not been done yet so it would always return true for
      a relay.
      Furthermore, it would always trigger a log notice that the IPv4 couldn't be
      found which was inevitable because the address discovery process has not been
      done yet (done when building our first descriptor).
      It is also important to point out that starting in, asking an
      authority for an address is done during address discovery time using a one-hop
      circuit thus independent from the relay deciding to fetch or not documents
      from an authority.
      Small fix also is to reverse the "IPv(4|6)Only" flag in the notice so that if
      we can't find IPv6 it would output to use IPv4Only.
      Fixes #40300
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
  15. 22 Feb, 2021 1 commit
  16. 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
  17. 17 Feb, 2021 3 commits
  18. 12 Feb, 2021 2 commits
    • Nick Mathewson's avatar
      Start an 0456 changelog. · fa8d4385
      Nick Mathewson authored
    • David Goulet's avatar
      config: Do not compare for duplicate ORPorts with different addresses · dfcb050b
      David Goulet authored
      We were just looking at the family which is not correct because it is possible
      to have two explicit ORPort for the same family but different addresses. One
      example is:
        ORPort NoAdvertise
        ORPort NoListen
      Thus, this patch now ignores ports that have different addresses iff they are
      both explicits. That is, if we have this example, also two different
        ORPort 9001
        ORPort NoAdvertise
      The first one is implicit and second one is explicit and thus we have to
      consider them for removal which in this case would remove the "ORPort 9001" in
      favor of the second port.
      Fixes #40289
      Signe-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
  19. 10 Feb, 2021 1 commit
  20. 08 Feb, 2021 4 commits
  21. 05 Feb, 2021 1 commit
  22. 29 Jan, 2021 3 commits