Regarding using an HTTPS URL, note that HTTP transport had possible allocator/deallocator mismatch, which has been corrected, with Git 2.25 (Q1 2020).
So if you were using Git 2.24, http.extraheader
would not have worked anyway.
See commit 4d17fd2 (06 Nov 2019) by Johannes Schindelin (dscho
).
(Merged by Junio C Hamano -- gitster
-- in commit bad5ed3, 01 Dec 2019)
remote-curl
: unbreak http.extraHeader with custom allocators
Signed-off-by: Johannes Schindelin
In 93b980e58f5 ("http
: use xmalloc with cURL", 2019-08-15, Git v2.24.0-rc0 -- merge listed in batch #3), 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.
For self-signed certificate, disabling SSL verification globally might be considered a security risk and should be implemented only for testing.
Referencing the self-signed certificate by GIT_SSL_CAINFO
is more secure.