1. 18 Mar, 2020 1 commit
  2. 17 Mar, 2020 1 commit
  3. 13 Mar, 2020 6 commits
  4. 10 Mar, 2020 4 commits
  5. 08 Mar, 2020 1 commit
    • win32: clarify usage of path canonicalization funcs · fb7da154
      The path canonicalization functions on win32 are intended to
      canonicalize absolute paths; those with prefixes.  In other words,
      things start with drive letters (`C:\`), share names (`\\server\share`),
      or other prefixes (`\\?\`).
      
      This function removes leading `..` that occur after the prefix but
      before the directory/file portion (eg, turning `C:\..\..\..\foo` into
      `C:\foo`).  This translation is not appropriate for local paths.
      Edward Thomson committed
  6. 06 Mar, 2020 2 commits
  7. 05 Mar, 2020 2 commits
    • Merge pull request #5432 from libgit2/ethomson/sslread · 76e45960
      httpclient: use a 16kb read buffer for macOS
      Patrick Steinhardt committed
    • httpclient: use a 16kb read buffer for macOS · 502e5d51
      Use a 16kb read buffer for compatibility with macOS SecureTransport.
      
      SecureTransport `SSLRead` has the following behavior:
      
      1. It will return _at most_ one TLS packet's worth of data, and
      2. It will try to give you as much data as you asked for
      
      This means that if you call `SSLRead` with a buffer size that is smaller
      than what _it_ reads (in other words, the maximum size of a TLS packet),
      then it will buffer that data for subsequent calls.  However, it will
      also attempt to give you as much data as you requested in your SSLRead
      call.  This means that it will guarantee a network read in the event
      that it has buffered data.
      
      Consider our 8kb buffer and a server sending us 12kb of data on an HTTP
      Keep-Alive session.  Our first `SSLRead` will read the TLS packet off
      the network.  It will return us the 8kb that we requested and buffer the
      remaining 4kb.  Our second `SSLRead` call will see the 4kb that's
      buffered and decide that it could give us an additional 4kb.  So it will
      do a network read.
      
      But there's nothing left to read; that was the end of the data.  The
      HTTP server is waiting for us to provide a new request.  The server will
      eventually time out, our `read` system call will return, `SSLRead` can
      return back to us and we can make progress.
      
      While technically correct, this is wildly ineffecient.  (Thanks, Tim
      Apple!)
      
      Moving us to use an internal buffer that is the maximum size of a TLS
      packet (16kb) ensures that `SSLRead` will never buffer and it will
      always return everything that it read (albeit decrypted).
      Edward Thomson committed
  8. 03 Mar, 2020 1 commit
  9. 02 Mar, 2020 2 commits
  10. 01 Mar, 2020 3 commits
  11. 26 Feb, 2020 1 commit
    • deps: ntlmclient: fix htonll on big endian FreeBSD · c690136c
      In commit 3828ea67 (deps: ntlmclient: fix missing htonll symbols on
      FreeBSD and SunOS, 2020-02-21), we've fixed compilation on BSDs due to
      missing `htonll` wrappers. While we are now using `htobe64` for both
      Linux and OpenBSD, we decided to use `bswap64` on FreeBSD. While correct
      on little endian systems, where we will swap from little- to big-endian,
      we will also do the swap on big endian systems. As a result, we do not
      use network byte order on such systems.
      
      Fix the issue by using htobe64, as well.
      Patrick Steinhardt committed
  12. 25 Feb, 2020 1 commit
  13. 24 Feb, 2020 5 commits
    • transports: auth_ntlm: fix use of strdup/strndup · ebade233
      In the NTLM authentication code, we accidentally use strdup(3P) and
      strndup(3P) instead of our own wrappers git__strdup and git__strndup,
      respectively.
      
      Fix the issue by using our own functions.
      Patrick Steinhardt committed
    • deps: ntlmclient: fix missing htonll symbols on FreeBSD and SunOS · 3828ea67
      The ntlmclient dependency defines htonll on Linux-based systems, only.
      As a result, non-Linux systems will run into compiler and/or linker
      errors due to undefined symbols.
      
      Fix this issue for FreeBSD, OpenBSD and SunOS/OpenSolaris by including
      the proper headers and defining the symbol accordingly.
      Patrick Steinhardt committed
    • Merge pull request #5420 from petersalomonsen/wasm-git-links · 45ed17bd
      README: add language binding link to wasm-git
      Patrick Steinhardt committed
    • cmake: fix ENABLE_TRACE parameter being too strict · d8e71cb2
      In order to check whether tracing support should be turned on, we check
      whether ENABLE_TRACE equals "ON". This is being much too strict, as
      CMake will also treat "on", "true", "yes" and others as true-ish, but
      passing them will disable tracing support now.
      
      Fix the issue by simply removing the STREQUAL, which will cause CMake to
      do the right thing automatically.
      Patrick Steinhardt committed
    • cmake: sanitize boolean options passed by user · 41b6d30c
      Starting with our conversions to mix backend-autodetection and selection
      into a single variable (USE_GSSAPI, USE_HTTPS, USE_SHA1), we have
      introduced a simple STREQUAL to check for "ON", which indicates that the
      user wants us to auto-detect available backends and pick any one that's
      available. This behaviour deviates from previous behaviour, as passing a
      value like "yes", "on" or "true" will in fact be treated like a backend
      name and result in autodetection failure.
      
      Fix the issue by introducing a new function `SanitizeBool`. Given a
      variable that may hold a boolean value, the function will sanitize that
      variable to hold either "ON" or "OFF". In case it is not a recognized
      boolean, we will just keep the value as-is. This fixes the above
      described issue.
      Patrick Steinhardt committed
  14. 23 Feb, 2020 1 commit
  15. 21 Feb, 2020 2 commits
  16. 20 Feb, 2020 1 commit
  17. 19 Feb, 2020 6 commits