- 13 Jan, 2022 2 commits
-
-
Give callers the ability to select how to handle redirects - either supporting redirects during the initial connection (so that, for example, `git.example.com/repo` can redirect to `github.com/example/repo`) or all/no redirects. This is for compatibility with git.
Edward Thomson committed -
In redirect application logic, (optionally) allow off-site redirects.
Edward Thomson committed
-
- 06 Jan, 2022 1 commit
-
-
The existing mechanism for providing options to remote fetch/push calls, and subsequently to transports, is unsatisfactory. It requires an options structure to avoid breaking the API and callback signatures. 1. Introduce `git_remote_connect_options` to satisfy those needs. 2. Add a new remote connection API, `git_remote_connect_ext` that will take this new options structure. Existing `git_remote_connect` calls will proxy to that. `git_remote_fetch` and `git_remote_push` will proxy their fetch/push options to that as well. 3. Define the interaction between `git_remote_connect` and fetch/push. Connect _may_ be called before fetch/push, but _need not_ be. The semantics of which options would be used for these operations was not specified if you specify options for both connect _and_ fetch. Now these are defined that the fetch or push options will be used _if_ they were specified. Otherwise, the connect options will be used if they were specified. Otherwise, the library's defaults will be used. 4. Update the transports to understand `git_remote_connect_options`. This is a breaking change to the systems API.
Edward Thomson committed
-
- 17 Oct, 2021 1 commit
-
-
libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
Edward Thomson committed
-
- 02 Sep, 2021 2 commits
-
-
Update the proxy detection for a remote. 1. Honor `http.<url>.proxy` syntax for a remote's direct URL and parent URLs. 2. Honor an empty configuration URL to override a proxy configuration. Add tests to ensure that configuration specificity is honored.
Edward Thomson committed -
Item 2 of 3 from #4164 Signed-off-by: Mathieu Parent <math.parent@gmail.com>
Mathieu Parent committed
-
- 05 Aug, 2021 1 commit
-
-
Attempt authentication when a username is presented but a password is not; this can happen in particular when users are doing token authentication and specifying the token in the URL itself. For example, `https://token@host/` is a valid URI and should be treated as a username of `token` with an empty password.
Edward Thomson committed
-
- 27 Nov, 2020 1 commit
-
-
Edward Thomson committed
-
- 11 Oct, 2020 1 commit
-
-
Provide a mechanism for system components to register for initialization and shutdown of the libgit2 runtime.
Edward Thomson committed
-
- 07 Feb, 2020 2 commits
-
-
When the failure is clearly an auth failure (as opposed to possibly an auth failure), use the error code GIT_EAUTH instead of GIT_ERROR. While we're here, fix a typo and improve an error message. Fixes #5389.
Josh Bleecher Snyder committed -
In commit b9c5b15a (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.
Patrick Steinhardt committed
-
- 26 Jan, 2020 1 commit
-
-
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.
Edward Thomson committed
-
- 24 Jan, 2020 6 commits
-
-
Disambiguate between general network problems and HTTP problems in error codes.
Edward Thomson committed -
Edward Thomson committed
-
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.
Edward Thomson committed -
Untangle the notion of the http transport from the actual http implementation. The http transport now uses the httpclient.
Edward Thomson committed -
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.
Edward Thomson committed -
Move the redirect handling into `git_net_url` for consistency.
Edward Thomson committed
-
- 18 Jan, 2020 1 commit
-
-
libgit2 does not use `type_t` suffixes as it's redundant; thus, rename `git_http_authtype_t` to `git_http_auth_t` for consistency.
Edward Thomson committed
-
- 13 Dec, 2019 1 commit
-
-
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
Josh Bleecher Snyder committed
-
- 13 Sep, 2019 1 commit
-
-
Etienne Samson committed
-
- 23 Aug, 2019 2 commits
-
-
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.
Ian Hattendorf committed -
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`.
Patrick Steinhardt committed
-
- 21 Aug, 2019 1 commit
-
-
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.
Edward Thomson committed
-
- 14 Jun, 2019 1 commit
-
-
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.
Edward Thomson committed
-
- 10 Jun, 2019 15 commits
-
-
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`.
Edward Thomson committed -
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.
Edward Thomson committed -
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.
Edward Thomson committed -
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.
Edward Thomson committed -
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.
Edward Thomson committed -
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.
Edward Thomson committed -
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.
Edward Thomson committed -
Edward Thomson committed
-
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.
Edward Thomson committed -
Edward Thomson committed
-
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.
Edward Thomson committed -
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.
Edward Thomson committed -
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.
Edward Thomson committed -
Edward Thomson committed
-
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.
Edward Thomson committed
-