|
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.
|
|
|
956ba48b
|
2019-03-14T10:36:40
|
|
http: increase the replay count
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.
|
|
|
ee3d35cf
|
2019-04-07T19:15:21
|
|
http: support https for proxies
|
|
|
3d11b6c5
|
2019-03-11T20:36:09
|
|
winhttp: support default credentials for proxies
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.
|