2014-09-14 09:40:45 +02:00
|
|
|
#include "git-compat-util.h"
|
http: centralize the accounting of libcurl dependencies
As discussed in 644de29e220 (http: drop support for curl < 7.19.4,
2021-07-30) checking against LIBCURL_VERSION_NUM isn't as reliable as
checking specific symbols present in curl, as some distros have been
known to backport features.
However, while some of the curl_easy_setopt() arguments we rely on are
macros, others are enum, and we can't assume that those that are
macros won't change into enums in the future.
So we're still going to have to check LIBCURL_VERSION_NUM, but by
doing that in one central place and using a macro definition of our
own, anyone who's backporting features can define it themselves, and
thus have access to more modern curl features that they backported,
even if they didn't bump the LIBCURL_VERSION_NUM.
More importantly, as shown in a preceding commit doing these version
checks makes for hard to read and possibly buggy code, as shown by the
bug fixed there where we were conflating base 10 for base 16 when
comparing the version.
By doing them all in one place we'll hopefully reduce the chances of
such future mistakes, furthermore it now becomes easier to see at a
glance what the oldest supported version is, which makes it easier to
reason about any future deprecation similar to the recent
e48a623dea0 (Merge branch 'ab/http-drop-old-curl', 2021-08-24).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-13 16:51:28 +02:00
|
|
|
#include "git-curl-compat.h"
|
2005-11-18 20:02:58 +01:00
|
|
|
#include "http.h"
|
2017-06-14 20:07:36 +02:00
|
|
|
#include "config.h"
|
2009-06-06 10:44:01 +02:00
|
|
|
#include "pack.h"
|
2009-10-31 01:47:41 +01:00
|
|
|
#include "sideband.h"
|
2010-04-19 16:23:09 +02:00
|
|
|
#include "run-command.h"
|
2010-11-14 02:51:15 +01:00
|
|
|
#include "url.h"
|
2013-08-05 22:20:36 +02:00
|
|
|
#include "urlmatch.h"
|
http: use credential API to get passwords
This patch converts the http code to use the new credential
API, both for http authentication as well as for getting
certificate passwords.
Most of the code change is simply variable naming (the
passwords are now contained inside the credential struct)
or deletion of obsolete code (the credential code handles
URL parsing and prompting for us).
The behavior should be the same, with one exception: the
credential code will prompt with a description based on the
credential components. Therefore, the old prompt of:
Username for 'example.com':
Password for 'example.com':
now looks like:
Username for 'https://example.com/repo.git':
Password for 'https://user@example.com/repo.git':
Note that we include more information in each line,
specifically:
1. We now include the protocol. While more noisy, this is
an important part of knowing what you are accessing
(especially if you care about http vs https).
2. We include the username in the password prompt. This is
not a big deal when you have just been prompted for it,
but the username may also come from the remote's URL
(and after future patches, from configuration or
credential helpers). In that case, it's a nice
reminder of the user for which you're giving the
password.
3. We include the path component of the URL. In many
cases, the user won't care about this and it's simply
noise (i.e., they'll use the same credential for a
whole site). However, that is part of a larger
question, which is whether path components should be
part of credential context, both for prompting and for
lookup by storage helpers. That issue will be addressed
as a whole in a future patch.
Similarly, for unlocking certificates, we used to say:
Certificate Password for 'example.com':
and we now say:
Password for 'cert:///path/to/certificate':
Showing the path to the client certificate makes more sense,
as that is what you are unlocking, not "example.com".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-10 11:31:21 +01:00
|
|
|
#include "credential.h"
|
2012-06-02 21:03:08 +02:00
|
|
|
#include "version.h"
|
2013-02-20 21:02:45 +01:00
|
|
|
#include "pkt-line.h"
|
2015-02-26 04:04:16 +01:00
|
|
|
#include "gettext.h"
|
http: limit redirection to protocol-whitelist
Previously, libcurl would follow redirection to any protocol
it was compiled for support with. This is desirable to allow
redirection from HTTP to HTTPS. However, it would even
successfully allow redirection from HTTP to SFTP, a protocol
that git does not otherwise support at all. Furthermore
git's new protocol-whitelisting could be bypassed by
following a redirect within the remote helper, as it was
only enforced at transport selection time.
This patch limits redirects within libcurl to HTTP, HTTPS,
FTP and FTPS. If there is a protocol-whitelist present, this
list is limited to those also allowed by the whitelist. As
redirection happens from within libcurl, it is impossible
for an HTTP redirect to a protocol implemented within
another remote helper.
When the curl version git was compiled with is too old to
support restrictions on protocol redirection, we warn the
user if GIT_ALLOW_PROTOCOL restrictions were requested. This
is a little inaccurate, as even without that variable in the
environment, we would still restrict SFTP, etc, and we do
not warn in that case. But anything else means we would
literally warn every time git accesses an http remote.
This commit includes a test, but it is not as robust as we
would hope. It redirects an http request to ftp, and checks
that curl complained about the protocol, which means that we
are relying on curl's specific error message to know what
happened. Ideally we would redirect to a working ftp server
and confirm that we can clone without protocol restrictions,
and not with them. But we do not have a portable way of
providing an ftp server, nor any other protocol that curl
supports (https is the closest, but we would have to deal
with certificates).
[jk: added test and version warning]
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-23 00:06:04 +02:00
|
|
|
#include "transport.h"
|
2017-08-19 00:20:16 +02:00
|
|
|
#include "packfile.h"
|
2017-10-16 19:55:29 +02:00
|
|
|
#include "protocol.h"
|
2018-01-19 01:28:01 +01:00
|
|
|
#include "string-list.h"
|
2018-03-23 18:20:59 +01:00
|
|
|
#include "object-store.h"
|
2005-11-18 20:02:58 +01:00
|
|
|
|
2016-05-23 15:44:02 +02:00
|
|
|
static struct trace_key trace_curl = TRACE_KEY_INIT(CURL);
|
2018-01-19 01:28:02 +01:00
|
|
|
static int trace_curl_data = 1;
|
2020-06-05 23:21:36 +02:00
|
|
|
static int trace_curl_redact = 1;
|
2016-02-03 05:09:14 +01:00
|
|
|
long int git_curl_ipresolve = CURL_IPRESOLVE_WHATEVER;
|
2009-03-10 02:47:29 +01:00
|
|
|
int active_requests;
|
2009-06-06 10:43:41 +02:00
|
|
|
int http_is_verbose;
|
2017-04-11 20:13:57 +02:00
|
|
|
ssize_t http_post_buffer = 16 * LARGE_PACKET_MAX;
|
2005-11-18 20:02:58 +01:00
|
|
|
|
2009-11-27 16:42:26 +01:00
|
|
|
static int min_curl_sessions = 1;
|
|
|
|
static int curl_session_count;
|
2007-12-09 18:04:57 +01:00
|
|
|
static int max_requests = -1;
|
|
|
|
static CURLM *curlm;
|
|
|
|
static CURL *curl_default;
|
http*: add helper methods for fetching objects (loose)
The code handling the fetching of loose objects in http-push.c and
http-walker.c have been refactored into new methods and a new struct
(object_http_request) in http.c. They are not meant to be invoked
elsewhere.
The new methods in http.c are
- new_http_object_request
- process_http_object_request
- finish_http_object_request
- abort_http_object_request
- release_http_object_request
and the new struct is http_object_request.
RANGER_HEADER_SIZE and no_pragma_header is no longer made available
outside of http.c, since after the above changes, there are no other
instances of usage outside of http.c.
Remove members of the transfer_request struct in http-push.c and
http-walker.c, including filename, real_sha1 and zret, as they are used
no longer used.
Move the methods append_remote_object_url() and get_remote_object_url()
from http-push.c to http.c. Additionally, get_remote_object_url() is no
longer defined only when USE_CURL_MULTI is defined, since
non-USE_CURL_MULTI code in http.c uses it (namely, in
new_http_object_request()).
Refactor code from http-push.c::start_fetch_loose() and
http-walker.c::start_object_fetch_request() that deals with the details
of coming up with the filename to store the retrieved object, resuming
a previously aborted request, and making a new curl request, into a new
function, new_http_object_request().
Refactor code from http-walker.c::process_object_request() into the
function, process_http_object_request().
Refactor code from http-push.c::finish_request() and
http-walker.c::finish_object_request() into a new function,
finish_http_object_request(). It returns the result of the
move_temp_to_file() invocation.
Add a function, release_http_object_request(), which cleans up object
request data. http-push.c and http-walker.c invoke this function
separately; http-push.c::release_request() and
http-walker.c::release_object_request() do not invoke this function.
Add a function, abort_http_object_request(), which unlink()s the object
file and invokes release_http_object_request(). Update
http-walker.c::abort_object_request() to use this.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-06 10:44:02 +02:00
|
|
|
|
|
|
|
#define PREV_BUF_SIZE 4096
|
|
|
|
|
2005-11-18 20:02:58 +01:00
|
|
|
char curl_errorstr[CURL_ERROR_SIZE];
|
|
|
|
|
2007-12-09 18:04:57 +01:00
|
|
|
static int curl_ssl_verify = -1;
|
2013-04-07 21:10:39 +02:00
|
|
|
static int curl_ssl_try;
|
2018-11-09 04:44:14 +01:00
|
|
|
static const char *curl_http_version = NULL;
|
2009-03-10 02:47:29 +01:00
|
|
|
static const char *ssl_cert;
|
2015-05-08 15:22:15 +02:00
|
|
|
static const char *ssl_cipherlist;
|
2015-08-14 21:37:43 +02:00
|
|
|
static const char *ssl_version;
|
|
|
|
static struct {
|
|
|
|
const char *name;
|
|
|
|
long ssl_version;
|
|
|
|
} sslversions[] = {
|
|
|
|
{ "sslv2", CURL_SSLVERSION_SSLv2 },
|
|
|
|
{ "sslv3", CURL_SSLVERSION_SSLv3 },
|
|
|
|
{ "tlsv1", CURL_SSLVERSION_TLSv1 },
|
http: centralize the accounting of libcurl dependencies
As discussed in 644de29e220 (http: drop support for curl < 7.19.4,
2021-07-30) checking against LIBCURL_VERSION_NUM isn't as reliable as
checking specific symbols present in curl, as some distros have been
known to backport features.
However, while some of the curl_easy_setopt() arguments we rely on are
macros, others are enum, and we can't assume that those that are
macros won't change into enums in the future.
So we're still going to have to check LIBCURL_VERSION_NUM, but by
doing that in one central place and using a macro definition of our
own, anyone who's backporting features can define it themselves, and
thus have access to more modern curl features that they backported,
even if they didn't bump the LIBCURL_VERSION_NUM.
More importantly, as shown in a preceding commit doing these version
checks makes for hard to read and possibly buggy code, as shown by the
bug fixed there where we were conflating base 10 for base 16 when
comparing the version.
By doing them all in one place we'll hopefully reduce the chances of
such future mistakes, furthermore it now becomes easier to see at a
glance what the oldest supported version is, which makes it easier to
reason about any future deprecation similar to the recent
e48a623dea0 (Merge branch 'ab/http-drop-old-curl', 2021-08-24).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-13 16:51:28 +02:00
|
|
|
#ifdef GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_0
|
2015-08-14 21:37:43 +02:00
|
|
|
{ "tlsv1.0", CURL_SSLVERSION_TLSv1_0 },
|
|
|
|
{ "tlsv1.1", CURL_SSLVERSION_TLSv1_1 },
|
|
|
|
{ "tlsv1.2", CURL_SSLVERSION_TLSv1_2 },
|
|
|
|
#endif
|
http: centralize the accounting of libcurl dependencies
As discussed in 644de29e220 (http: drop support for curl < 7.19.4,
2021-07-30) checking against LIBCURL_VERSION_NUM isn't as reliable as
checking specific symbols present in curl, as some distros have been
known to backport features.
However, while some of the curl_easy_setopt() arguments we rely on are
macros, others are enum, and we can't assume that those that are
macros won't change into enums in the future.
So we're still going to have to check LIBCURL_VERSION_NUM, but by
doing that in one central place and using a macro definition of our
own, anyone who's backporting features can define it themselves, and
thus have access to more modern curl features that they backported,
even if they didn't bump the LIBCURL_VERSION_NUM.
More importantly, as shown in a preceding commit doing these version
checks makes for hard to read and possibly buggy code, as shown by the
bug fixed there where we were conflating base 10 for base 16 when
comparing the version.
By doing them all in one place we'll hopefully reduce the chances of
such future mistakes, furthermore it now becomes easier to see at a
glance what the oldest supported version is, which makes it easier to
reason about any future deprecation similar to the recent
e48a623dea0 (Merge branch 'ab/http-drop-old-curl', 2021-08-24).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-13 16:51:28 +02:00
|
|
|
#ifdef GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_3
|
2018-03-29 12:14:18 +02:00
|
|
|
{ "tlsv1.3", CURL_SSLVERSION_TLSv1_3 },
|
|
|
|
#endif
|
2015-08-14 21:37:43 +02:00
|
|
|
};
|
2009-03-10 02:47:29 +01:00
|
|
|
static const char *ssl_key;
|
|
|
|
static const char *ssl_capath;
|
2018-03-14 22:56:06 +01:00
|
|
|
static const char *curl_no_proxy;
|
http: centralize the accounting of libcurl dependencies
As discussed in 644de29e220 (http: drop support for curl < 7.19.4,
2021-07-30) checking against LIBCURL_VERSION_NUM isn't as reliable as
checking specific symbols present in curl, as some distros have been
known to backport features.
However, while some of the curl_easy_setopt() arguments we rely on are
macros, others are enum, and we can't assume that those that are
macros won't change into enums in the future.
So we're still going to have to check LIBCURL_VERSION_NUM, but by
doing that in one central place and using a macro definition of our
own, anyone who's backporting features can define it themselves, and
thus have access to more modern curl features that they backported,
even if they didn't bump the LIBCURL_VERSION_NUM.
More importantly, as shown in a preceding commit doing these version
checks makes for hard to read and possibly buggy code, as shown by the
bug fixed there where we were conflating base 10 for base 16 when
comparing the version.
By doing them all in one place we'll hopefully reduce the chances of
such future mistakes, furthermore it now becomes easier to see at a
glance what the oldest supported version is, which makes it easier to
reason about any future deprecation similar to the recent
e48a623dea0 (Merge branch 'ab/http-drop-old-curl', 2021-08-24).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-13 16:51:28 +02:00
|
|
|
#ifdef GIT_CURL_HAVE_CURLOPT_PINNEDPUBLICKEY
|
2016-02-15 15:04:22 +01:00
|
|
|
static const char *ssl_pinnedkey;
|
|
|
|
#endif
|
2009-03-10 02:47:29 +01:00
|
|
|
static const char *ssl_cainfo;
|
2007-12-09 18:04:57 +01:00
|
|
|
static long curl_low_speed_limit = -1;
|
|
|
|
static long curl_low_speed_time = -1;
|
2009-03-10 02:47:29 +01:00
|
|
|
static int curl_ftp_no_epsv;
|
|
|
|
static const char *curl_http_proxy;
|
2016-01-26 14:02:47 +01:00
|
|
|
static const char *http_proxy_authmethod;
|
2020-03-04 19:40:05 +01:00
|
|
|
|
|
|
|
static const char *http_proxy_ssl_cert;
|
|
|
|
static const char *http_proxy_ssl_key;
|
|
|
|
static const char *http_proxy_ssl_ca_info;
|
|
|
|
static struct credential proxy_cert_auth = CREDENTIAL_INIT;
|
|
|
|
static int proxy_ssl_cert_password_required;
|
|
|
|
|
2016-01-26 14:02:47 +01:00
|
|
|
static struct {
|
|
|
|
const char *name;
|
|
|
|
long curlauth_param;
|
|
|
|
} proxy_authmethods[] = {
|
|
|
|
{ "basic", CURLAUTH_BASIC },
|
|
|
|
{ "digest", CURLAUTH_DIGEST },
|
|
|
|
{ "negotiate", CURLAUTH_GSSNEGOTIATE },
|
|
|
|
{ "ntlm", CURLAUTH_NTLM },
|
|
|
|
{ "anyauth", CURLAUTH_ANY },
|
|
|
|
/*
|
|
|
|
* CURLAUTH_DIGEST_IE has no corresponding command-line option in
|
|
|
|
* curl(1) and is not included in CURLAUTH_ANY, so we leave it out
|
|
|
|
* here, too
|
|
|
|
*/
|
|
|
|
};
|
2017-08-11 18:37:34 +02:00
|
|
|
#ifdef CURLGSSAPI_DELEGATION_FLAG
|
2016-09-28 20:01:34 +02:00
|
|
|
static const char *curl_deleg;
|
|
|
|
static struct {
|
|
|
|
const char *name;
|
|
|
|
long curl_deleg_param;
|
|
|
|
} curl_deleg_levels[] = {
|
|
|
|
{ "none", CURLGSSAPI_DELEGATION_NONE },
|
|
|
|
{ "policy", CURLGSSAPI_DELEGATION_POLICY_FLAG },
|
|
|
|
{ "always", CURLGSSAPI_DELEGATION_FLAG },
|
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
http: use credential API to handle proxy authentication
Currently, the only way to pass proxy credentials to curl is by including them
in the proxy URL. Usually, this means they will end up on disk unencrypted, one
way or another (by inclusion in ~/.gitconfig, shell profile or history). Since
proxy authentication often uses a domain user, credentials can be security
sensitive; therefore, a safer way of passing credentials is desirable.
If the configured proxy contains a username but not a password, query the
credential API for one. Also, make sure we approve/reject proxy credentials
properly.
For consistency reasons, add parsing of http_proxy/https_proxy/all_proxy
environment variables, which would otherwise be evaluated as a fallback by curl.
Without this, we would have different semantics for git configuration and
environment variables.
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Knut Franke <k.franke@science-computing.de>
Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26 14:02:48 +01:00
|
|
|
static struct credential proxy_auth = CREDENTIAL_INIT;
|
|
|
|
static const char *curl_proxyuserpwd;
|
2011-06-02 22:31:25 +02:00
|
|
|
static const char *curl_cookie_file;
|
2013-07-24 00:40:17 +02:00
|
|
|
static int curl_save_cookies;
|
http: hoist credential request out of handle_curl_result
When we are handling a curl response code in http_request or
in the remote-curl RPC code, we use the handle_curl_result
helper to translate curl's response into an easy-to-use
code. When we see an HTTP 401, we do one of two things:
1. If we already had a filled-in credential, we mark it as
rejected, and then return HTTP_NOAUTH to indicate to
the caller that we failed.
2. If we didn't, then we ask for a new credential and tell
the caller HTTP_REAUTH to indicate that they may want
to try again.
Rejecting in the first case makes sense; it is the natural
result of the request we just made. However, prompting for
more credentials in the second step does not always make
sense. We do not know for sure that the caller is going to
make a second request, and nor are we sure that it will be
to the same URL. Logically, the prompt belongs not to the
request we just finished, but to the request we are (maybe)
about to make.
In practice, it is very hard to trigger any bad behavior.
Currently, if we make a second request, it will always be to
the same URL (even in the face of redirects, because curl
handles the redirects internally). And we almost always
retry on HTTP_REAUTH these days. The one exception is if we
are streaming a large RPC request to the server (e.g., a
pushed packfile), in which case we cannot restart. It's
extremely unlikely to see a 401 response at this stage,
though, as we would typically have seen it when we sent a
probe request, before streaming the data.
This patch drops the automatic prompt out of case 2, and
instead requires the caller to do it. This is a few extra
lines of code, and the bug it fixes is unlikely to come up
in practice. But it is conceptually cleaner, and paves the
way for better handling of credentials across redirects.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-09-28 10:31:45 +02:00
|
|
|
struct credential http_auth = CREDENTIAL_INIT;
|
2011-12-14 01:11:56 +01:00
|
|
|
static int http_proactive_auth;
|
2010-08-11 22:40:38 +02:00
|
|
|
static const char *user_agent;
|
http: add an "auto" mode for http.emptyauth
This variable needs to be specified to make some types of
non-basic authentication work, but ideally this would just
work out of the box for everyone.
However, simply setting it to "1" by default introduces an
extra round-trip for cases where it _isn't_ useful. We end
up sending a bogus empty credential that the server rejects.
Instead, let's introduce an automatic mode, that works like
this:
1. We won't try to send the bogus credential on the first
request. We'll wait to get an HTTP 401, as usual.
2. After seeing an HTTP 401, the empty-auth hack will kick
in only when we know there is an auth method available
that might make use of it (i.e., something besides
"Basic" or "Digest").
That should make it work out of the box, without incurring
any extra round-trips for people hitting Basic-only servers.
This _does_ incur an extra round-trip if you really want to
use "Basic" but your server advertises other methods (the
emptyauth hack will kick in but fail, and then Git will
actually ask for a password).
The auto mode may incur an extra round-trip over setting
http.emptyauth=true, because part of the emptyauth hack is
to feed this blank password to curl even before we've made a
single request.
Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-25 20:18:31 +01:00
|
|
|
static int curl_empty_auth = -1;
|
2005-11-18 20:02:58 +01:00
|
|
|
|
http: make redirects more obvious
We instruct curl to always follow HTTP redirects. This is
convenient, but it creates opportunities for malicious
servers to create confusing situations. For instance,
imagine Alice is a git user with access to a private
repository on Bob's server. Mallory runs her own server and
wants to access objects from Bob's repository.
Mallory may try a few tricks that involve asking Alice to
clone from her, build on top, and then push the result:
1. Mallory may simply redirect all fetch requests to Bob's
server. Git will transparently follow those redirects
and fetch Bob's history, which Alice may believe she
got from Mallory. The subsequent push seems like it is
just feeding Mallory back her own objects, but is
actually leaking Bob's objects. There is nothing in
git's output to indicate that Bob's repository was
involved at all.
The downside (for Mallory) of this attack is that Alice
will have received Bob's entire repository, and is
likely to notice that when building on top of it.
2. If Mallory happens to know the sha1 of some object X in
Bob's repository, she can instead build her own history
that references that object. She then runs a dumb http
server, and Alice's client will fetch each object
individually. When it asks for X, Mallory redirects her
to Bob's server. The end result is that Alice obtains
objects from Bob, but they may be buried deep in
history. Alice is less likely to notice.
Both of these attacks are fairly hard to pull off. There's a
social component in getting Mallory to convince Alice to
work with her. Alice may be prompted for credentials in
accessing Bob's repository (but not always, if she is using
a credential helper that caches). Attack (1) requires a
certain amount of obliviousness on Alice's part while making
a new commit. Attack (2) requires that Mallory knows a sha1
in Bob's repository, that Bob's server supports dumb http,
and that the object in question is loose on Bob's server.
But we can probably make things a bit more obvious without
any loss of functionality. This patch does two things to
that end.
First, when we encounter a whole-repo redirect during the
initial ref discovery, we now inform the user on stderr,
making attack (1) much more obvious.
Second, the decision to follow redirects is now
configurable. The truly paranoid can set the new
http.followRedirects to false to avoid any redirection
entirely. But for a more practical default, we will disallow
redirects only after the initial ref discovery. This is
enough to thwart attacks similar to (2), while still
allowing the common use of redirects at the repository
level. Since c93c92f30 (http: update base URLs when we see
redirects, 2013-09-28) we re-root all further requests from
the redirect destination, which should generally mean that
no further redirection is necessary.
As an escape hatch, in case there really is a server that
needs to redirect individual requests, the user can set
http.followRedirects to "true" (and this can be done on a
per-server basis via http.*.followRedirects config).
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-06 19:24:41 +01:00
|
|
|
enum http_follow_config http_follow_config = HTTP_FOLLOW_INITIAL;
|
|
|
|
|
http: use credential API to get passwords
This patch converts the http code to use the new credential
API, both for http authentication as well as for getting
certificate passwords.
Most of the code change is simply variable naming (the
passwords are now contained inside the credential struct)
or deletion of obsolete code (the credential code handles
URL parsing and prompting for us).
The behavior should be the same, with one exception: the
credential code will prompt with a description based on the
credential components. Therefore, the old prompt of:
Username for 'example.com':
Password for 'example.com':
now looks like:
Username for 'https://example.com/repo.git':
Password for 'https://user@example.com/repo.git':
Note that we include more information in each line,
specifically:
1. We now include the protocol. While more noisy, this is
an important part of knowing what you are accessing
(especially if you care about http vs https).
2. We include the username in the password prompt. This is
not a big deal when you have just been prompted for it,
but the username may also come from the remote's URL
(and after future patches, from configuration or
credential helpers). In that case, it's a nice
reminder of the user for which you're giving the
password.
3. We include the path component of the URL. In many
cases, the user won't care about this and it's simply
noise (i.e., they'll use the same credential for a
whole site). However, that is part of a larger
question, which is whether path components should be
part of credential context, both for prompting and for
lookup by storage helpers. That issue will be addressed
as a whole in a future patch.
Similarly, for unlocking certificates, we used to say:
Certificate Password for 'example.com':
and we now say:
Password for 'cert:///path/to/certificate':
Showing the path to the client certificate makes more sense,
as that is what you are unlocking, not "example.com".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-10 11:31:21 +01:00
|
|
|
static struct credential cert_auth = CREDENTIAL_INIT;
|
2009-05-28 05:16:02 +02:00
|
|
|
static int ssl_cert_password_required;
|
2015-01-08 01:29:20 +01:00
|
|
|
static unsigned long http_auth_methods = CURLAUTH_ANY;
|
http: add an "auto" mode for http.emptyauth
This variable needs to be specified to make some types of
non-basic authentication work, but ideally this would just
work out of the box for everyone.
However, simply setting it to "1" by default introduces an
extra round-trip for cases where it _isn't_ useful. We end
up sending a bogus empty credential that the server rejects.
Instead, let's introduce an automatic mode, that works like
this:
1. We won't try to send the bogus credential on the first
request. We'll wait to get an HTTP 401, as usual.
2. After seeing an HTTP 401, the empty-auth hack will kick
in only when we know there is an auth method available
that might make use of it (i.e., something besides
"Basic" or "Digest").
That should make it work out of the box, without incurring
any extra round-trips for people hitting Basic-only servers.
This _does_ incur an extra round-trip if you really want to
use "Basic" but your server advertises other methods (the
emptyauth hack will kick in but fail, and then Git will
actually ask for a password).
The auto mode may incur an extra round-trip over setting
http.emptyauth=true, because part of the emptyauth hack is
to feed this blank password to curl even before we've made a
single request.
Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-25 20:18:31 +01:00
|
|
|
static int http_auth_methods_restricted;
|
|
|
|
/* Modes for which empty_auth cannot actually help us. */
|
|
|
|
static unsigned long empty_auth_useless =
|
|
|
|
CURLAUTH_BASIC
|
|
|
|
| CURLAUTH_DIGEST_IE
|
|
|
|
| CURLAUTH_DIGEST;
|
2009-05-28 05:16:02 +02:00
|
|
|
|
2007-12-09 18:04:57 +01:00
|
|
|
static struct curl_slist *pragma_header;
|
http*: add helper methods for fetching objects (loose)
The code handling the fetching of loose objects in http-push.c and
http-walker.c have been refactored into new methods and a new struct
(object_http_request) in http.c. They are not meant to be invoked
elsewhere.
The new methods in http.c are
- new_http_object_request
- process_http_object_request
- finish_http_object_request
- abort_http_object_request
- release_http_object_request
and the new struct is http_object_request.
RANGER_HEADER_SIZE and no_pragma_header is no longer made available
outside of http.c, since after the above changes, there are no other
instances of usage outside of http.c.
Remove members of the transfer_request struct in http-push.c and
http-walker.c, including filename, real_sha1 and zret, as they are used
no longer used.
Move the methods append_remote_object_url() and get_remote_object_url()
from http-push.c to http.c. Additionally, get_remote_object_url() is no
longer defined only when USE_CURL_MULTI is defined, since
non-USE_CURL_MULTI code in http.c uses it (namely, in
new_http_object_request()).
Refactor code from http-push.c::start_fetch_loose() and
http-walker.c::start_object_fetch_request() that deals with the details
of coming up with the filename to store the retrieved object, resuming
a previously aborted request, and making a new curl request, into a new
function, new_http_object_request().
Refactor code from http-walker.c::process_object_request() into the
function, process_http_object_request().
Refactor code from http-push.c::finish_request() and
http-walker.c::finish_object_request() into a new function,
finish_http_object_request(). It returns the result of the
move_temp_to_file() invocation.
Add a function, release_http_object_request(), which cleans up object
request data. http-push.c and http-walker.c invoke this function
separately; http-push.c::release_request() and
http-walker.c::release_object_request() do not invoke this function.
Add a function, abort_http_object_request(), which unlink()s the object
file and invokes release_http_object_request(). Update
http-walker.c::abort_object_request() to use this.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-06 10:44:02 +02:00
|
|
|
static struct curl_slist *no_pragma_header;
|
remote-curl: unbreak http.extraHeader with custom allocators
In 93b980e58f5 (http: use xmalloc with cURL, 2019-08-15), we started to
ask cURL to use `xmalloc()`, and if compiled with nedmalloc, that means
implicitly a different allocator than the system one.
Which means that all of cURL's allocations and releases now _need_ to
use that allocator.
However, the `http_options()` function used `slist_append()` to add any
configured extra HTTP header(s) _before_ asking cURL to use `xmalloc()`,
and `http_cleanup()` would release them _afterwards_, i.e. in the
presence of custom allocators, cURL would attempt to use the wrong
allocator to release the memory.
A naïve attempt at fixing this would move the call to
`curl_global_init()` _before_ the config is parsed (i.e. before that
call to `slist_append()`).
However, that does not work, as we _also_ parse the config setting
`http.sslbackend` and if found, call `curl_global_sslset()` which *must*
be called before `curl_global_init()`, for details see:
https://curl.haxx.se/libcurl/c/curl_global_sslset.html
So let's instead make the config parsing entirely independent from
cURL's data structures. Incidentally, this deletes two more lines than
it introduces, which is nice.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-06 11:04:55 +01:00
|
|
|
static struct string_list extra_http_headers = STRING_LIST_INIT_DUP;
|
2009-06-06 10:43:41 +02:00
|
|
|
|
2009-03-10 02:47:29 +01:00
|
|
|
static struct active_request_slot *active_queue_head;
|
2005-11-18 20:02:58 +01:00
|
|
|
|
2015-01-28 13:04:37 +01:00
|
|
|
static char *cached_accept_language;
|
|
|
|
|
2018-10-15 12:14:43 +02:00
|
|
|
static char *http_ssl_backend;
|
|
|
|
|
2018-10-25 20:53:55 +02:00
|
|
|
static int http_schannel_check_revoke = 1;
|
2018-10-25 20:53:56 +02:00
|
|
|
/*
|
|
|
|
* With the backend being set to `schannel`, setting sslCAinfo would override
|
|
|
|
* the Certificate Store in cURL v7.60.0 and later, which is not what we want
|
|
|
|
* by default.
|
|
|
|
*/
|
|
|
|
static int http_schannel_use_ssl_cainfo;
|
2018-10-25 20:53:55 +02:00
|
|
|
|
2011-05-03 17:47:27 +02:00
|
|
|
size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void *buffer_)
|
2005-11-18 20:02:58 +01:00
|
|
|
{
|
|
|
|
size_t size = eltsize * nmemb;
|
2008-07-04 09:37:40 +02:00
|
|
|
struct buffer *buffer = buffer_;
|
|
|
|
|
2007-12-09 20:30:59 +01:00
|
|
|
if (size > buffer->buf.len - buffer->posn)
|
|
|
|
size = buffer->buf.len - buffer->posn;
|
|
|
|
memcpy(ptr, buffer->buf.buf + buffer->posn, size);
|
2005-11-18 20:02:58 +01:00
|
|
|
buffer->posn += size;
|
2007-12-09 20:30:59 +01:00
|
|
|
|
Make fread/fwrite-like functions in http.c more like fread/fwrite.
The fread/fwrite-like functions in http.c, namely fread_buffer,
fwrite_buffer, fwrite_null, fwrite_sha1_file all return the
multiplication of the size and number of items they are being given.
Practically speaking, it doesn't matter, because in all contexts where
those functions are used, size is 1.
But those functions being similar to fread and fwrite (the curl API is
designed around being able to use fread and fwrite directly), it might
be preferable to make them behave like fread and fwrite, which, from
the fread/fwrite manual page, is:
On success, fread() and fwrite() return the number of items read
or written. This number equals the number of bytes transferred
only when size is 1. If an error occurs, or the end of the file
is reached, the return value is a short item count (or zero).
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08 01:03:54 +02:00
|
|
|
return size / eltsize;
|
2005-11-18 20:02:58 +01:00
|
|
|
}
|
|
|
|
|
2009-04-01 18:48:24 +02:00
|
|
|
curlioerr ioctl_buffer(CURL *handle, int cmd, void *clientp)
|
|
|
|
{
|
|
|
|
struct buffer *buffer = clientp;
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case CURLIOCMD_NOP:
|
|
|
|
return CURLIOE_OK;
|
|
|
|
|
|
|
|
case CURLIOCMD_RESTARTREAD:
|
|
|
|
buffer->posn = 0;
|
|
|
|
return CURLIOE_OK;
|
|
|
|
|
|
|
|
default:
|
|
|
|
return CURLIOE_UNKNOWNCMD;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-05-03 17:47:27 +02:00
|
|
|
size_t fwrite_buffer(char *ptr, size_t eltsize, size_t nmemb, void *buffer_)
|
2005-11-18 20:02:58 +01:00
|
|
|
{
|
|
|
|
size_t size = eltsize * nmemb;
|
2008-07-04 09:37:40 +02:00
|
|
|
struct strbuf *buffer = buffer_;
|
|
|
|
|
2007-12-09 20:30:59 +01:00
|
|
|
strbuf_add(buffer, ptr, size);
|
Make fread/fwrite-like functions in http.c more like fread/fwrite.
The fread/fwrite-like functions in http.c, namely fread_buffer,
fwrite_buffer, fwrite_null, fwrite_sha1_file all return the
multiplication of the size and number of items they are being given.
Practically speaking, it doesn't matter, because in all contexts where
those functions are used, size is 1.
But those functions being similar to fread and fwrite (the curl API is
designed around being able to use fread and fwrite directly), it might
be preferable to make them behave like fread and fwrite, which, from
the fread/fwrite manual page, is:
On success, fread() and fwrite() return the number of items read
or written. This number equals the number of bytes transferred
only when size is 1. If an error occurs, or the end of the file
is reached, the return value is a short item count (or zero).
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08 01:03:54 +02:00
|
|
|
return nmemb;
|
2005-11-18 20:02:58 +01:00
|
|
|
}
|
|
|
|
|
2011-05-03 17:47:27 +02:00
|
|
|
size_t fwrite_null(char *ptr, size_t eltsize, size_t nmemb, void *strbuf)
|
2005-11-18 20:02:58 +01:00
|
|
|
{
|
Make fread/fwrite-like functions in http.c more like fread/fwrite.
The fread/fwrite-like functions in http.c, namely fread_buffer,
fwrite_buffer, fwrite_null, fwrite_sha1_file all return the
multiplication of the size and number of items they are being given.
Practically speaking, it doesn't matter, because in all contexts where
those functions are used, size is 1.
But those functions being similar to fread and fwrite (the curl API is
designed around being able to use fread and fwrite directly), it might
be preferable to make them behave like fread and fwrite, which, from
the fread/fwrite manual page, is:
On success, fread() and fwrite() return the number of items read
or written. This number equals the number of bytes transferred
only when size is 1. If an error occurs, or the end of the file
is reached, the return value is a short item count (or zero).
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08 01:03:54 +02:00
|
|
|
return nmemb;
|
2005-11-18 20:02:58 +01:00
|
|
|
}
|
|
|
|
|
2015-01-15 00:40:46 +01:00
|
|
|
static void closedown_active_slot(struct active_request_slot *slot)
|
|
|
|
{
|
|
|
|
active_requests--;
|
|
|
|
slot->in_use = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void finish_active_slot(struct active_request_slot *slot)
|
|
|
|
{
|
|
|
|
closedown_active_slot(slot);
|
|
|
|
curl_easy_getinfo(slot->curl, CURLINFO_HTTP_CODE, &slot->http_code);
|
|
|
|
|
2022-05-02 18:50:37 +02:00
|
|
|
if (slot->finished)
|
2015-01-15 00:40:46 +01:00
|
|
|
(*slot->finished) = 1;
|
|
|
|
|
|
|
|
/* Store slot results so they can be read after the slot is reused */
|
2022-05-02 18:50:37 +02:00
|
|
|
if (slot->results) {
|
2015-01-15 00:40:46 +01:00
|
|
|
slot->results->curl_result = slot->curl_result;
|
|
|
|
slot->results->http_code = slot->http_code;
|
|
|
|
curl_easy_getinfo(slot->curl, CURLINFO_HTTPAUTH_AVAIL,
|
|
|
|
&slot->results->auth_avail);
|
http: use credential API to handle proxy authentication
Currently, the only way to pass proxy credentials to curl is by including them
in the proxy URL. Usually, this means they will end up on disk unencrypted, one
way or another (by inclusion in ~/.gitconfig, shell profile or history). Since
proxy authentication often uses a domain user, credentials can be security
sensitive; therefore, a safer way of passing credentials is desirable.
If the configured proxy contains a username but not a password, query the
credential API for one. Also, make sure we approve/reject proxy credentials
properly.
For consistency reasons, add parsing of http_proxy/https_proxy/all_proxy
environment variables, which would otherwise be evaluated as a fallback by curl.
Without this, we would have different semantics for git configuration and
environment variables.
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Knut Franke <k.franke@science-computing.de>
Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26 14:02:48 +01:00
|
|
|
|
|
|
|
curl_easy_getinfo(slot->curl, CURLINFO_HTTP_CONNECTCODE,
|
|
|
|
&slot->results->http_connectcode);
|
2015-01-15 00:40:46 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Run callback if appropriate */
|
2022-05-02 18:50:37 +02:00
|
|
|
if (slot->callback_func)
|
2015-01-15 00:40:46 +01:00
|
|
|
slot->callback_func(slot->callback_data);
|
|
|
|
}
|
|
|
|
|
2016-09-13 02:25:56 +02:00
|
|
|
static void xmulti_remove_handle(struct active_request_slot *slot)
|
|
|
|
{
|
|
|
|
curl_multi_remove_handle(curlm, slot->curl);
|
|
|
|
}
|
|
|
|
|
2005-11-18 20:02:58 +01:00
|
|
|
static void process_curl_messages(void)
|
|
|
|
{
|
|
|
|
int num_messages;
|
|
|
|
struct active_request_slot *slot;
|
|
|
|
CURLMsg *curl_message = curl_multi_info_read(curlm, &num_messages);
|
|
|
|
|
|
|
|
while (curl_message != NULL) {
|
|
|
|
if (curl_message->msg == CURLMSG_DONE) {
|
|
|
|
int curl_result = curl_message->data.result;
|
|
|
|
slot = active_queue_head;
|
|
|
|
while (slot != NULL &&
|
|
|
|
slot->curl != curl_message->easy_handle)
|
|
|
|
slot = slot->next;
|
2022-05-02 18:50:37 +02:00
|
|
|
if (slot) {
|
2016-09-13 02:25:56 +02:00
|
|
|
xmulti_remove_handle(slot);
|
2005-11-18 20:02:58 +01:00
|
|
|
slot->curl_result = curl_result;
|
|
|
|
finish_active_slot(slot);
|
|
|
|
} else {
|
|
|
|
fprintf(stderr, "Received DONE message for unknown request!\n");
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
fprintf(stderr, "Unknown CURL message received: %d\n",
|
|
|
|
(int)curl_message->msg);
|
|
|
|
}
|
|
|
|
curl_message = curl_multi_info_read(curlm, &num_messages);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-05-14 19:46:53 +02:00
|
|
|
static int http_options(const char *var, const char *value, void *cb)
|
2005-11-18 20:02:58 +01:00
|
|
|
{
|
2018-11-09 04:44:14 +01:00
|
|
|
if (!strcmp("http.version", var)) {
|
|
|
|
return git_config_string(&curl_http_version, var, value);
|
|
|
|
}
|
2005-11-18 20:02:58 +01:00
|
|
|
if (!strcmp("http.sslverify", var)) {
|
http_init(): Fix config file parsing
We honor the command line options, environment variables, variables in
repository configuration file, variables in user's global configuration
file, variables in the system configuration file, and then finally use
built-in default. To implement this semantics, the code should:
- start from built-in default values;
- call git_config() with the configuration parser callback, which
implements "later definition overrides earlier ones" logic
(git_config() reads the system's, user's and then repository's
configuration file in this order);
- override the result from the above with environment variables if set;
- override the result from the above with command line options.
The initialization code http_init() for http transfer got this wrong, and
implemented a "first one wins, ignoring the later ones" in http_options(),
to compensate this mistake, read environment variables before calling
git_config(). This is all wrong.
As a second class citizen, the http codepath hasn't been audited as
closely as other parts of the system, but we should try to bring sanity to
it, before inviting contributors to improve on it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-10 03:00:30 +01:00
|
|
|
curl_ssl_verify = git_config_bool(var, value);
|
2005-11-18 20:02:58 +01:00
|
|
|
return 0;
|
|
|
|
}
|
2015-05-08 15:22:15 +02:00
|
|
|
if (!strcmp("http.sslcipherlist", var))
|
|
|
|
return git_config_string(&ssl_cipherlist, var, value);
|
2015-08-14 21:37:43 +02:00
|
|
|
if (!strcmp("http.sslversion", var))
|
|
|
|
return git_config_string(&ssl_version, var, value);
|
http_init(): Fix config file parsing
We honor the command line options, environment variables, variables in
repository configuration file, variables in user's global configuration
file, variables in the system configuration file, and then finally use
built-in default. To implement this semantics, the code should:
- start from built-in default values;
- call git_config() with the configuration parser callback, which
implements "later definition overrides earlier ones" logic
(git_config() reads the system's, user's and then repository's
configuration file in this order);
- override the result from the above with environment variables if set;
- override the result from the above with command line options.
The initialization code http_init() for http transfer got this wrong, and
implemented a "first one wins, ignoring the later ones" in http_options(),
to compensate this mistake, read environment variables before calling
git_config(). This is all wrong.
As a second class citizen, the http codepath hasn't been audited as
closely as other parts of the system, but we should try to bring sanity to
it, before inviting contributors to improve on it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-10 03:00:30 +01:00
|
|
|
if (!strcmp("http.sslcert", var))
|
http.c: http.sslcert and http.sslkey are both pathnames
Back when the modern http_options() codepath was created to parse
various http.* options at 29508e1e ("Isolate shared HTTP request
functionality", 2005-11-18), and then later was corrected for
interation between the multiple configuration files in 7059cd99
("http_init(): Fix config file parsing", 2009-03-09), we parsed
configuration variables like http.sslkey, http.sslcert as plain
vanilla strings, because git_config_pathname() that understands
"~[username]/" prefix did not exist. Later, we converted some of
them (namely, http.sslCAPath and http.sslCAInfo) to use the
function, and added variables like http.cookeyFile http.pinnedpubkey
to use the function from the beginning. Because of that, these
variables all understand "~[username]/" prefix.
Make the remaining two variables, http.sslcert and http.sslkey, also
aware of the convention, as they are both clearly pathnames to
files.
Noticed-by: Victor Toni <victor.toni@gmail.com>
Helped-by: Charles Bailey <cbailey32@bloomberg.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-20 22:30:52 +02:00
|
|
|
return git_config_pathname(&ssl_cert, var, value);
|
http_init(): Fix config file parsing
We honor the command line options, environment variables, variables in
repository configuration file, variables in user's global configuration
file, variables in the system configuration file, and then finally use
built-in default. To implement this semantics, the code should:
- start from built-in default values;
- call git_config() with the configuration parser callback, which
implements "later definition overrides earlier ones" logic
(git_config() reads the system's, user's and then repository's
configuration file in this order);
- override the result from the above with environment variables if set;
- override the result from the above with command line options.
The initialization code http_init() for http transfer got this wrong, and
implemented a "first one wins, ignoring the later ones" in http_options(),
to compensate this mistake, read environment variables before calling
git_config(). This is all wrong.
As a second class citizen, the http codepath hasn't been audited as
closely as other parts of the system, but we should try to bring sanity to
it, before inviting contributors to improve on it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-10 03:00:30 +01:00
|
|
|
if (!strcmp("http.sslkey", var))
|
http.c: http.sslcert and http.sslkey are both pathnames
Back when the modern http_options() codepath was created to parse
various http.* options at 29508e1e ("Isolate shared HTTP request
functionality", 2005-11-18), and then later was corrected for
interation between the multiple configuration files in 7059cd99
("http_init(): Fix config file parsing", 2009-03-09), we parsed
configuration variables like http.sslkey, http.sslcert as plain
vanilla strings, because git_config_pathname() that understands
"~[username]/" prefix did not exist. Later, we converted some of
them (namely, http.sslCAPath and http.sslCAInfo) to use the
function, and added variables like http.cookeyFile http.pinnedpubkey
to use the function from the beginning. Because of that, these
variables all understand "~[username]/" prefix.
Make the remaining two variables, http.sslcert and http.sslkey, also
aware of the convention, as they are both clearly pathnames to
files.
Noticed-by: Victor Toni <victor.toni@gmail.com>
Helped-by: Charles Bailey <cbailey32@bloomberg.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-20 22:30:52 +02:00
|
|
|
return git_config_pathname(&ssl_key, var, value);
|
http_init(): Fix config file parsing
We honor the command line options, environment variables, variables in
repository configuration file, variables in user's global configuration
file, variables in the system configuration file, and then finally use
built-in default. To implement this semantics, the code should:
- start from built-in default values;
- call git_config() with the configuration parser callback, which
implements "later definition overrides earlier ones" logic
(git_config() reads the system's, user's and then repository's
configuration file in this order);
- override the result from the above with environment variables if set;
- override the result from the above with command line options.
The initialization code http_init() for http transfer got this wrong, and
implemented a "first one wins, ignoring the later ones" in http_options(),
to compensate this mistake, read environment variables before calling
git_config(). This is all wrong.
As a second class citizen, the http codepath hasn't been audited as
closely as other parts of the system, but we should try to bring sanity to
it, before inviting contributors to improve on it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-10 03:00:30 +01:00
|
|
|
if (!strcmp("http.sslcapath", var))
|
2015-11-23 13:02:40 +01:00
|
|
|
return git_config_pathname(&ssl_capath, var, value);
|
http_init(): Fix config file parsing
We honor the command line options, environment variables, variables in
repository configuration file, variables in user's global configuration
file, variables in the system configuration file, and then finally use
built-in default. To implement this semantics, the code should:
- start from built-in default values;
- call git_config() with the configuration parser callback, which
implements "later definition overrides earlier ones" logic
(git_config() reads the system's, user's and then repository's
configuration file in this order);
- override the result from the above with environment variables if set;
- override the result from the above with command line options.
The initialization code http_init() for http transfer got this wrong, and
implemented a "first one wins, ignoring the later ones" in http_options(),
to compensate this mistake, read environment variables before calling
git_config(). This is all wrong.
As a second class citizen, the http codepath hasn't been audited as
closely as other parts of the system, but we should try to bring sanity to
it, before inviting contributors to improve on it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-10 03:00:30 +01:00
|
|
|
if (!strcmp("http.sslcainfo", var))
|
2015-11-23 13:02:40 +01:00
|
|
|
return git_config_pathname(&ssl_cainfo, var, value);
|
2009-05-28 05:16:03 +02:00
|
|
|
if (!strcmp("http.sslcertpasswordprotected", var)) {
|
2013-07-12 20:52:47 +02:00
|
|
|
ssl_cert_password_required = git_config_bool(var, value);
|
2009-05-28 05:16:03 +02:00
|
|
|
return 0;
|
|
|
|
}
|
2013-04-07 21:10:39 +02:00
|
|
|
if (!strcmp("http.ssltry", var)) {
|
|
|
|
curl_ssl_try = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
2018-10-15 12:14:43 +02:00
|
|
|
if (!strcmp("http.sslbackend", var)) {
|
|
|
|
free(http_ssl_backend);
|
|
|
|
http_ssl_backend = xstrdup_or_null(value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-10-25 20:53:55 +02:00
|
|
|
if (!strcmp("http.schannelcheckrevoke", var)) {
|
|
|
|
http_schannel_check_revoke = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-10-25 20:53:56 +02:00
|
|
|
if (!strcmp("http.schannelusesslcainfo", var)) {
|
|
|
|
http_schannel_use_ssl_cainfo = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-11-27 16:42:26 +01:00
|
|
|
if (!strcmp("http.minsessions", var)) {
|
|
|
|
min_curl_sessions = git_config_int(var, value);
|
|
|
|
if (min_curl_sessions > 1)
|
|
|
|
min_curl_sessions = 1;
|
|
|
|
return 0;
|
|
|
|
}
|
2005-11-18 20:02:58 +01:00
|
|
|
if (!strcmp("http.maxrequests", var)) {
|
http_init(): Fix config file parsing
We honor the command line options, environment variables, variables in
repository configuration file, variables in user's global configuration
file, variables in the system configuration file, and then finally use
built-in default. To implement this semantics, the code should:
- start from built-in default values;
- call git_config() with the configuration parser callback, which
implements "later definition overrides earlier ones" logic
(git_config() reads the system's, user's and then repository's
configuration file in this order);
- override the result from the above with environment variables if set;
- override the result from the above with command line options.
The initialization code http_init() for http transfer got this wrong, and
implemented a "first one wins, ignoring the later ones" in http_options(),
to compensate this mistake, read environment variables before calling
git_config(). This is all wrong.
As a second class citizen, the http codepath hasn't been audited as
closely as other parts of the system, but we should try to bring sanity to
it, before inviting contributors to improve on it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-10 03:00:30 +01:00
|
|
|
max_requests = git_config_int(var, value);
|
2005-11-18 20:02:58 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (!strcmp("http.lowspeedlimit", var)) {
|
http_init(): Fix config file parsing
We honor the command line options, environment variables, variables in
repository configuration file, variables in user's global configuration
file, variables in the system configuration file, and then finally use
built-in default. To implement this semantics, the code should:
- start from built-in default values;
- call git_config() with the configuration parser callback, which
implements "later definition overrides earlier ones" logic
(git_config() reads the system's, user's and then repository's
configuration file in this order);
- override the result from the above with environment variables if set;
- override the result from the above with command line options.
The initialization code http_init() for http transfer got this wrong, and
implemented a "first one wins, ignoring the later ones" in http_options(),
to compensate this mistake, read environment variables before calling
git_config(). This is all wrong.
As a second class citizen, the http codepath hasn't been audited as
closely as other parts of the system, but we should try to bring sanity to
it, before inviting contributors to improve on it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-10 03:00:30 +01:00
|
|
|
curl_low_speed_limit = (long)git_config_int(var, value);
|
2005-11-18 20:02:58 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (!strcmp("http.lowspeedtime", var)) {
|
http_init(): Fix config file parsing
We honor the command line options, environment variables, variables in
repository configuration file, variables in user's global configuration
file, variables in the system configuration file, and then finally use
built-in default. To implement this semantics, the code should:
- start from built-in default values;
- call git_config() with the configuration parser callback, which
implements "later definition overrides earlier ones" logic
(git_config() reads the system's, user's and then repository's
configuration file in this order);
- override the result from the above with environment variables if set;
- override the result from the above with command line options.
The initialization code http_init() for http transfer got this wrong, and
implemented a "first one wins, ignoring the later ones" in http_options(),
to compensate this mistake, read environment variables before calling
git_config(). This is all wrong.
As a second class citizen, the http codepath hasn't been audited as
closely as other parts of the system, but we should try to bring sanity to
it, before inviting contributors to improve on it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-10 03:00:30 +01:00
|
|
|
curl_low_speed_time = (long)git_config_int(var, value);
|
2005-11-18 20:02:58 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-09-29 02:10:44 +02:00
|
|
|
if (!strcmp("http.noepsv", var)) {
|
|
|
|
curl_ftp_no_epsv = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
http_init(): Fix config file parsing
We honor the command line options, environment variables, variables in
repository configuration file, variables in user's global configuration
file, variables in the system configuration file, and then finally use
built-in default. To implement this semantics, the code should:
- start from built-in default values;
- call git_config() with the configuration parser callback, which
implements "later definition overrides earlier ones" logic
(git_config() reads the system's, user's and then repository's
configuration file in this order);
- override the result from the above with environment variables if set;
- override the result from the above with command line options.
The initialization code http_init() for http transfer got this wrong, and
implemented a "first one wins, ignoring the later ones" in http_options(),
to compensate this mistake, read environment variables before calling
git_config(). This is all wrong.
As a second class citizen, the http codepath hasn't been audited as
closely as other parts of the system, but we should try to bring sanity to
it, before inviting contributors to improve on it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-10 03:00:30 +01:00
|
|
|
if (!strcmp("http.proxy", var))
|
|
|
|
return git_config_string(&curl_http_proxy, var, value);
|
2006-09-29 02:10:44 +02:00
|
|
|
|
2016-01-26 14:02:47 +01:00
|
|
|
if (!strcmp("http.proxyauthmethod", var))
|
|
|
|
return git_config_string(&http_proxy_authmethod, var, value);
|
|
|
|
|
2020-03-04 19:40:05 +01:00
|
|
|
if (!strcmp("http.proxysslcert", var))
|
|
|
|
return git_config_string(&http_proxy_ssl_cert, var, value);
|
|
|
|
|
|
|
|
if (!strcmp("http.proxysslkey", var))
|
|
|
|
return git_config_string(&http_proxy_ssl_key, var, value);
|
|
|
|
|
|
|
|
if (!strcmp("http.proxysslcainfo", var))
|
|
|
|
return git_config_string(&http_proxy_ssl_ca_info, var, value);
|
|
|
|
|
|
|
|
if (!strcmp("http.proxysslcertpasswordprotected", var)) {
|
|
|
|
proxy_ssl_cert_password_required = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-06-02 22:31:25 +02:00
|
|
|
if (!strcmp("http.cookiefile", var))
|
2016-05-04 20:42:15 +02:00
|
|
|
return git_config_pathname(&curl_cookie_file, var, value);
|
2013-07-24 00:40:17 +02:00
|
|
|
if (!strcmp("http.savecookies", var)) {
|
|
|
|
curl_save_cookies = git_config_bool(var, value);
|
|
|
|
return 0;
|
|
|
|
}
|
2011-06-02 22:31:25 +02:00
|
|
|
|
2009-10-31 01:47:41 +01:00
|
|
|
if (!strcmp("http.postbuffer", var)) {
|
2017-04-11 20:13:57 +02:00
|
|
|
http_post_buffer = git_config_ssize_t(var, value);
|
|
|
|
if (http_post_buffer < 0)
|
|
|
|
warning(_("negative value for http.postbuffer; defaulting to %d"), LARGE_PACKET_MAX);
|
2009-10-31 01:47:41 +01:00
|
|
|
if (http_post_buffer < LARGE_PACKET_MAX)
|
|
|
|
http_post_buffer = LARGE_PACKET_MAX;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-08-11 22:40:38 +02:00
|
|
|
if (!strcmp("http.useragent", var))
|
|
|
|
return git_config_string(&user_agent, var, value);
|
|
|
|
|
2016-02-15 19:44:46 +01:00
|
|
|
if (!strcmp("http.emptyauth", var)) {
|
http: add an "auto" mode for http.emptyauth
This variable needs to be specified to make some types of
non-basic authentication work, but ideally this would just
work out of the box for everyone.
However, simply setting it to "1" by default introduces an
extra round-trip for cases where it _isn't_ useful. We end
up sending a bogus empty credential that the server rejects.
Instead, let's introduce an automatic mode, that works like
this:
1. We won't try to send the bogus credential on the first
request. We'll wait to get an HTTP 401, as usual.
2. After seeing an HTTP 401, the empty-auth hack will kick
in only when we know there is an auth method available
that might make use of it (i.e., something besides
"Basic" or "Digest").
That should make it work out of the box, without incurring
any extra round-trips for people hitting Basic-only servers.
This _does_ incur an extra round-trip if you really want to
use "Basic" but your server advertises other methods (the
emptyauth hack will kick in but fail, and then Git will
actually ask for a password).
The auto mode may incur an extra round-trip over setting
http.emptyauth=true, because part of the emptyauth hack is
to feed this blank password to curl even before we've made a
single request.
Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-25 20:18:31 +01:00
|
|
|
if (value && !strcmp("auto", value))
|
|
|
|
curl_empty_auth = -1;
|
|
|
|
else
|
|
|
|
curl_empty_auth = git_config_bool(var, value);
|
2016-02-15 19:44:46 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-09-28 20:01:34 +02:00
|
|
|
if (!strcmp("http.delegation", var)) {
|
2017-08-11 18:37:34 +02:00
|
|
|
#ifdef CURLGSSAPI_DELEGATION_FLAG
|
2016-09-28 20:01:34 +02:00
|
|
|
return git_config_string(&curl_deleg, var, value);
|
|
|
|
#else
|
|
|
|
warning(_("Delegation control is not supported with cURL < 7.22.0"));
|
|
|
|
return 0;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2016-02-15 15:04:22 +01:00
|
|
|
if (!strcmp("http.pinnedpubkey", var)) {
|
http: centralize the accounting of libcurl dependencies
As discussed in 644de29e220 (http: drop support for curl < 7.19.4,
2021-07-30) checking against LIBCURL_VERSION_NUM isn't as reliable as
checking specific symbols present in curl, as some distros have been
known to backport features.
However, while some of the curl_easy_setopt() arguments we rely on are
macros, others are enum, and we can't assume that those that are
macros won't change into enums in the future.
So we're still going to have to check LIBCURL_VERSION_NUM, but by
doing that in one central place and using a macro definition of our
own, anyone who's backporting features can define it themselves, and
thus have access to more modern curl features that they backported,
even if they didn't bump the LIBCURL_VERSION_NUM.
More importantly, as shown in a preceding commit doing these version
checks makes for hard to read and possibly buggy code, as shown by the
bug fixed there where we were conflating base 10 for base 16 when
comparing the version.
By doing them all in one place we'll hopefully reduce the chances of
such future mistakes, furthermore it now becomes easier to see at a
glance what the oldest supported version is, which makes it easier to
reason about any future deprecation similar to the recent
e48a623dea0 (Merge branch 'ab/http-drop-old-curl', 2021-08-24).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-13 16:51:28 +02:00
|
|
|
#ifdef GIT_CURL_HAVE_CURLOPT_PINNEDPUBLICKEY
|
2016-02-15 15:04:22 +01:00
|
|
|
return git_config_pathname(&ssl_pinnedkey, var, value);
|
|
|
|
#else
|
2021-09-13 16:51:27 +02:00
|
|
|
warning(_("Public key pinning not supported with cURL < 7.39.0"));
|
2016-02-15 15:04:22 +01:00
|
|
|
return 0;
|
|
|
|
#endif
|
|
|
|
}
|
2016-02-24 22:25:58 +01:00
|
|
|
|
2016-04-27 14:20:37 +02:00
|
|
|
if (!strcmp("http.extraheader", var)) {
|
|
|
|
if (!value) {
|
|
|
|
return config_error_nonbool(var);
|
|
|
|
} else if (!*value) {
|
remote-curl: unbreak http.extraHeader with custom allocators
In 93b980e58f5 (http: use xmalloc with cURL, 2019-08-15), we started to
ask cURL to use `xmalloc()`, and if compiled with nedmalloc, that means
implicitly a different allocator than the system one.
Which means that all of cURL's allocations and releases now _need_ to
use that allocator.
However, the `http_options()` function used `slist_append()` to add any
configured extra HTTP header(s) _before_ asking cURL to use `xmalloc()`,
and `http_cleanup()` would release them _afterwards_, i.e. in the
presence of custom allocators, cURL would attempt to use the wrong
allocator to release the memory.
A naïve attempt at fixing this would move the call to
`curl_global_init()` _before_ the config is parsed (i.e. before that
call to `slist_append()`).
However, that does not work, as we _also_ parse the config setting
`http.sslbackend` and if found, call `curl_global_sslset()` which *must*
be called before `curl_global_init()`, for details see:
https://curl.haxx.se/libcurl/c/curl_global_sslset.html
So let's instead make the config parsing entirely independent from
cURL's data structures. Incidentally, this deletes two more lines than
it introduces, which is nice.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-06 11:04:55 +01:00
|
|
|
string_list_clear(&extra_http_headers, 0);
|
2016-04-27 14:20:37 +02:00
|
|
|
} else {
|
remote-curl: unbreak http.extraHeader with custom allocators
In 93b980e58f5 (http: use xmalloc with cURL, 2019-08-15), we started to
ask cURL to use `xmalloc()`, and if compiled with nedmalloc, that means
implicitly a different allocator than the system one.
Which means that all of cURL's allocations and releases now _need_ to
use that allocator.
However, the `http_options()` function used `slist_append()` to add any
configured extra HTTP header(s) _before_ asking cURL to use `xmalloc()`,
and `http_cleanup()` would release them _afterwards_, i.e. in the
presence of custom allocators, cURL would attempt to use the wrong
allocator to release the memory.
A naïve attempt at fixing this would move the call to
`curl_global_init()` _before_ the config is parsed (i.e. before that
call to `slist_append()`).
However, that does not work, as we _also_ parse the config setting
`http.sslbackend` and if found, call `curl_global_sslset()` which *must*
be called before `curl_global_init()`, for details see:
https://curl.haxx.se/libcurl/c/curl_global_sslset.html
So let's instead make the config parsing entirely independent from
cURL's data structures. Incidentally, this deletes two more lines than
it introduces, which is nice.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-06 11:04:55 +01:00
|
|
|
string_list_append(&extra_http_headers, value);
|
2016-04-27 14:20:37 +02:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
http: make redirects more obvious
We instruct curl to always follow HTTP redirects. This is
convenient, but it creates opportunities for malicious
servers to create confusing situations. For instance,
imagine Alice is a git user with access to a private
repository on Bob's server. Mallory runs her own server and
wants to access objects from Bob's repository.
Mallory may try a few tricks that involve asking Alice to
clone from her, build on top, and then push the result:
1. Mallory may simply redirect all fetch requests to Bob's
server. Git will transparently follow those redirects
and fetch Bob's history, which Alice may believe she
got from Mallory. The subsequent push seems like it is
just feeding Mallory back her own objects, but is
actually leaking Bob's objects. There is nothing in
git's output to indicate that Bob's repository was
involved at all.
The downside (for Mallory) of this attack is that Alice
will have received Bob's entire repository, and is
likely to notice that when building on top of it.
2. If Mallory happens to know the sha1 of some object X in
Bob's repository, she can instead build her own history
that references that object. She then runs a dumb http
server, and Alice's client will fetch each object
individually. When it asks for X, Mallory redirects her
to Bob's server. The end result is that Alice obtains
objects from Bob, but they may be buried deep in
history. Alice is less likely to notice.
Both of these attacks are fairly hard to pull off. There's a
social component in getting Mallory to convince Alice to
work with her. Alice may be prompted for credentials in
accessing Bob's repository (but not always, if she is using
a credential helper that caches). Attack (1) requires a
certain amount of obliviousness on Alice's part while making
a new commit. Attack (2) requires that Mallory knows a sha1
in Bob's repository, that Bob's server supports dumb http,
and that the object in question is loose on Bob's server.
But we can probably make things a bit more obvious without
any loss of functionality. This patch does two things to
that end.
First, when we encounter a whole-repo redirect during the
initial ref discovery, we now inform the user on stderr,
making attack (1) much more obvious.
Second, the decision to follow redirects is now
configurable. The truly paranoid can set the new
http.followRedirects to false to avoid any redirection
entirely. But for a more practical default, we will disallow
redirects only after the initial ref discovery. This is
enough to thwart attacks similar to (2), while still
allowing the common use of redirects at the repository
level. Since c93c92f30 (http: update base URLs when we see
redirects, 2013-09-28) we re-root all further requests from
the redirect destination, which should generally mean that
no further redirection is necessary.
As an escape hatch, in case there really is a server that
needs to redirect individual requests, the user can set
http.followRedirects to "true" (and this can be done on a
per-server basis via http.*.followRedirects config).
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-06 19:24:41 +01:00
|
|
|
if (!strcmp("http.followredirects", var)) {
|
|
|
|
if (value && !strcmp(value, "initial"))
|
|
|
|
http_follow_config = HTTP_FOLLOW_INITIAL;
|
|
|
|
else if (git_config_bool(var, value))
|
|
|
|
http_follow_config = HTTP_FOLLOW_ALWAYS;
|
|
|
|
else
|
|
|
|
http_follow_config = HTTP_FOLLOW_NONE;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-11-18 20:02:58 +01:00
|
|
|
/* Fall back on the default ones */
|
2008-05-14 19:46:53 +02:00
|
|
|
return git_default_config(var, value, cb);
|
2005-11-18 20:02:58 +01:00
|
|
|
}
|
|
|
|
|
http: add an "auto" mode for http.emptyauth
This variable needs to be specified to make some types of
non-basic authentication work, but ideally this would just
work out of the box for everyone.
However, simply setting it to "1" by default introduces an
extra round-trip for cases where it _isn't_ useful. We end
up sending a bogus empty credential that the server rejects.
Instead, let's introduce an automatic mode, that works like
this:
1. We won't try to send the bogus credential on the first
request. We'll wait to get an HTTP 401, as usual.
2. After seeing an HTTP 401, the empty-auth hack will kick
in only when we know there is an auth method available
that might make use of it (i.e., something besides
"Basic" or "Digest").
That should make it work out of the box, without incurring
any extra round-trips for people hitting Basic-only servers.
This _does_ incur an extra round-trip if you really want to
use "Basic" but your server advertises other methods (the
emptyauth hack will kick in but fail, and then Git will
actually ask for a password).
The auto mode may incur an extra round-trip over setting
http.emptyauth=true, because part of the emptyauth hack is
to feed this blank password to curl even before we've made a
single request.
Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-25 20:18:31 +01:00
|
|
|
static int curl_empty_auth_enabled(void)
|
|
|
|
{
|
|
|
|
if (curl_empty_auth >= 0)
|
|
|
|
return curl_empty_auth;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In the automatic case, kick in the empty-auth
|
|
|
|
* hack as long as we would potentially try some
|
|
|
|
* method more exotic than "Basic" or "Digest".
|
|
|
|
*
|
|
|
|
* But only do this when this is our second or
|
|
|
|
* subsequent request, as by then we know what
|
|
|
|
* methods are available.
|
|
|
|
*/
|
|
|
|
if (http_auth_methods_restricted &&
|
|
|
|
(http_auth_methods & ~empty_auth_useless))
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-03-10 07:34:25 +01:00
|
|
|
static void init_curl_http_auth(CURL *result)
|
|
|
|
{
|
2016-10-04 16:53:52 +02:00
|
|
|
if (!http_auth.username || !*http_auth.username) {
|
http: add an "auto" mode for http.emptyauth
This variable needs to be specified to make some types of
non-basic authentication work, but ideally this would just
work out of the box for everyone.
However, simply setting it to "1" by default introduces an
extra round-trip for cases where it _isn't_ useful. We end
up sending a bogus empty credential that the server rejects.
Instead, let's introduce an automatic mode, that works like
this:
1. We won't try to send the bogus credential on the first
request. We'll wait to get an HTTP 401, as usual.
2. After seeing an HTTP 401, the empty-auth hack will kick
in only when we know there is an auth method available
that might make use of it (i.e., something besides
"Basic" or "Digest").
That should make it work out of the box, without incurring
any extra round-trips for people hitting Basic-only servers.
This _does_ incur an extra round-trip if you really want to
use "Basic" but your server advertises other methods (the
emptyauth hack will kick in but fail, and then Git will
actually ask for a password).
The auto mode may incur an extra round-trip over setting
http.emptyauth=true, because part of the emptyauth hack is
to feed this blank password to curl even before we've made a
single request.
Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-25 20:18:31 +01:00
|
|
|
if (curl_empty_auth_enabled())
|
2016-02-15 19:44:46 +01:00
|
|
|
curl_easy_setopt(result, CURLOPT_USERPWD, ":");
|
2012-04-13 08:19:25 +02:00
|
|
|
return;
|
2016-02-15 19:44:46 +01:00
|
|
|
}
|
2012-04-13 08:19:25 +02:00
|
|
|
|
|
|
|
credential_fill(&http_auth);
|
|
|
|
|
|
|
|
curl_easy_setopt(result, CURLOPT_USERNAME, http_auth.username);
|
|
|
|
curl_easy_setopt(result, CURLOPT_PASSWORD, http_auth.password);
|
2009-03-10 07:34:25 +01:00
|
|
|
}
|
|
|
|
|
2016-01-26 14:02:47 +01:00
|
|
|
/* *var must be free-able */
|
|
|
|
static void var_override(const char **var, char *value)
|
|
|
|
{
|
|
|
|
if (value) {
|
|
|
|
free((void *)*var);
|
|
|
|
*var = xstrdup(value);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
http: use credential API to handle proxy authentication
Currently, the only way to pass proxy credentials to curl is by including them
in the proxy URL. Usually, this means they will end up on disk unencrypted, one
way or another (by inclusion in ~/.gitconfig, shell profile or history). Since
proxy authentication often uses a domain user, credentials can be security
sensitive; therefore, a safer way of passing credentials is desirable.
If the configured proxy contains a username but not a password, query the
credential API for one. Also, make sure we approve/reject proxy credentials
properly.
For consistency reasons, add parsing of http_proxy/https_proxy/all_proxy
environment variables, which would otherwise be evaluated as a fallback by curl.
Without this, we would have different semantics for git configuration and
environment variables.
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Knut Franke <k.franke@science-computing.de>
Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26 14:02:48 +01:00
|
|
|
static void set_proxyauth_name_password(CURL *result)
|
|
|
|
{
|
|
|
|
curl_easy_setopt(result, CURLOPT_PROXYUSERNAME,
|
|
|
|
proxy_auth.username);
|
|
|
|
curl_easy_setopt(result, CURLOPT_PROXYPASSWORD,
|
|
|
|
proxy_auth.password);
|
|
|
|
}
|
|
|
|
|
2016-01-26 14:02:47 +01:00
|
|
|
static void init_curl_proxy_auth(CURL *result)
|
|
|
|
{
|
http: use credential API to handle proxy authentication
Currently, the only way to pass proxy credentials to curl is by including them
in the proxy URL. Usually, this means they will end up on disk unencrypted, one
way or another (by inclusion in ~/.gitconfig, shell profile or history). Since
proxy authentication often uses a domain user, credentials can be security
sensitive; therefore, a safer way of passing credentials is desirable.
If the configured proxy contains a username but not a password, query the
credential API for one. Also, make sure we approve/reject proxy credentials
properly.
For consistency reasons, add parsing of http_proxy/https_proxy/all_proxy
environment variables, which would otherwise be evaluated as a fallback by curl.
Without this, we would have different semantics for git configuration and
environment variables.
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Knut Franke <k.franke@science-computing.de>
Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26 14:02:48 +01:00
|
|
|
if (proxy_auth.username) {
|
|
|
|
if (!proxy_auth.password)
|
|
|
|
credential_fill(&proxy_auth);
|
|
|
|
set_proxyauth_name_password(result);
|
|
|
|
}
|
|
|
|
|
2016-01-26 14:02:47 +01:00
|
|
|
var_override(&http_proxy_authmethod, getenv("GIT_HTTP_PROXY_AUTHMETHOD"));
|
|
|
|
|
|
|
|
if (http_proxy_authmethod) {
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < ARRAY_SIZE(proxy_authmethods); i++) {
|
|
|
|
if (!strcmp(http_proxy_authmethod, proxy_authmethods[i].name)) {
|
|
|
|
curl_easy_setopt(result, CURLOPT_PROXYAUTH,
|
|
|
|
proxy_authmethods[i].curlauth_param);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (i == ARRAY_SIZE(proxy_authmethods)) {
|
|
|
|
warning("unsupported proxy authentication method %s: using anyauth",
|
|
|
|
http_proxy_authmethod);
|
|
|
|
curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);
|
|
|
|
}
|
|
|
|
|
2009-05-28 05:16:02 +02:00
|
|
|
static int has_cert_password(void)
|
|
|
|
{
|
|
|
|
if (ssl_cert == NULL || ssl_cert_password_required != 1)
|
|
|
|
return 0;
|
http: use credential API to get passwords
This patch converts the http code to use the new credential
API, both for http authentication as well as for getting
certificate passwords.
Most of the code change is simply variable naming (the
passwords are now contained inside the credential struct)
or deletion of obsolete code (the credential code handles
URL parsing and prompting for us).
The behavior should be the same, with one exception: the
credential code will prompt with a description based on the
credential components. Therefore, the old prompt of:
Username for 'example.com':
Password for 'example.com':
now looks like:
Username for 'https://example.com/repo.git':
Password for 'https://user@example.com/repo.git':
Note that we include more information in each line,
specifically:
1. We now include the protocol. While more noisy, this is
an important part of knowing what you are accessing
(especially if you care about http vs https).
2. We include the username in the password prompt. This is
not a big deal when you have just been prompted for it,
but the username may also come from the remote's URL
(and after future patches, from configuration or
credential helpers). In that case, it's a nice
reminder of the user for which you're giving the
password.
3. We include the path component of the URL. In many
cases, the user won't care about this and it's simply
noise (i.e., they'll use the same credential for a
whole site). However, that is part of a larger
question, which is whether path components should be
part of credential context, both for prompting and for
lookup by storage helpers. That issue will be addressed
as a whole in a future patch.
Similarly, for unlocking certificates, we used to say:
Certificate Password for 'example.com':
and we now say:
Password for 'cert:///path/to/certificate':
Showing the path to the client certificate makes more sense,
as that is what you are unlocking, not "example.com".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-10 11:31:21 +01:00
|
|
|
if (!cert_auth.password) {
|
|
|
|
cert_auth.protocol = xstrdup("cert");
|
2020-04-19 05:48:05 +02:00
|
|
|
cert_auth.host = xstrdup("");
|
2012-12-21 17:31:19 +01:00
|
|
|
cert_auth.username = xstrdup("");
|
http: use credential API to get passwords
This patch converts the http code to use the new credential
API, both for http authentication as well as for getting
certificate passwords.
Most of the code change is simply variable naming (the
passwords are now contained inside the credential struct)
or deletion of obsolete code (the credential code handles
URL parsing and prompting for us).
The behavior should be the same, with one exception: the
credential code will prompt with a description based on the
credential components. Therefore, the old prompt of:
Username for 'example.com':
Password for 'example.com':
now looks like:
Username for 'https://example.com/repo.git':
Password for 'https://user@example.com/repo.git':
Note that we include more information in each line,
specifically:
1. We now include the protocol. While more noisy, this is
an important part of knowing what you are accessing
(especially if you care about http vs https).
2. We include the username in the password prompt. This is
not a big deal when you have just been prompted for it,
but the username may also come from the remote's URL
(and after future patches, from configuration or
credential helpers). In that case, it's a nice
reminder of the user for which you're giving the
password.
3. We include the path component of the URL. In many
cases, the user won't care about this and it's simply
noise (i.e., they'll use the same credential for a
whole site). However, that is part of a larger
question, which is whether path components should be
part of credential context, both for prompting and for
lookup by storage helpers. That issue will be addressed
as a whole in a future patch.
Similarly, for unlocking certificates, we used to say:
Certificate Password for 'example.com':
and we now say:
Password for 'cert:///path/to/certificate':
Showing the path to the client certificate makes more sense,
as that is what you are unlocking, not "example.com".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-10 11:31:21 +01:00
|
|
|
cert_auth.path = xstrdup(ssl_cert);
|
|
|
|
credential_fill(&cert_auth);
|
|
|
|
}
|
|
|
|
return 1;
|
2009-05-28 05:16:02 +02:00
|
|
|
}
|
|
|
|
|
http: centralize the accounting of libcurl dependencies
As discussed in 644de29e220 (http: drop support for curl < 7.19.4,
2021-07-30) checking against LIBCURL_VERSION_NUM isn't as reliable as
checking specific symbols present in curl, as some distros have been
known to backport features.
However, while some of the curl_easy_setopt() arguments we rely on are
macros, others are enum, and we can't assume that those that are
macros won't change into enums in the future.
So we're still going to have to check LIBCURL_VERSION_NUM, but by
doing that in one central place and using a macro definition of our
own, anyone who's backporting features can define it themselves, and
thus have access to more modern curl features that they backported,
even if they didn't bump the LIBCURL_VERSION_NUM.
More importantly, as shown in a preceding commit doing these version
checks makes for hard to read and possibly buggy code, as shown by the
bug fixed there where we were conflating base 10 for base 16 when
comparing the version.
By doing them all in one place we'll hopefully reduce the chances of
such future mistakes, furthermore it now becomes easier to see at a
glance what the oldest supported version is, which makes it easier to
reason about any future deprecation similar to the recent
e48a623dea0 (Merge branch 'ab/http-drop-old-curl', 2021-08-24).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-13 16:51:28 +02:00
|
|
|
#ifdef GIT_CURL_HAVE_CURLOPT_PROXY_KEYPASSWD
|
2020-03-04 19:40:05 +01:00
|
|
|
static int has_proxy_cert_password(void)
|
|
|
|
{
|
|
|
|
if (http_proxy_ssl_cert == NULL || proxy_ssl_cert_password_required != 1)
|
|
|
|
return 0;
|
|
|
|
if (!proxy_cert_auth.password) {
|
|
|
|
proxy_cert_auth.protocol = xstrdup("cert");
|
2020-04-20 07:05:56 +02:00
|
|
|
proxy_cert_auth.host = xstrdup("");
|
2020-03-04 19:40:05 +01:00
|
|
|
proxy_cert_auth.username = xstrdup("");
|
|
|
|
proxy_cert_auth.path = xstrdup(http_proxy_ssl_cert);
|
|
|
|
credential_fill(&proxy_cert_auth);
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
http: centralize the accounting of libcurl dependencies
As discussed in 644de29e220 (http: drop support for curl < 7.19.4,
2021-07-30) checking against LIBCURL_VERSION_NUM isn't as reliable as
checking specific symbols present in curl, as some distros have been
known to backport features.
However, while some of the curl_easy_setopt() arguments we rely on are
macros, others are enum, and we can't assume that those that are
macros won't change into enums in the future.
So we're still going to have to check LIBCURL_VERSION_NUM, but by
doing that in one central place and using a macro definition of our
own, anyone who's backporting features can define it themselves, and
thus have access to more modern curl features that they backported,
even if they didn't bump the LIBCURL_VERSION_NUM.
More importantly, as shown in a preceding commit doing these version
checks makes for hard to read and possibly buggy code, as shown by the
bug fixed there where we were conflating base 10 for base 16 when
comparing the version.
By doing them all in one place we'll hopefully reduce the chances of
such future mistakes, furthermore it now becomes easier to see at a
glance what the oldest supported version is, which makes it easier to
reason about any future deprecation similar to the recent
e48a623dea0 (Merge branch 'ab/http-drop-old-curl', 2021-08-24).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-13 16:51:28 +02:00
|
|
|
#ifdef GITCURL_HAVE_CURLOPT_TCP_KEEPALIVE
|
2013-10-15 02:06:14 +02:00
|
|
|
static void set_curl_keepalive(CURL *c)
|
|
|
|
{
|
|
|
|
curl_easy_setopt(c, CURLOPT_TCP_KEEPALIVE, 1);
|
|
|
|
}
|
|
|
|
|
2021-07-30 11:31:54 +02:00
|
|
|
#else
|
2013-10-13 00:29:40 +02:00
|
|
|
static int sockopt_callback(void *client, curl_socket_t fd, curlsocktype type)
|
|
|
|
{
|
|
|
|
int ka = 1;
|
|
|
|
int rc;
|
|
|
|
socklen_t len = (socklen_t)sizeof(ka);
|
|
|
|
|
|
|
|
if (type != CURLSOCKTYPE_IPCXN)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
rc = setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, (void *)&ka< |