kmx git

Commit	Date	Message
3fa8ec52	2021-04-18T20:30:13	src: fix typos in header files
edffea15	2021-03-01T16:26:58	winhttp: skip certificate check if unable to send request In some circumstances (e.g. when proxies are involved), winhttp will fail to reach the WINHTTP_CALLBACK_STATUS_SENDING_REQUEST phase. If this occurs, we'll error with ERROR_WINHTTP_INCORRECT_HANDLE_STATE when attempting to query the server certificate context (see https://docs.microsoft.com/en-us/windows/win32/api/winhttp/nf-winhttp-winhttpsendrequest#remarks). To avoid this, verify that WinHttpSendRequest has reached the WINHTTP_CALLBACK_STATUS_SENDING_REQUEST phase before checking the certificate. Since we're using WinHTTP in synchronous mode, we know for sure that once WinHttpSendRequest returns we've either sent it successfully or not. NOTE: WINHTTP_CALLBACK_STATUS_SENDING_REQUEST appears to be deprecated with no direct replacement. WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE is only available in async mode, and there doesn't appear to be a method of querying this flag outside of the status callback.
7efddeb7	2021-02-15T15:47:28	Fix some typos
fe41e582	2020-12-23T12:32:58	Merge pull request #5741 from libgit2/ethomson/ipv6 Handle ipv6 addresses
b7ffc63b	2020-12-17T18:38:01	winhttp: handle ipv6 addresses
2807de5c	2020-12-17T15:18:31	http: handle ipv6 addresses
3433acd9	2020-12-21T21:27:58	Wrap newer hostkeys in #ifdefs This allows the library to be built using a pre-1.9.0 version of libssh2.
ed7b20e7	2020-12-21T17:26:34	Add support for additional hostkey types. Specifically: ECDSA_256, ECDSA_384, ECDSA_521 and ED25519.
86a1cdd3	2020-12-13T13:44:56	Merge pull request #5384 from ianhattendorf/fix/winhttp-client-cert winhttp: support optional client cert
37763d38	2020-12-05T15:26:59	threads: rename git_atomic to git_atomic32 Clarify the `git_atomic` type and functions now that we have a 64 bit version as well (`git_atomic64`).
29fe5f61	2020-11-22T18:25:00	Also add the raw hostkey to `git_cert_hostkey` `git_cert_x509` has the raw encoded certificate. Let's do the same for the SSH certificate for symmetry.
4f5f1127	2020-11-22T00:01:09	transports: use GIT_ASSERT
05816a98	2020-04-05T17:20:08	netops: use GIT_ASSERT
e316b0d3	2020-05-15T11:47:09	runtime: move init/shutdown into the "runtime" Provide a mechanism for system components to register for initialization and shutdown of the libgit2 runtime.
6554b40e	2020-05-13T10:39:33	settings: localize global data Move the settings global data teardown into its own separate function, instead of intermingled with the global state.
2ab99c6d	2020-10-04T18:30:10	Merge pull request #5576 from lollipopman/double-auth httpclient: only free challenges for current_server type
9e81711b	2020-09-18T10:31:50	Merge pull request #5632 from csware/winhttp_typo Fix typo: Make ifndef macroname the same as the define name
797535b6	2020-09-12T00:14:41	WinHTTP: Try to use TLS1.3 Signed-off-by: Sven Strickroth <email@cs-ware.de>
621e501c	2020-09-10T10:32:02	Fix typo: Make ifndef macroname the same as the define name Signed-off-by: Sven Strickroth <email@cs-ware.de>
2dea3eb4	2020-09-08T13:03:07	Don't fail if a HTTP server announces he supports a protocol upgrade cf. RFC7230 section 6.7, an Upgrade header in a normal response merely informs the client that the server supports upgrading to other protocols, and the client can ask for such an upgrade in a later request. The server requiring an upgrade is via the 426 Upgrade Required response code, not the mere presence of the Upgrade response header. (closes issue #5573) Signed-off-by: Sven Strickroth <email@cs-ware.de>
bd346313	2020-07-10T15:37:08	httpclient: only free challenges for current_server type Prior to this commit we freed both the server and proxy auth challenges in git_http_client_read_response. This works when the proxy needs auth or when the server needs auth, but it does not work when both the proxy and the server need auth as we erroneously remove the server auth challenge before we have added them as server credentials. Instead only remove the challenges for the current_server type. Co-authored-by: Stephen Gelman <ssgelm@gmail.com>
6a10b802	2020-06-24T08:53:46	winhttp: clarify invalid cert case
c6184f0c	2020-06-08T21:07:36	tree-wide: do not compile deprecated functions with hard deprecation When compiling libgit2 with -DDEPRECATE_HARD, we add a preprocessor definition `GIT_DEPRECATE_HARD` which causes the "git2/deprecated.h" header to be empty. As a result, no function declarations are made available to callers, but the implementations are still available to link against. This has the problem that function declarations also aren't visible to the implementations, meaning that the symbol's visibility will not be set up correctly. As a result, the resulting library may not expose those deprecated symbols at all on some platforms and thus cause linking errors. Fix the issue by conditionally compiling deprecated functions, only. While it becomes impossible to link against such a library in case one uses deprecated functions, distributors of libgit2 aren't expected to pass -DDEPRECATE_HARD anyway. Instead, users of libgit2 should manually define GIT_DEPRECATE_HARD to hide deprecated functions. Using "real" hard deprecation still makes sense in the context of CI to test we don't use deprecated symbols ourselves and in case a dependant uses libgit2 in a vendored way and knows it won't ever use any of the deprecated symbols anyway.
a6c9e0b3	2020-06-08T12:40:47	tree-wide: mark local functions as static We've accumulated quite some functions which are never used outside of their respective code unit, but which are lacking the `static` keyword. Add it to reduce their linkage scope and allow the compiler to optimize better.
53a8f463	2020-06-03T07:40:59	Merge pull request #5536 from libgit2/ethomson/http httpclient: support googlesource
04c7bdb4	2020-06-01T22:44:14	httpclient: clear the read_buf on new requests The httpclient implementation keeps a `read_buf` that holds the data in the body of the response after the headers have been written. We store that data for subsequent calls to `git_http_client_read_body`. If we want to stop reading body data and send another request, we need to clear that cached data. Clear the cached body data on new requests, just like we read any outstanding data from the socket.
aa8b2c0f	2020-06-01T23:53:55	httpclient: don't read more than the client wants When `git_http_client_read_body` is invoked, it provides the size of the buffer that can be read into. This will be set as the parser context's `output_size` member. Use this as an upper limit on our reads, and ensure that we do not read more than the client requests.
51eff5a5	2020-05-29T13:13:19	strarray: we should `dispose` instead of `free` We _dispose_ the contents of objects; we _free_ objects (and their contents). Update `git_strarray_free` to be `git_strarray_dispose`. `git_strarray_free` remains as a deprecated proxy function.
570f0340	2020-06-01T19:10:38	httpclient: read_body should return 0 at EOF When users call `git_http_client_read_body`, it should return 0 at the end of a message. When the `on_message_complete` callback is called, this will set `client->state` to `DONE`. In our read loop, we look for this condition and exit. Without this, when there is no data left except the end of message chunk (`0\r\n`) in the http stream, we would block by reading the three bytes off the stream but not making progress in any `on_body` callbacks. Listening to the `on_message_complete` callback allows us to stop trying to read from the socket when we've read the end of message chunk.
e7a1fd88	2020-03-26T11:42:47	Fix spelling error Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>
502e5d51	2020-03-01T12:44:39	httpclient: use a 16kb read buffer for macOS 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).
ebade233	2020-02-24T21:49:43	transports: auth_ntlm: fix use of strdup/strndup 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.
46228d86	2020-02-06T11:10:27	transports: http: fix custom headers not being applied In commit b9c5b15a7 (http: use the new httpclient, 2019-12-22), the HTTP code got refactored to extract a generic HTTP client that operates independently of the Git protocol. Part of refactoring was the creation of a new `git_http_request` struct that encapsulates the generation of requests. Our Git-specific HTTP transport was converted to use that in `generate_request`, but during the process we forgot to set up custom headers for the `git_http_request` and as a result we do not send out these headers anymore. Fix the issue by correctly setting up the request's custom headers and add a test to verify we correctly send them.
1697e90f	2020-02-06T09:22:46	winhttp: variable and switch case scoping
5b2cd755	2020-02-03T16:24:02	winhttp: support optional client cert
3f54ba8b	2020-01-18T13:51:40	credential: change git_cred to git_credential We avoid abbreviations where possible; rename git_cred to git_credential. In addition, we have standardized on a trailing `_t` for enum types, instead of using "type" in the name. So `git_credtype_t` has become `git_credential_t` and its members have become `GIT_CREDENTIAL` instead of `GIT_CREDTYPE`. Finally, the source and header files have been renamed to `credential` instead of `cred`. Keep previous name and values as deprecated, and include the new header files from the previous ones.
e9cef7c4	2020-01-11T23:53:45	http: introduce GIT_ERROR_HTTP Disambiguate between general network problems and HTTP problems in error codes.
29762e40	2020-01-01T16:14:37	httpclient: use defines for status codes
76fd406a	2019-12-26T16:37:01	http: send probe packets When we're authenticating with a connection-based authentication scheme (NTLM, Negotiate), we need to make sure that we're still connected between the initial GET where we did the authentication and the POST that we're about to send. Our keep-alive session may have not kept alive, but more likely, some servers do not authenticate the entire keep-alive connection and may have "forgotten" that we were authenticated, namely Apache and nginx. Send a "probe" packet, that is an HTTP POST request to the upload-pack or receive-pack endpoint, that consists of an empty git pkt ("0000"). If we're authenticated, we'll get a 200 back. If we're not, we'll get a 401 back, and then we'll resend that probe packet with the first step of our authentication (asking to start authentication with the given scheme). We expect _yet another_ 401 back, with the authentication challenge. Finally, we will send our authentication response with the actual POST data. This will allow us to authenticate without draining the POST data in the initial request that gets us a 401.
b9c5b15a	2019-12-22T14:12:24	http: use the new httpclient Untangle the notion of the http transport from the actual http implementation. The http transport now uses the httpclient.
7372573b	2019-10-25T12:22:10	httpclient: support expect/continue Allow users to opt-in to expect/continue handling when sending a POST and we're authenticated with a "connection-based" authentication mechanism like NTLM or Negotiate. If the response is a 100, return to the caller (to allow them to post their body). If the response is not a 100, buffer the response for the caller. HTTP expect/continue is generally safe, but some legacy servers have not implemented it correctly. Require it to be opt-in.
6c21c989	2019-12-14T21:32:07	httpclient: support CONNECT proxies Fully support HTTP proxies, in particular CONNECT proxies, that allow us to speak TLS through a proxy.
6b208836	2019-12-18T21:55:28	httpclient: handle chunked responses Detect responses that are sent with Transfer-Encoding: chunked, and record that information so that we can consume the entire message body.
6a095679	2019-12-14T10:34:36	httpclient: support authentication Store the last-seen credential challenges (eg, all the 'WWW-Authenticate' headers in a response message). Given some credentials, find the best (first) challenge whose mechanism supports these credentials. (eg, 'Basic' supports username/password credentials, 'Negotiate' supports default credentials). Set up an authentication context for this mechanism and these credentials. Continue exchanging challenge/responses until we're authenticated.
1152f361	2019-12-13T18:37:19	httpclient: consume final chunk message When sending a new request, ensure that we got the entirety of the response body. Our caller may have decided that they were done reading. If we were not at the end of the message, this means that we need to tear down the connection and cannot do keep-alive. However, if the caller read all of the message, but we still have a final end-of-response chunk signifier (ie, "0\r\n\r\n") on the socket, then we should consider that the response was successfully copmleted. If we're asked to send a new request, try to read from the socket, just to clear out that end-of-chunk message, marking ourselves as disconnected on any errors.
84b99a95	2019-12-12T13:53:43	httpclient: add chunk support to POST Teach httpclient how to support chunking when POSTing request bodies.
eacecebd	2019-12-12T13:25:32	httpclient: introduce a simple http implementation Introduce a new http client implementation that can GET and POST to remote URLs. Consumers can use `git_http_client_init` to create a new client, `git_http_client_send_request` to send a request to the remote server and `git_http_client_read_response` to read the response. The http client implementation will perform the I/O with the remote server (http or https) but does not understand the git smart transfer protocol. This allows us to split the concerns of the http subtransport from the actual http implementation.
471daeea	2019-12-01T14:00:49	net: refactor gitno redirect handling Move the redirect handling into `git_net_url` for consistency.
a194e17f	2019-11-27T18:43:36	winhttp: refactor request sending Clarify what it means to not send a length; this allows us to refactor requests further.
7e0f5a6a	2019-10-22T22:37:14	smart protocol: correct case in error messages
2d6a61bd	2019-10-22T09:52:31	gssapi: validate that we were requested Negotiate
e761df5c	2019-10-22T09:35:48	gssapi: dispose after completion for retry Disposal pattern; dispose on completion, allowing us to retry authentication, which may happen on web servers that close connection-based authenticated sessions (NTLM/SPNEGO) unexpectedly.
5625892b	2019-09-20T12:06:11	gssapi: delete half-built security context so auth can continue
2174aa0a	2019-10-21T11:47:23	gssapi: correct incorrect case in error message
3f6fe054	2019-10-20T17:23:01	gssapi: protect GSS_ERROR macro The GSS_ERROR(x) macro may expand to `(x & value)` on some implementations, instead of `((x) & value)`. This is the case on macOS, which means that if we attempt to wrap an expression in that macro, like `a = b`, then that would expand to `(a = b & value)`. Since `&` has a higher precedence, this is not at all what we want, and will set our result code to an incorrect value. Evaluate the expression then test it with `GSS_ERROR` independently to avoid this.
73fe690d	2019-10-20T17:22:27	gssapi: protect against empty messages
917ba762	2020-01-18T14:14:00	auth: update enum type name for consistency libgit2 does not use `type_t` suffixes as it's redundant; thus, rename `git_http_authtype_t` to `git_http_auth_t` for consistency.
dbb6429c	2020-01-10T14:30:18	Merge pull request #5305 from kas-luthor/bugfix/multiple-auth Adds support for multiple SSH auth mechanisms being used sequentially
33f93bf3	2020-01-06T11:53:53	Merge pull request #5325 from josharian/no-double-slash http: avoid generating double slashes in url
05c1fb8a	2019-12-06T11:04:40	http: avoid generating double slashes in url Prior to this change, given a remote url with a trailing slash, such as http://localhost/a/, service requests would contain a double slash: http://localhost/a//info/refs?service=git-receive-pack. Detect and prevent that. Updates #5321
cb7fd1ed	2019-12-13T15:11:38	Fixes code styling
86852613	2019-12-13T12:13:05	smart_pkt: fix overflow resulting in OOB read/write of one byte When parsing OK packets, we copy any information after the initial "ok " prefix into the resulting packet. As newlines act as packet boundaries, we also strip the trailing newline if there is any. We do not check whether there is any data left after the initial "ok " prefix though, which leads to a pointer overflow in that case as `len == 0`: if (line[len - 1] == '\n') --len; This out-of-bounds read is a rather useless gadget, as we can only deduce whether at some offset there is a newline character. In case there accidentally is one, we overflow `len` to `SIZE_MAX` and then write a NUL byte into an array indexed by it: pkt->ref[len] = '\0'; Again, this doesn't seem like something that's possible to be exploited in any meaningful way, but it may surely lead to inconsistencies or DoS. Fix the issue by checking whether there is any trailing data after the packet prefix.
48c3f7e1	2019-11-20T11:21:14	ssh: include sha256 host key hash when supported
fbdf5bdd	2019-11-16T22:41:25	Adds support for multiple SSH auth mechanisms being used sequentially
3f998aee	2019-10-26T17:21:29	Follow 308 redirect in WinHTTP transport
dbc17a7e	2019-09-21T08:46:08	negotiate: use GSS.framework on macOS
49a3289e	2019-09-21T08:25:23	cred: add missing private header in GSSAPI block Should have been part of 8bf0f7eb26c65b2b937b1f40a384b9b269b0b76d
8bf0f7eb	2019-09-09T13:00:27	cred: separate public interface from low-level details
5d8a4659	2019-09-13T10:31:49	Merge pull request #5195 from tiennou/fix/commitish-smart-push smart: use push_glob instead of manual filtering
39028eb6	2019-09-09T13:00:53	Merge pull request #5212 from libgit2/ethomson/creds_for_scheme Use an HTTP scheme that supports the given credentials
4de51f9e	2019-08-23T16:05:28	http: ensure the scheme supports the credentials When a server responds with multiple scheme support - for example, Negotiate and NTLM are commonly used together - we need to ensure that we choose a scheme that supports the credentials.
53f51c60	2019-08-21T19:48:05	smart: implement by-date insertion when revwalking
c2dd895a	2019-08-08T10:47:29	transports: http: check for memory allocation failures When allocating a chunk that is used to write to HTTP streams, we do not check for memory allocation errors. This may lead us to write to a `NULL` pointer and thus cause a segfault. Fix this by adding a call to `GIT_ERROR_CHECK_ALLOC`.
1c847169	2019-08-21T16:38:59	http: allow dummy negotiation scheme to fail to act The dummy negotiation scheme is used for known authentication strategies that do not wish to act. For example, when a server requests the "Negotiate" scheme but libgit2 is not built with Negotiate support, and will use the "dummy" strategy which will simply not act. Instead of setting `out` to NULL and returning a successful code, return `GIT_PASSTHROUGH` to indicate that it did not act and catch that error code.
39d18fe6	2019-07-31T08:37:10	smart: use push_glob instead of manual filtering The code worked under the assumption that anything under `refs/tags` are tag objects, and all the rest would be peelable to a commit. As it is completely valid to have tags to blobs under a non `refs/tags` ref, this would cause failures when trying to peel a tag to a commit. Fix the broken filtering by switching to `git_revwalk_push_glob`, which already handles this case.
3cd123e9	2019-06-15T21:56:53	win32: define DWORD_MAX if it's not defined MinGW does not define DWORD_MAX. Specify it when it's not defined.
d93b0aa0	2019-06-15T21:47:40	win32: decorate unused parameters
8c925ef8	2019-05-21T14:30:28	smart protocol: validate progress message length Ensure that the server has not sent us overly-large sideband messages (ensure that they are no more than `INT_MAX` bytes), then cast to `int`.
7afe788c	2019-05-21T14:27:46	smart transport: use size_t for sizes
db7f1d9b	2019-05-21T14:21:58	local transport: cast message size to int explicitly Our progress information messages are short (and bounded by their format string), cast the length to int for callers.
8048ba70	2019-05-21T14:18:40	winhttp: safely cast length to DWORD
2a4bcf63	2019-06-23T18:24:23	errors: use lowercase Use lowercase for our error messages, per our custom.
5d92e547	2019-06-08T17:28:35	oid: `is_zero` instead of `iszero` The only function that is named `issomething` (without underscore) was `git_oid_iszero`. Rename it to `git_oid_is_zero` for consistency with the rest of the library.
0b5ba0d7	2019-06-06T16:36:23	Rename opt init functions to `options_init` In libgit2 nomenclature, when we need to verb a direct object, we name a function `git_directobject_verb`. Thus, if we need to init an options structure named `git_foo_options`, then the name of the function that does that should be `git_foo_options_init`. The previous names of `git_foo_init_options` is close - it _sounds_ as if it's initializing the options of a `foo`, but in fact `git_foo_options` is its own noun that should be respected. Deprecate the old names; they'll now call directly to the new ones.
7ea8630e	2019-04-07T20:11:59	http: free auth context on failure When we send HTTP credentials but the server rejects them, tear down the authentication context so that we can start fresh. To maintain this state, additionally move all of the authentication handling into `on_auth_required`.
005b5bc2	2019-04-07T17:55:23	http: reconnect to proxy on connection close When we're issuing a CONNECT to a proxy, we expect to keep-alive to the proxy. However, during authentication negotiations, the proxy may close the connection. Reconnect if the server closes the connection.
d171fbee	2019-04-07T17:40:23	http: allow server to drop a keepalive connection When we have a keep-alive connection to the server, that server may legally drop the connection for any reason once a successful request and response has occurred. It's common for servers to drop the connection after some amount of time or number of requests have occurred.
9af1de5b	2019-03-24T20:49:57	http: stop on server EOF We stop the read loop when we have read all the data. We should also consider the server's feelings. If the server hangs up on us, we need to stop our read loop. Otherwise, we'll try to read from the server - and fail - ad infinitum.
539e6293	2019-03-22T19:06:46	http: teach auth mechanisms about connection affinity Instead of using `is_complete` to decide whether we have connection or request affinity for authentication mechanisms, set a boolean on the mechanism definition itself.
3e0b4b43	2019-03-22T18:52:03	http: maintain authentication across connections For request-based authentication mechanisms (Basic, Digest) we should keep the authentication context alive across socket connections, since the authentication headers must be transmitted with every request. However, we should continue to remove authentication contexts for mechanisms with connection affinity (NTLM, Negotiate) since we need to reauthenticate for every socket connection.
ce72ae95	2019-03-22T10:53:30	http: simplify authentication mechanisms Hold an individual authentication context instead of trying to maintain all the contexts; we can select the preferred context during the initial negotiation. Subsequent authentication steps will re-use the chosen authentication (until such time as it's rejected) instead of trying to manage multiple contexts when all but one will never be used (since we can only authenticate with a single mechanism at a time.) Also, when we're given a 401 or 407 in the middle of challenge/response handling, short-circuit immediately without incrementing the retry count. The multi-step authentication is expected, and not a "retry" and should not be penalized as such. This means that we don't need to keep the contexts around and ensures that we do not unnecessarily fail for too many retries when we have challenge/response auth on a proxy and a server and potentially redirects in play as well.
6d931ba7	2019-03-22T16:35:59	http: don't set the header in the auth token
10718526	2019-03-09T13:53:16	http: don't reset replay count after connection A "connection" to a server is transient, and we may reconnect to a server in the midst of authentication failures (if the remote indicates that we should, via `Connection: close`) or in a redirect.
3192e3c9	2019-03-07T16:57:11	http: provide an NTLM authentication provider
79fc8281	2019-03-21T16:49:25	http: validate server's authentication types Ensure that the server supports the particular credential type that we're specifying. Previously we considered credential types as an input to an auth mechanism - since the HTTP transport only supported default credentials (via negotiate) and username/password credentials (via basic), this worked. However, if we are to add another mechanism that uses username/password credentials, we'll need to be careful to identify the types that are accepted.
5ad99210	2019-03-07T16:43:45	http: consume body on proxy auth failure We must always consume the full parser body if we're going to keep-alive. So in the authentication failure case, continue advancing the http message parser until it's complete, then we can retry the connection. Not doing so would mean that we have to tear the connection down and start over. Advancing through fully (even though we don't use the data) will ensure that we can retry a connection with keep-alive.
75b20458	2019-03-07T16:34:55	http: always consume body on auth failure When we get an authentication failure, we must consume the entire body of the response. If we only read half of the body (on the assumption that we can ignore the rest) then we will never complete the parsing of the message. This means that we will never set the complete flag, and our replay must actually tear down the connection and try again. This is particularly problematic for stateful authentication mechanisms (SPNEGO, NTLM) that require that we keep the connection alive. Note that the prior code is only a problem when the 401 that we are parsing is too large to be read in a single chunked read from the http parser. But now we will continue to invoke the http parser until we've got a complete message in the authentication failed scenario. Note that we need not do anything with the message, so when we get an authentication failed, we'll stop adding data to our buffer, we'll simply loop in the parser and let it advance its internal state.
e87f912b	2019-03-21T15:29:52	http: don't realloc the request
10e8fe55	2019-03-21T13:55:54	transports: add an `is_complete` function for auth Some authentication mechanisms (like HTTP Basic and Digest) have a one-step mechanism to create credentials, but there are more complex mechanisms like NTLM and Negotiate that require challenge/response after negotiation, requiring several round-trips. Add an `is_complete` function to know when they have round-tripped enough to be a single authentication and should now either have succeeded or failed to authenticate.
9050c69c	2019-03-09T17:24:16	http: examine keepalive status at message end We cannot examine the keep-alive status of the http parser in `http_connect`; it's too late and the critical information about whether keep-alive is supported has been destroyed. Per the documentation for `http_should_keep_alive`: > If http_should_keep_alive() in the on_headers_complete or > on_message_complete callback returns 0, then this should be > the last message on the connection. Query then and set the state.

3fa8ec52

2021-04-18T20:30:13

src: fix typos in header files

edffea15

2021-03-01T16:26:58

winhttp: skip certificate check if unable to send request In some circumstances (e.g. when proxies are involved), winhttp will fail to reach the WINHTTP_CALLBACK_STATUS_SENDING_REQUEST phase. If this occurs, we'll error with ERROR_WINHTTP_INCORRECT_HANDLE_STATE when attempting to query the server certificate context (see https://docs.microsoft.com/en-us/windows/win32/api/winhttp/nf-winhttp-winhttpsendrequest#remarks). To avoid this, verify that WinHttpSendRequest has reached the WINHTTP_CALLBACK_STATUS_SENDING_REQUEST phase before checking the certificate. Since we're using WinHTTP in synchronous mode, we know for sure that once WinHttpSendRequest returns we've either sent it successfully or not. NOTE: WINHTTP_CALLBACK_STATUS_SENDING_REQUEST appears to be deprecated with no direct replacement. WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE is only available in async mode, and there doesn't appear to be a method of querying this flag outside of the status callback.

7efddeb7

2021-02-15T15:47:28

Fix some typos

fe41e582

2020-12-23T12:32:58

Merge pull request #5741 from libgit2/ethomson/ipv6 Handle ipv6 addresses

b7ffc63b

2020-12-17T18:38:01

winhttp: handle ipv6 addresses

2807de5c

2020-12-17T15:18:31

http: handle ipv6 addresses

3433acd9

2020-12-21T21:27:58

Wrap newer hostkeys in #ifdefs This allows the library to be built using a pre-1.9.0 version of libssh2.

ed7b20e7

2020-12-21T17:26:34

Add support for additional hostkey types. Specifically: ECDSA_256, ECDSA_384, ECDSA_521 and ED25519.

86a1cdd3

2020-12-13T13:44:56

Merge pull request #5384 from ianhattendorf/fix/winhttp-client-cert winhttp: support optional client cert

37763d38

2020-12-05T15:26:59

threads: rename git_atomic to git_atomic32 Clarify the `git_atomic` type and functions now that we have a 64 bit version as well (`git_atomic64`).

29fe5f61

2020-11-22T18:25:00

Also add the raw hostkey to `git_cert_hostkey` `git_cert_x509` has the raw encoded certificate. Let's do the same for the SSH certificate for symmetry.

4f5f1127

2020-11-22T00:01:09

transports: use GIT_ASSERT

05816a98

2020-04-05T17:20:08

netops: use GIT_ASSERT

e316b0d3

2020-05-15T11:47:09

runtime: move init/shutdown into the "runtime" Provide a mechanism for system components to register for initialization and shutdown of the libgit2 runtime.

6554b40e

2020-05-13T10:39:33

settings: localize global data Move the settings global data teardown into its own separate function, instead of intermingled with the global state.

2ab99c6d

2020-10-04T18:30:10

Merge pull request #5576 from lollipopman/double-auth httpclient: only free challenges for current_server type

9e81711b

2020-09-18T10:31:50

Merge pull request #5632 from csware/winhttp_typo Fix typo: Make ifndef macroname the same as the define name

797535b6

2020-09-12T00:14:41

WinHTTP: Try to use TLS1.3 Signed-off-by: Sven Strickroth <email@cs-ware.de>

621e501c

2020-09-10T10:32:02

Fix typo: Make ifndef macroname the same as the define name Signed-off-by: Sven Strickroth <email@cs-ware.de>

2dea3eb4

2020-09-08T13:03:07

Don't fail if a HTTP server announces he supports a protocol upgrade cf. RFC7230 section 6.7, an Upgrade header in a normal response merely informs the client that the server supports upgrading to other protocols, and the client can ask for such an upgrade in a later request. The server requiring an upgrade is via the 426 Upgrade Required response code, not the mere presence of the Upgrade response header. (closes issue #5573) Signed-off-by: Sven Strickroth <email@cs-ware.de>

bd346313

2020-07-10T15:37:08

httpclient: only free challenges for current_server type Prior to this commit we freed both the server and proxy auth challenges in git_http_client_read_response. This works when the proxy needs auth or when the server needs auth, but it does not work when both the proxy and the server need auth as we erroneously remove the server auth challenge before we have added them as server credentials. Instead only remove the challenges for the current_server type. Co-authored-by: Stephen Gelman <ssgelm@gmail.com>

6a10b802

2020-06-24T08:53:46

winhttp: clarify invalid cert case

c6184f0c

2020-06-08T21:07:36

tree-wide: do not compile deprecated functions with hard deprecation When compiling libgit2 with -DDEPRECATE_HARD, we add a preprocessor definition `GIT_DEPRECATE_HARD` which causes the "git2/deprecated.h" header to be empty. As a result, no function declarations are made available to callers, but the implementations are still available to link against. This has the problem that function declarations also aren't visible to the implementations, meaning that the symbol's visibility will not be set up correctly. As a result, the resulting library may not expose those deprecated symbols at all on some platforms and thus cause linking errors. Fix the issue by conditionally compiling deprecated functions, only. While it becomes impossible to link against such a library in case one uses deprecated functions, distributors of libgit2 aren't expected to pass -DDEPRECATE_HARD anyway. Instead, users of libgit2 should manually define GIT_DEPRECATE_HARD to hide deprecated functions. Using "real" hard deprecation still makes sense in the context of CI to test we don't use deprecated symbols ourselves and in case a dependant uses libgit2 in a vendored way and knows it won't ever use any of the deprecated symbols anyway.

a6c9e0b3

2020-06-08T12:40:47

tree-wide: mark local functions as static We've accumulated quite some functions which are never used outside of their respective code unit, but which are lacking the `static` keyword. Add it to reduce their linkage scope and allow the compiler to optimize better.

53a8f463

2020-06-03T07:40:59

Merge pull request #5536 from libgit2/ethomson/http httpclient: support googlesource

04c7bdb4

2020-06-01T22:44:14

httpclient: clear the read_buf on new requests The httpclient implementation keeps a `read_buf` that holds the data in the body of the response after the headers have been written. We store that data for subsequent calls to `git_http_client_read_body`. If we want to stop reading body data and send another request, we need to clear that cached data. Clear the cached body data on new requests, just like we read any outstanding data from the socket.

aa8b2c0f

2020-06-01T23:53:55

httpclient: don't read more than the client wants When `git_http_client_read_body` is invoked, it provides the size of the buffer that can be read into. This will be set as the parser context's `output_size` member. Use this as an upper limit on our reads, and ensure that we do not read more than the client requests.

51eff5a5

2020-05-29T13:13:19

strarray: we should `dispose` instead of `free` We _dispose_ the contents of objects; we _free_ objects (and their contents). Update `git_strarray_free` to be `git_strarray_dispose`. `git_strarray_free` remains as a deprecated proxy function.

570f0340

2020-06-01T19:10:38

httpclient: read_body should return 0 at EOF When users call `git_http_client_read_body`, it should return 0 at the end of a message. When the `on_message_complete` callback is called, this will set `client->state` to `DONE`. In our read loop, we look for this condition and exit. Without this, when there is no data left except the end of message chunk (`0\r\n`) in the http stream, we would block by reading the three bytes off the stream but not making progress in any `on_body` callbacks. Listening to the `on_message_complete` callback allows us to stop trying to read from the socket when we've read the end of message chunk.

e7a1fd88

2020-03-26T11:42:47

Fix spelling error Signed-off-by: Utkarsh Gupta <utkarsh@debian.org>

502e5d51

2020-03-01T12:44:39

httpclient: use a 16kb read buffer for macOS 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).

ebade233

2020-02-24T21:49:43

transports: auth_ntlm: fix use of strdup/strndup 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.

46228d86

2020-02-06T11:10:27

transports: http: fix custom headers not being applied In commit b9c5b15a7 (http: use the new httpclient, 2019-12-22), the HTTP code got refactored to extract a generic HTTP client that operates independently of the Git protocol. Part of refactoring was the creation of a new `git_http_request` struct that encapsulates the generation of requests. Our Git-specific HTTP transport was converted to use that in `generate_request`, but during the process we forgot to set up custom headers for the `git_http_request` and as a result we do not send out these headers anymore. Fix the issue by correctly setting up the request's custom headers and add a test to verify we correctly send them.

1697e90f

2020-02-06T09:22:46

winhttp: variable and switch case scoping

5b2cd755

2020-02-03T16:24:02

winhttp: support optional client cert

3f54ba8b

2020-01-18T13:51:40

credential: change git_cred to git_credential We avoid abbreviations where possible; rename git_cred to git_credential. In addition, we have standardized on a trailing `_t` for enum types, instead of using "type" in the name. So `git_credtype_t` has become `git_credential_t` and its members have become `GIT_CREDENTIAL` instead of `GIT_CREDTYPE`. Finally, the source and header files have been renamed to `credential` instead of `cred`. Keep previous name and values as deprecated, and include the new header files from the previous ones.

e9cef7c4

2020-01-11T23:53:45

http: introduce GIT_ERROR_HTTP Disambiguate between general network problems and HTTP problems in error codes.

29762e40

2020-01-01T16:14:37

httpclient: use defines for status codes

76fd406a

2019-12-26T16:37:01

http: send probe packets When we're authenticating with a connection-based authentication scheme (NTLM, Negotiate), we need to make sure that we're still connected between the initial GET where we did the authentication and the POST that we're about to send. Our keep-alive session may have not kept alive, but more likely, some servers do not authenticate the entire keep-alive connection and may have "forgotten" that we were authenticated, namely Apache and nginx. Send a "probe" packet, that is an HTTP POST request to the upload-pack or receive-pack endpoint, that consists of an empty git pkt ("0000"). If we're authenticated, we'll get a 200 back. If we're not, we'll get a 401 back, and then we'll resend that probe packet with the first step of our authentication (asking to start authentication with the given scheme). We expect _yet another_ 401 back, with the authentication challenge. Finally, we will send our authentication response with the actual POST data. This will allow us to authenticate without draining the POST data in the initial request that gets us a 401.

b9c5b15a

2019-12-22T14:12:24

http: use the new httpclient Untangle the notion of the http transport from the actual http implementation. The http transport now uses the httpclient.

7372573b

2019-10-25T12:22:10

httpclient: support expect/continue Allow users to opt-in to expect/continue handling when sending a POST and we're authenticated with a "connection-based" authentication mechanism like NTLM or Negotiate. If the response is a 100, return to the caller (to allow them to post their body). If the response is *not* a 100, buffer the response for the caller. HTTP expect/continue is generally safe, but some legacy servers have not implemented it correctly. Require it to be opt-in.

6c21c989

2019-12-14T21:32:07

httpclient: support CONNECT proxies Fully support HTTP proxies, in particular CONNECT proxies, that allow us to speak TLS through a proxy.

6b208836

2019-12-18T21:55:28

httpclient: handle chunked responses Detect responses that are sent with Transfer-Encoding: chunked, and record that information so that we can consume the entire message body.

6a095679

2019-12-14T10:34:36

httpclient: support authentication Store the last-seen credential challenges (eg, all the 'WWW-Authenticate' headers in a response message). Given some credentials, find the best (first) challenge whose mechanism supports these credentials. (eg, 'Basic' supports username/password credentials, 'Negotiate' supports default credentials). Set up an authentication context for this mechanism and these credentials. Continue exchanging challenge/responses until we're authenticated.

1152f361

2019-12-13T18:37:19

httpclient: consume final chunk message When sending a new request, ensure that we got the entirety of the response body. Our caller may have decided that they were done reading. If we were not at the end of the message, this means that we need to tear down the connection and cannot do keep-alive. However, if the caller read all of the message, but we still have a final end-of-response chunk signifier (ie, "0\r\n\r\n") on the socket, then we should consider that the response was successfully copmleted. If we're asked to send a new request, try to read from the socket, just to clear out that end-of-chunk message, marking ourselves as disconnected on any errors.

84b99a95

2019-12-12T13:53:43

httpclient: add chunk support to POST Teach httpclient how to support chunking when POSTing request bodies.

eacecebd

2019-12-12T13:25:32

httpclient: introduce a simple http implementation Introduce a new http client implementation that can GET and POST to remote URLs. Consumers can use `git_http_client_init` to create a new client, `git_http_client_send_request` to send a request to the remote server and `git_http_client_read_response` to read the response. The http client implementation will perform the I/O with the remote server (http or https) but does not understand the git smart transfer protocol. This allows us to split the concerns of the http subtransport from the actual http implementation.

471daeea

2019-12-01T14:00:49

net: refactor gitno redirect handling Move the redirect handling into `git_net_url` for consistency.

a194e17f

2019-11-27T18:43:36

winhttp: refactor request sending Clarify what it means to not send a length; this allows us to refactor requests further.

7e0f5a6a

2019-10-22T22:37:14

smart protocol: correct case in error messages

2d6a61bd

2019-10-22T09:52:31

gssapi: validate that we were requested Negotiate

e761df5c

2019-10-22T09:35:48

gssapi: dispose after completion for retry Disposal pattern; dispose on completion, allowing us to retry authentication, which may happen on web servers that close connection-based authenticated sessions (NTLM/SPNEGO) unexpectedly.

5625892b

2019-09-20T12:06:11

gssapi: delete half-built security context so auth can continue

2174aa0a

2019-10-21T11:47:23

gssapi: correct incorrect case in error message

3f6fe054

2019-10-20T17:23:01

gssapi: protect GSS_ERROR macro The GSS_ERROR(x) macro may expand to `(x & value)` on some implementations, instead of `((x) & value)`. This is the case on macOS, which means that if we attempt to wrap an expression in that macro, like `a = b`, then that would expand to `(a = b & value)`. Since `&` has a higher precedence, this is not at all what we want, and will set our result code to an incorrect value. Evaluate the expression then test it with `GSS_ERROR` independently to avoid this.

73fe690d

2019-10-20T17:22:27

gssapi: protect against empty messages

917ba762

2020-01-18T14:14:00

auth: update enum type name for consistency libgit2 does not use `type_t` suffixes as it's redundant; thus, rename `git_http_authtype_t` to `git_http_auth_t` for consistency.

dbb6429c

2020-01-10T14:30:18

Merge pull request #5305 from kas-luthor/bugfix/multiple-auth Adds support for multiple SSH auth mechanisms being used sequentially

33f93bf3

2020-01-06T11:53:53

Merge pull request #5325 from josharian/no-double-slash http: avoid generating double slashes in url

05c1fb8a

2019-12-06T11:04:40

http: avoid generating double slashes in url Prior to this change, given a remote url with a trailing slash, such as http://localhost/a/, service requests would contain a double slash: http://localhost/a//info/refs?service=git-receive-pack. Detect and prevent that. Updates #5321

cb7fd1ed

2019-12-13T15:11:38

Fixes code styling

86852613

2019-12-13T12:13:05

smart_pkt: fix overflow resulting in OOB read/write of one byte When parsing OK packets, we copy any information after the initial "ok " prefix into the resulting packet. As newlines act as packet boundaries, we also strip the trailing newline if there is any. We do not check whether there is any data left after the initial "ok " prefix though, which leads to a pointer overflow in that case as `len == 0`: if (line[len - 1] == '\n') --len; This out-of-bounds read is a rather useless gadget, as we can only deduce whether at some offset there is a newline character. In case there accidentally is one, we overflow `len` to `SIZE_MAX` and then write a NUL byte into an array indexed by it: pkt->ref[len] = '\0'; Again, this doesn't seem like something that's possible to be exploited in any meaningful way, but it may surely lead to inconsistencies or DoS. Fix the issue by checking whether there is any trailing data after the packet prefix.

48c3f7e1

2019-11-20T11:21:14

ssh: include sha256 host key hash when supported

fbdf5bdd

2019-11-16T22:41:25

Adds support for multiple SSH auth mechanisms being used sequentially

3f998aee

2019-10-26T17:21:29

Follow 308 redirect in WinHTTP transport

dbc17a7e

2019-09-21T08:46:08

negotiate: use GSS.framework on macOS

49a3289e

2019-09-21T08:25:23

cred: add missing private header in GSSAPI block Should have been part of 8bf0f7eb26c65b2b937b1f40a384b9b269b0b76d

8bf0f7eb

2019-09-09T13:00:27

cred: separate public interface from low-level details

5d8a4659

2019-09-13T10:31:49

Merge pull request #5195 from tiennou/fix/commitish-smart-push smart: use push_glob instead of manual filtering

39028eb6

2019-09-09T13:00:53

Merge pull request #5212 from libgit2/ethomson/creds_for_scheme Use an HTTP scheme that supports the given credentials

4de51f9e

2019-08-23T16:05:28

http: ensure the scheme supports the credentials When a server responds with multiple scheme support - for example, Negotiate and NTLM are commonly used together - we need to ensure that we choose a scheme that supports the credentials.

53f51c60

2019-08-21T19:48:05

smart: implement by-date insertion when revwalking

c2dd895a

2019-08-08T10:47:29

transports: http: check for memory allocation failures When allocating a chunk that is used to write to HTTP streams, we do not check for memory allocation errors. This may lead us to write to a `NULL` pointer and thus cause a segfault. Fix this by adding a call to `GIT_ERROR_CHECK_ALLOC`.

1c847169

2019-08-21T16:38:59

http: allow dummy negotiation scheme to fail to act The dummy negotiation scheme is used for known authentication strategies that do not wish to act. For example, when a server requests the "Negotiate" scheme but libgit2 is not built with Negotiate support, and will use the "dummy" strategy which will simply not act. Instead of setting `out` to NULL and returning a successful code, return `GIT_PASSTHROUGH` to indicate that it did not act and catch that error code.

39d18fe6

2019-07-31T08:37:10

smart: use push_glob instead of manual filtering The code worked under the assumption that anything under `refs/tags` are tag objects, and all the rest would be peelable to a commit. As it is completely valid to have tags to blobs under a non `refs/tags` ref, this would cause failures when trying to peel a tag to a commit. Fix the broken filtering by switching to `git_revwalk_push_glob`, which already handles this case.

3cd123e9

2019-06-15T21:56:53

win32: define DWORD_MAX if it's not defined MinGW does not define DWORD_MAX. Specify it when it's not defined.

d93b0aa0

2019-06-15T21:47:40

win32: decorate unused parameters

8c925ef8

2019-05-21T14:30:28

smart protocol: validate progress message length Ensure that the server has not sent us overly-large sideband messages (ensure that they are no more than `INT_MAX` bytes), then cast to `int`.

7afe788c

2019-05-21T14:27:46

smart transport: use size_t for sizes

db7f1d9b

2019-05-21T14:21:58

local transport: cast message size to int explicitly Our progress information messages are short (and bounded by their format string), cast the length to int for callers.

8048ba70

2019-05-21T14:18:40

winhttp: safely cast length to DWORD

2a4bcf63

2019-06-23T18:24:23

errors: use lowercase Use lowercase for our error messages, per our custom.

5d92e547

2019-06-08T17:28:35

oid: `is_zero` instead of `iszero` The only function that is named `issomething` (without underscore) was `git_oid_iszero`. Rename it to `git_oid_is_zero` for consistency with the rest of the library.

0b5ba0d7

2019-06-06T16:36:23

Rename opt init functions to `options_init` In libgit2 nomenclature, when we need to verb a direct object, we name a function `git_directobject_verb`. Thus, if we need to init an options structure named `git_foo_options`, then the name of the function that does that should be `git_foo_options_init`. The previous names of `git_foo_init_options` is close - it _sounds_ as if it's initializing the options of a `foo`, but in fact `git_foo_options` is its own noun that should be respected. Deprecate the old names; they'll now call directly to the new ones.

7ea8630e

2019-04-07T20:11:59

http: free auth context on failure When we send HTTP credentials but the server rejects them, tear down the authentication context so that we can start fresh. To maintain this state, additionally move all of the authentication handling into `on_auth_required`.

005b5bc2

2019-04-07T17:55:23

http: reconnect to proxy on connection close When we're issuing a CONNECT to a proxy, we expect to keep-alive to the proxy. However, during authentication negotiations, the proxy may close the connection. Reconnect if the server closes the connection.

d171fbee

2019-04-07T17:40:23

http: allow server to drop a keepalive connection When we have a keep-alive connection to the server, that server may legally drop the connection for any reason once a successful request and response has occurred. It's common for servers to drop the connection after some amount of time or number of requests have occurred.

9af1de5b

2019-03-24T20:49:57

http: stop on server EOF We stop the read loop when we have read all the data. We should also consider the server's feelings. If the server hangs up on us, we need to stop our read loop. Otherwise, we'll try to read from the server - and fail - ad infinitum.

539e6293

2019-03-22T19:06:46

http: teach auth mechanisms about connection affinity Instead of using `is_complete` to decide whether we have connection or request affinity for authentication mechanisms, set a boolean on the mechanism definition itself.

3e0b4b43

2019-03-22T18:52:03

http: maintain authentication across connections For request-based authentication mechanisms (Basic, Digest) we should keep the authentication context alive across socket connections, since the authentication headers must be transmitted with every request. However, we should continue to remove authentication contexts for mechanisms with connection affinity (NTLM, Negotiate) since we need to reauthenticate for every socket connection.

ce72ae95

2019-03-22T10:53:30

http: simplify authentication mechanisms Hold an individual authentication context instead of trying to maintain all the contexts; we can select the preferred context during the initial negotiation. Subsequent authentication steps will re-use the chosen authentication (until such time as it's rejected) instead of trying to manage multiple contexts when all but one will never be used (since we can only authenticate with a single mechanism at a time.) Also, when we're given a 401 or 407 in the middle of challenge/response handling, short-circuit immediately without incrementing the retry count. The multi-step authentication is expected, and not a "retry" and should not be penalized as such. This means that we don't need to keep the contexts around and ensures that we do not unnecessarily fail for too many retries when we have challenge/response auth on a proxy and a server and potentially redirects in play as well.

6d931ba7

2019-03-22T16:35:59

http: don't set the header in the auth token

10718526

2019-03-09T13:53:16

http: don't reset replay count after connection A "connection" to a server is transient, and we may reconnect to a server in the midst of authentication failures (if the remote indicates that we should, via `Connection: close`) or in a redirect.

3192e3c9

2019-03-07T16:57:11

http: provide an NTLM authentication provider

79fc8281

2019-03-21T16:49:25

http: validate server's authentication types Ensure that the server supports the particular credential type that we're specifying. Previously we considered credential types as an input to an auth mechanism - since the HTTP transport only supported default credentials (via negotiate) and username/password credentials (via basic), this worked. However, if we are to add another mechanism that uses username/password credentials, we'll need to be careful to identify the types that are accepted.

5ad99210

2019-03-07T16:43:45

http: consume body on proxy auth failure We must always consume the full parser body if we're going to keep-alive. So in the authentication failure case, continue advancing the http message parser until it's complete, then we can retry the connection. Not doing so would mean that we have to tear the connection down and start over. Advancing through fully (even though we don't use the data) will ensure that we can retry a connection with keep-alive.

75b20458

2019-03-07T16:34:55

http: always consume body on auth failure When we get an authentication failure, we must consume the entire body of the response. If we only read half of the body (on the assumption that we can ignore the rest) then we will never complete the parsing of the message. This means that we will never set the complete flag, and our replay must actually tear down the connection and try again. This is particularly problematic for stateful authentication mechanisms (SPNEGO, NTLM) that require that we keep the connection alive. Note that the prior code is only a problem when the 401 that we are parsing is too large to be read in a single chunked read from the http parser. But now we will continue to invoke the http parser until we've got a complete message in the authentication failed scenario. Note that we need not do anything with the message, so when we get an authentication failed, we'll stop adding data to our buffer, we'll simply loop in the parser and let it advance its internal state.

e87f912b

2019-03-21T15:29:52

http: don't realloc the request

10e8fe55

2019-03-21T13:55:54

transports: add an `is_complete` function for auth Some authentication mechanisms (like HTTP Basic and Digest) have a one-step mechanism to create credentials, but there are more complex mechanisms like NTLM and Negotiate that require challenge/response after negotiation, requiring several round-trips. Add an `is_complete` function to know when they have round-tripped enough to be a single authentication and should now either have succeeded or failed to authenticate.

9050c69c

2019-03-09T17:24:16

http: examine keepalive status at message end We cannot examine the keep-alive status of the http parser in `http_connect`; it's too late and the critical information about whether keep-alive is supported has been destroyed. Per the documentation for `http_should_keep_alive`: > If http_should_keep_alive() in the on_headers_complete or > on_message_complete callback returns 0, then this should be > the last message on the connection. Query then and set the state.

thodg/libgit2/src/transports

src/transports

Log