1. 22 Dec, 2020 1 commit
  2. 21 Dec, 2020 8 commits
    • David Goulet's avatar
      Merge branch 'maint-0.4.5' · e7da6810
      David Goulet authored
      e7da6810
    • David Goulet's avatar
      relay: Log address suggested by directory authorities · aae9a05a
      David Goulet authored
      
      
      If we get an address suggestion from a directory authority and we have no
      address configured or discovered, log it at notice level so the operator can
      learn what address will be used by Tor.
      
      Fixes #40201
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      aae9a05a
    • Nick Mathewson's avatar
      Merge branch 'maint-0.4.5' · 43b38805
      Nick Mathewson authored
      43b38805
    • Nick Mathewson's avatar
      ad00da66
    • Nick Mathewson's avatar
      Merge branch 'mr_240_squashed' · cce7d1ed
      Nick Mathewson authored
      cce7d1ed
    • David Goulet's avatar
      f4cbcde2
    • Karsten Loesing's avatar
      Fix timestamp parser in new load_stats_file. · 5dd6304f
      Karsten Loesing authored
      The previous parser only considered stats files _starting_ with the
      timestamp tag, not stats files having the timestamp tag in a later
      position. While this applies to all current stats files, a future
      stats file might look differently. Better to fix the function now than
      be surprised in another 9 years from now.
      
      This commit also adds a test case for such future stats, and it fixes
      stats file paths in newly added unit tests.
      5dd6304f
    • David Goulet's avatar
      relay: Report the entire content of a stats file · c934fced
      David Goulet authored
      It turns out that 9 years ago, we stopped appending data into stats file and
      rather overwrite everytime we have new stats (see commit
      a6a127c8
      
      )
      
      The load_stats_file() function was still thinking that we could have the same
      line many times in the file which turns out to be false since 9 years ago.
      However, that did not cause problem until IPv6 connection stats came along
      which introduced a new line in conn-stats: "ipv6-conn-bi-direct ...".
      
      Before, that file contained a single line starting with the tag
      "conn-bi-direct".  That very tag appears also in the IPv6 tag (see above) so
      the load_stats_file() function would consider that the IPv6 line as the last
      tag to be appeneded to the file and fail to report the line above (for IPv4).
      It would actually truncate the IPv6 line and report it (removing the "ipv6-"
      part).
      
      In other words, "conn-bi-direct" was not reported and instead
      "ipv6-conn-bi-direct" was used without the "ipv6-" part.
      
      This commit refactors the entire function so that now it looks for a
      "timestamp tag" to validate and then if everything is fine, returns the entire
      content of the file. The refactor simplifies the function, adds logging in
      case of failures and modernize it in terms of coding standard.
      
      Unit tests are also added that makes sure the loaded content matches the
      entire file if timestamp validation passes.
      
      Fixes #40226
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      c934fced
  3. 18 Dec, 2020 2 commits
  4. 17 Dec, 2020 3 commits
  5. 16 Dec, 2020 9 commits
  6. 15 Dec, 2020 5 commits
  7. 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
  8. 11 Dec, 2020 2 commits
    • David Goulet's avatar
      configure: Revert back the static libevent path · 15b0d30a
      David Goulet authored
      From c618c4f2
      
      , we changed the static
      libevent.a path to be able to use the git repository or tarball directly but
      that broke the "make install" setup that Tor Browser is using with Android.
      
      In other words, the git repository and tarball put the "libevent.a" in
      ".libs/" where "make install" puts it in "lib/".
      
      Using the --with-libevent-dir=..., which is mandatory for static libevent,
      autoconf will take the path and use it for the includes (-I) and library (-L)
      for which if it finds a "include/" and a "lib/" in the root, it will use
      those.
      
      However, with the git repo or tarball, the "lib/" doesn't exists thus autoconf
      sets the library search path to be at the root and thus fails to find the
      libevent.a in ".libs/".
      
      This is a whole lot more work to make both cases work in our configure.ac thus
      I'm reverting the change here to the Tor Browser case works again and the work
      around for others is to either symlink the libevent.a at the root or use a
      temporary make install directory.
      
      One long term fix here would likely be to ask libevent to symblink the .a into
      the root along the .la files and likely do the same for .so. Or, use the
      "lib/" structure to contain the .a + .so files. Would be better than doing
      ninji-tsu in our configure.ac
      
      Fixes #40225
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      15b0d30a
    • George Kadianakis's avatar
      04b271af
  9. 09 Dec, 2020 4 commits
  10. 08 Dec, 2020 5 commits