Skip to content

G
git2
Switch branch/tag
  1. 18 Mar, 2020 1 commit
  3. 17 Mar, 2020 1 commit
  5. 13 Mar, 2020 6 commits
  7. 10 Mar, 2020 4 commits
  9. 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
  11. 06 Mar, 2020 2 commits
  13. 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
  15. 03 Mar, 2020 1 commit
  17. 02 Mar, 2020 2 commits
  19. 01 Mar, 2020 3 commits
  21. 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
  23. 25 Feb, 2020 1 commit
  25. 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
  27. 23 Feb, 2020 1 commit
  29. 21 Feb, 2020 2 commits
  31. 20 Feb, 2020 1 commit
  33. 19 Feb, 2020 6 commits