Jeff King <peff@xxxxxxxx> writes:
> ...
> I think the best we can do is to put the auth data in a static buffer
> and feed that to curl. We end up rewriting the auth data into our buffer
> over and over, but at least we don't re-malloc it. Like this:
>
> diff --git a/http.c b/http.c
> index f3f83d7..374c3bb 100644
> --- a/http.c
> +++ b/http.c
> @@ -211,12 +211,12 @@ static int http_options(const char *var, const char *value, void *cb)
> static void init_curl_http_auth(CURL *result)
> {
> if (http_auth.username) {
> - struct strbuf up = STRBUF_INIT;
> + static struct strbuf up = STRBUF_INIT;
> credential_fill(&http_auth);
> + strbuf_reset(&up);
> strbuf_addf(&up, "%s:%s",
> http_auth.username, http_auth.password);
> - curl_easy_setopt(result, CURLOPT_USERPWD,
> - strbuf_detach(&up, NULL));
> + curl_easy_setopt(result, CURLOPT_USERPWD, up.buf);
> }
> }
Yeah, that's sad but I agree that is probably the best we could do. Do
you want me to squash it in?
> By the way, this touches on an area that I noticed while refactoring the
> http auth code a while ago, but decided not to tackle at the time. We
> fill in the auth information early, and then never bother to revisit it
> as URLs change. So for example, if I got a redirect from host A to host
> B, we would continue to use the credential for host A and host B. Which
> is maybe convenient, and maybe a security issue.
Good point. Do we follow redirects, though?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html