summaryrefslogtreecommitdiff
path: root/src/transports
Commit message (Collapse)AuthorAgeFilesLines
* http: free auth context on failureethomson/netrefactorEdward Thomson2019-06-101-50/+63
| | | | | | | 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`.
* http: reconnect to proxy on connection closeEdward Thomson2019-06-101-3/+15
| | | | | | 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.
* http: allow server to drop a keepalive connectionEdward Thomson2019-06-101-0/+15
| | | | | | | 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.
* http: stop on server EOFEdward Thomson2019-06-101-2/+12
| | | | | | | | 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.
* http: teach auth mechanisms about connection affinityEdward Thomson2019-06-105-1/+7
| | | | | | 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.
* http: maintain authentication across connectionsEdward Thomson2019-06-101-6/+38
| | | | | | | | | | 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.
* http: simplify authentication mechanismsEdward Thomson2019-06-101-166/+156
| | | | | | | | | | | | | | | | | | | | | 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.
* http: don't set the header in the auth tokenEdward Thomson2019-06-105-21/+25
|
* http: don't reset replay count after connectionEdward Thomson2019-06-101-1/+0
| | | | | | 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.
* http: provide an NTLM authentication providerEdward Thomson2019-06-104-0/+261
|
* http: validate server's authentication typesEdward Thomson2019-06-101-42/+97
| | | | | | | | | | 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.
* http: consume body on proxy auth failureEdward Thomson2019-06-101-4/+9
| | | | | | | | | | | 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.
* http: always consume body on auth failureEdward Thomson2019-06-101-26/+25
| | | | | | | | | | | | | | | | | | | | | 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.
* http: don't realloc the requestEdward Thomson2019-06-101-33/+29
|
* transports: add an `is_complete` function for authEdward Thomson2019-06-103-0/+14
| | | | | | | | | | 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.
* http: examine keepalive status at message endEdward Thomson2019-06-101-3/+4
| | | | | | | | | | | | | | 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.
* http: increase the replay countEdward Thomson2019-06-102-2/+2
| | | | | | | | | Increase the permissible replay count; with multiple-step authentication schemes (NTLM, Negotiate), proxy authentication and redirects, we need to be mindful of the number of steps it takes to get connected. 7 seems high but can be exhausted quickly with just a single authentication failure over a redirected multi-state authentication pipeline.
* http: support https for proxiesEdward Thomson2019-06-101-8/+1
|
* winhttp: support default credentials for proxiesEdward Thomson2019-06-101-189/+199
| | | | | | | | | | | | | | | | | | | | | | | | | We did not properly support default credentials for proxies, only for destination servers. Refactor the credential handling to support sending either username/password _or_ default credentials to either the proxy or the destination server. This actually shares the authentication logic between proxy servers and destination servers. Due to copy/pasta drift over time, they had diverged. Now they share a common logic which is: first, use credentials specified in the URL (if there were any), treating empty username and password (ie, "http://:@foo.com/") as default credentials, for compatibility with git. Next, call the credential callbacks. Finally, fallback to WinHTTP compatibility layers using built-in authentication like we always have. Allowing default credentials for proxies requires moving the security level downgrade into the credential setting routines themselves. We will update our security level to "high" by default which means that we will never send default credentials without prompting. (A lower setting, like the WinHTTP default of "medium" would allow WinHTTP to handle credentials for us, despite what a user may have requested with their structures.) Now we start with "high" and downgrade to "low" only after a user has explicitly requested default credentials.
* net: rename gitno_connection_data to git_net_urlEdward Thomson2019-06-108-124/+109
| | | | | | | | | | "Connection data" is an imprecise and largely incorrect name; these structures are actually parsed URLs. Provide a parser that takes a URL string and produces a URL structure (if it is valid). Separate the HTTP redirect handling logic from URL parsing, keeping a `gitno_connection_data_handle_redirect` whose only job is redirect handling logic and does not parse URLs itself.
* credentials: suffix the callbacks with `_cb`Edward Thomson2019-06-101-2/+2
| | | | | The credential callbacks should match the other callback naming conventions, using the `_cb` suffix instead of a `_callback` suffix.
* transports: make use of the `GIT_CONTAINER_OF` macroEtienne Samson2019-04-163-26/+26
|
* remote: rename git_push_transfer_progress callbackEdward Thomson2019-02-221-1/+1
| | | | | | The `git_push_transfer_progress` is a callback and as such should be suffixed with `_cb` for consistency. Rename `git_push_transfer_progress` to `git_push_transfer_progress_cb`.
* indexer: use git_indexer_progress throughoutEdward Thomson2019-02-223-18/+18
| | | | | Update internal usage of `git_transfer_progress` to `git_indexer_progreses`.
* streams: fix callers potentially only writing partial dataPatrick Steinhardt2019-01-312-23/+19
| | | | | | | | | | | | | | | | | | | | | Similar to the write(3) function, implementations of `git_stream_write` do not guarantee that all bytes are written. Instead, they return the number of bytes that actually have been written, which may be smaller than the total number of bytes. Furthermore, due to an interface design issue, we cannot ever write more than `SSIZE_MAX` bytes at once, as otherwise we cannot represent the number of bytes written to the caller. Unfortunately, no caller of `git_stream_write` ever checks the return value, except to verify that no error occurred. Due to this, they are susceptible to the case where only partial data has been written. Fix this by introducing a new function `git_stream__write_full`. In contrast to `git_stream_write`, it will always return either success or failure, without returning the number of bytes written. Thus, it is able to write all `SIZE_MAX` bytes and loop around `git_stream_write` until all data has been written. Adjust all callers except the BIO callbacks in our mbedtls and OpenSSL streams, which already do the right thing and require the amount of bytes written.
* git transport: only write INT_MAX bytesEdward Thomson2019-01-251-5/+9
| | | | | The transport code returns an `int` with the number of bytes written; thus only attempt to write at most `INT_MAX`.
* Don't use deprecated constantsSven Strickroth2019-01-241-2/+2
| | | | | | Follow up for PR #4917. Signed-off-by: Sven Strickroth <email@cs-ware.de>
* git_error: use new names in internal APIs and usageEdward Thomson2019-01-2211-255/+255
| | | | | Move to the `git_error` name in the internal API for error-related functions.
* Merge pull request #4939 from libgit2/ethomson/git_refEdward Thomson2019-01-192-3/+3
|\ | | | | Move `git_ref_t` to `git_reference_t`
| * references: use new names in internal usageethomson/git_refEdward Thomson2019-01-172-3/+3
| | | | | | | | Update internal usage to use the `git_reference` names for constants.
* | Merge pull request #4925 from lhchavez/fix-a-bunch-of-warningsEdward Thomson2019-01-171-32/+4
|\ \ | |/ |/| Fix a bunch of warnings
| * Windows is hard.lhchavez2019-01-061-1/+1
| |
| * Fix a bunch of warningslhchavez2019-01-051-32/+4
| | | | | | | | | | | | | | | | | | | | | | This change fixes a bunch of warnings that were discovered by compiling with `clang -target=i386-pc-linux-gnu`. It turned out that the intrinsics were not necessarily being used in all platforms! Especially in GCC, since it does not support __has_builtin. Some more warnings were gleaned from the Windows build, but I stopped when I saw that some third-party dependencies (e.g. zlib) have warnings of their own, so we might never be able to enable -Werror there.
* | proxy: fix crash on remote connection with GIT_PROXY_AUTO but no proxy is ↵Jason Haslam2019-01-141-0/+3
|/ | | | detected
* object_type: use new enumeration namesethomson/index_fixesEdward Thomson2018-12-011-4/+4
| | | | Use the new object_type enumeration names within the codebase.
* http: reset replay_count upon connectionethomson/proxyEdward Thomson2018-11-281-0/+1
| | | | | | | | | Reset the replay_count upon a successful connection. It's possible that we could encounter a situation where we connect successfully but need to replay a request - for example, a connection and initial request succeeds without authentication but a subsequent call does require authentication. Reset the replay count upon any successful request to afford subsequent replays room to manuever.
* http: don't allow SSL connections to a proxyEdward Thomson2018-11-281-1/+9
| | | | | Temporarily disallow SSL connections to a proxy until we can understand the valgrind warnings when tunneling OpenSSL over OpenSSL.
* http: only load proxy configuration during connectionEdward Thomson2018-11-281-2/+4
| | | | | | | | | | | | Only load the proxy configuration during connection; we need this data when we're going to connect to the server, however we may mutate it after connection (connecting through a CONNECT proxy means that we should send requests like normal). If we reload the proxy configuration but do not actually reconnect (because we're in a keep-alive session) then we will reload the proxy configuration that we should have mutated. Thus, only load the proxy configuration when we know that we're going to reconnect.
* http: disallow repeated headers from serversEdward Thomson2018-11-281-9/+18
| | | | | Don't allow servers to send us multiple Content-Type, Content-Length or Location headers.
* http: remove cURLEdward Thomson2018-11-281-23/+0
| | | | | We previously used cURL to support HTTP proxies. Now that we've added this support natively, we can remove the curl dependency.
* http: use CONNECT to talk to proxiesEdward Thomson2018-11-281-13/+224
| | | | | Natively support HTTPS connections through proxies by speaking CONNECT to the proxy and then adding a TLS connection on top of the socket.
* tls: introduce a wrap functionEdward Thomson2018-11-281-17/+36
| | | | | | | | | | | Introduce `git_tls_stream_wrap` which will take an existing `stream` with an already connected socket and begin speaking TLS on top of it. This is useful if you've built a connection to a proxy server and you wish to begin CONNECT over it to tunnel a TLS connection. Also update the pluggable TLS stream layer so that it can accept a registration structure that provides an `init` and `wrap` function, instead of a single initialization function.
* http transport: reset error message on cert failureEdward Thomson2018-11-281-11/+11
| | | | | | | | Store the error message from the underlying TLS library before calling the certificate callback. If it refuses to act (demonstrated by returning GIT_PASSTHROUGH) then restore the error message. Otherwise, if the callback does not set an error message, set a sensible default that implicates the callback itself.
* http transport: support cert check for proxiesEdward Thomson2018-11-281-39/+70
| | | | | Refactor certificate checking so that it can easily be called for proxies or the remote server.
* http transport: provide proxy credentialsEdward Thomson2018-11-284-8/+19
|
* http transport: refactor storageEdward Thomson2018-11-281-120/+133
| | | | | | | Create a simple data structure that contains information about the server being connected to, whether that's the actual remote endpoint (git server) or an intermediate proxy. This allows for organization of streams, authentication state, etc.
* http transport: cap number of authentication replaysEdward Thomson2018-11-283-9/+10
| | | | | | Put a limit on the number of authentication replays in the HTTP transport. Standardize on 7 replays for authentication or redirects, which matches the behavior of the WinHTTP transport.
* http transport: prompt for proxy credentialsEdward Thomson2018-11-281-19/+37
| | | | Teach the HTTP transport how to prompt for proxy credentials.
* http transport: further refactor credential handlingEdward Thomson2018-11-281-17/+32
| | | | | Prepare credential handling to understand both git server and proxy server authentication.
* http transport: refactor credential handlingEdward Thomson2018-11-281-47/+58
| | | | | | | Factor credential handling into its own function. Additionally, add safety checks to ensure that we are in a valid state - that we have received a valid challenge from the server and that we have configuration to respond to that challenge.
View Lorry Controller Status