{"thread":{"id":"45602","subject":"[RFC] dropping support for ancient versions of curl","startedAt":"2017-04-04T02:54:46Z","lastAt":"2017-04-14T11:12:23Z","messageCount":48,"participants":["Jeff King","Jessie Hernandez","Ævar Arnfjörð Bjarmason","Johannes Schindelin","Frank Gevaerts","Brandon Williams","Stefan Beller","Tom G. Christensen","Franke, Knut","brian m. carlson","Todd Zullinger","Junio C Hamano","Jacob Keller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"316130","messageId":"20170404025438.bgxz5sfmrawqswcj@sigill.intra.peff.net","threadId":"45602","inReplyTo":null,"subject":"[RFC] dropping support for ancient versions of curl","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-04T02:54:38Z","receivedAt":"2017-04-04T02:54:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"A nearby thread raised the question of whether we can rely on a version\nof libcurl that contains a particular feature. The version in question\nis curl 7.11.1, which came out in March 2004.\n\nMy feeling is that this is old enough to stop caring about. Which means\nwe can drop some of the #ifdefs that clutter the HTTP code (and there's\na patch at the end of this mail dropping support for everything older\nthan 7.11.1). But that made wonder: how old is too old? I think it's\nnice that we don't force people to upgrade to the latest version of\ncurl. But at some point, if you are running a 13-year-old version of\nlibcurl, how likely are you to run a brand new version of Git? :)\n\nIf we declared 7.16.0 as a cutoff, we could unconditionally define\nUSE_CURL_MULTI, which gets rid of quite a few messy ifdefs.\n\n-Peff\n\n---\n http.c        | 51 -----------------------------------\n http.h        | 11 --------\n remote-curl.c |  3 ---\n 3 files changed, 65 deletions(-)\n\ndiff --git a/http.c b/http.c\nindex 8d94e2c63..7a81f0b68 100644\n--- a/http.c\n+++ b/http.c\n@@ -12,19 +12,11 @@\n #include \"transport.h\"\n \n static struct trace_key trace_curl = TRACE_KEY_INIT(CURL);\n-#if LIBCURL_VERSION_NUM >= 0x070a08\n long int git_curl_ipresolve = CURL_IPRESOLVE_WHATEVER;\n-#else\n-long int git_curl_ipresolve;\n-#endif\n int active_requests;\n int http_is_verbose;\n size_t http_post_buffer = 16 * LARGE_PACKET_MAX;\n \n-#if LIBCURL_VERSION_NUM >= 0x070a06\n-#define LIBCURL_CAN_HANDLE_AUTH_ANY\n-#endif\n-\n static int min_curl_sessions = 1;\n static int curl_session_count;\n #ifdef USE_CURL_MULTI\n@@ -57,12 +49,8 @@ static struct {\n \t{ \"tlsv1.2\", CURL_SSLVERSION_TLSv1_2 },\n #endif\n };\n-#if LIBCURL_VERSION_NUM >= 0x070903\n static const char *ssl_key;\n-#endif\n-#if LIBCURL_VERSION_NUM >= 0x070908\n static const char *ssl_capath;\n-#endif\n #if LIBCURL_VERSION_NUM >= 0x072c00\n static const char *ssl_pinnedkey;\n #endif\n@@ -81,9 +69,7 @@ static struct {\n \t{ \"digest\", CURLAUTH_DIGEST },\n \t{ \"negotiate\", CURLAUTH_GSSNEGOTIATE },\n \t{ \"ntlm\", CURLAUTH_NTLM },\n-#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY\n \t{ \"anyauth\", CURLAUTH_ANY },\n-#endif\n \t/*\n \t * CURLAUTH_DIGEST_IE has no corresponding command-line option in\n \t * curl(1) and is not included in CURLAUTH_ANY, so we leave it out\n@@ -123,7 +109,6 @@ enum http_follow_config http_follow_config = HTTP_FOLLOW_INITIAL;\n \n static struct credential cert_auth = CREDENTIAL_INIT;\n static int ssl_cert_password_required;\n-#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY\n static unsigned long http_auth_methods = CURLAUTH_ANY;\n static int http_auth_methods_restricted;\n /* Modes for which empty_auth cannot actually help us. */\n@@ -133,7 +118,6 @@ static unsigned long empty_auth_useless =\n \t| CURLAUTH_DIGEST_IE\n #endif\n \t| CURLAUTH_DIGEST;\n-#endif\n \n static struct curl_slist *pragma_header;\n static struct curl_slist *no_pragma_header;\n@@ -207,12 +191,8 @@ static void finish_active_slot(struct active_request_slot *slot)\n \tif (slot->results != NULL) {\n \t\tslot->results->curl_result = slot->curl_result;\n \t\tslot->results->http_code = slot->http_code;\n-#if LIBCURL_VERSION_NUM >= 0x070a08\n \t\tcurl_easy_getinfo(slot->curl, CURLINFO_HTTPAUTH_AVAIL,\n \t\t\t\t  &slot->results->auth_avail);\n-#else\n-\t\tslot->results->auth_avail = 0;\n-#endif\n \n \t\tcurl_easy_getinfo(slot->curl, CURLINFO_HTTP_CONNECTCODE,\n \t\t\t&slot->results->http_connectcode);\n@@ -272,14 +252,10 @@ static int http_options(const char *var, const char *value, void *cb)\n \t\treturn git_config_string(&ssl_version, var, value);\n \tif (!strcmp(\"http.sslcert\", var))\n \t\treturn git_config_string(&ssl_cert, var, value);\n-#if LIBCURL_VERSION_NUM >= 0x070903\n \tif (!strcmp(\"http.sslkey\", var))\n \t\treturn git_config_string(&ssl_key, var, value);\n-#endif\n-#if LIBCURL_VERSION_NUM >= 0x070908\n \tif (!strcmp(\"http.sslcapath\", var))\n \t\treturn git_config_pathname(&ssl_capath, var, value);\n-#endif\n \tif (!strcmp(\"http.sslcainfo\", var))\n \t\treturn git_config_pathname(&ssl_cainfo, var, value);\n \tif (!strcmp(\"http.sslcertpasswordprotected\", var)) {\n@@ -398,12 +374,6 @@ static int curl_empty_auth_enabled(void)\n \tif (curl_empty_auth >= 0)\n \t\treturn curl_empty_auth;\n \n-#ifndef LIBCURL_CAN_HANDLE_AUTH_ANY\n-\t/*\n-\t * Our libcurl is too old to do AUTH_ANY in the first place;\n-\t * just default to turning the feature off.\n-\t */\n-#else\n \t/*\n \t * In the automatic case, kick in the empty-auth\n \t * hack as long as we would potentially try some\n@@ -416,7 +386,6 @@ static int curl_empty_auth_enabled(void)\n \tif (http_auth_methods_restricted &&\n \t    (http_auth_methods & ~empty_auth_useless))\n \t\treturn 1;\n-#endif\n \treturn 0;\n }\n \n@@ -487,7 +456,6 @@ static void init_curl_proxy_auth(CURL *result)\n \n \tvar_override(&http_proxy_authmethod, getenv(\"GIT_HTTP_PROXY_AUTHMETHOD\"));\n \n-#if LIBCURL_VERSION_NUM >= 0x070a07 /* CURLOPT_PROXYAUTH and CURLAUTH_ANY */\n \tif (http_proxy_authmethod) {\n \t\tint i;\n \t\tfor (i = 0; i < ARRAY_SIZE(proxy_authmethods); i++) {\n@@ -505,7 +473,6 @@ static void init_curl_proxy_auth(CURL *result)\n \t}\n \telse\n \t\tcurl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY);\n-#endif\n }\n \n static int has_cert_password(void)\n@@ -707,12 +674,8 @@ static CURL *get_curl_handle(void)\n \t\tcurl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, 2);\n \t}\n \n-#if LIBCURL_VERSION_NUM >= 0x070907\n \tcurl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);\n-#endif\n-#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY\n \tcurl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);\n-#endif\n \n #if LIBCURL_VERSION_NUM >= 0x071600\n \tif (curl_deleg) {\n@@ -759,14 +722,10 @@ static CURL *get_curl_handle(void)\n \t\tcurl_easy_setopt(result, CURLOPT_SSLCERT, ssl_cert);\n \tif (has_cert_password())\n \t\tcurl_easy_setopt(result, CURLOPT_KEYPASSWD, cert_auth.password);\n-#if LIBCURL_VERSION_NUM >= 0x070903\n \tif (ssl_key != NULL)\n \t\tcurl_easy_setopt(result, CURLOPT_SSLKEY, ssl_key);\n-#endif\n-#if LIBCURL_VERSION_NUM >= 0x070908\n \tif (ssl_capath != NULL)\n \t\tcurl_easy_setopt(result, CURLOPT_CAPATH, ssl_capath);\n-#endif\n #if LIBCURL_VERSION_NUM >= 0x072c00\n \tif (ssl_pinnedkey != NULL)\n \t\tcurl_easy_setopt(result, CURLOPT_PINNEDPUBLICKEY, ssl_pinnedkey);\n@@ -933,12 +892,8 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)\n \t\tcurl_ssl_verify = 0;\n \n \tset_from_env(&ssl_cert, \"GIT_SSL_CERT\");\n-#if LIBCURL_VERSION_NUM >= 0x070903\n \tset_from_env(&ssl_key, \"GIT_SSL_KEY\");\n-#endif\n-#if LIBCURL_VERSION_NUM >= 0x070908\n \tset_from_env(&ssl_capath, \"GIT_SSL_CAPATH\");\n-#endif\n \tset_from_env(&ssl_cainfo, \"GIT_SSL_CAINFO\");\n \n \tset_from_env(&user_agent, \"GIT_HTTP_USER_AGENT\");\n@@ -1111,12 +1066,8 @@ struct active_request_slot *get_active_slot(void)\n \telse\n \t\tcurl_easy_setopt(slot->curl, CURLOPT_FOLLOWLOCATION, 0);\n \n-#if LIBCURL_VERSION_NUM >= 0x070a08\n \tcurl_easy_setopt(slot->curl, CURLOPT_IPRESOLVE, git_curl_ipresolve);\n-#endif\n-#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY\n \tcurl_easy_setopt(slot->curl, CURLOPT_HTTPAUTH, http_auth_methods);\n-#endif\n \tif (http_auth.password || curl_empty_auth_enabled())\n \t\tinit_curl_http_auth(slot->curl);\n \n@@ -1383,13 +1334,11 @@ static int handle_curl_result(struct slot_results *results)\n \t\t\tcredential_reject(&http_auth);\n \t\t\treturn HTTP_NOAUTH;\n \t\t} else {\n-#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY\n \t\t\thttp_auth_methods &= ~CURLAUTH_GSSNEGOTIATE;\n \t\t\tif (results->auth_avail) {\n \t\t\t\thttp_auth_methods &= results->auth_avail;\n \t\t\t\thttp_auth_methods_restricted = 1;\n \t\t\t}\n-#endif\n \t\t\treturn HTTP_REAUTH;\n \t\t}\n \t} else {\ndiff --git a/http.h b/http.h\nindex 02bccb7b0..d1de11a3d 100644\n--- a/http.h\n+++ b/http.h\n@@ -22,21 +22,10 @@\n #define DEFAULT_MAX_REQUESTS 5\n #endif\n \n-#if LIBCURL_VERSION_NUM < 0x070704\n-#define curl_global_cleanup() do { /* nothing */ } while (0)\n-#endif\n-#if LIBCURL_VERSION_NUM < 0x070800\n-#define curl_global_init(a) do { /* nothing */ } while (0)\n-#endif\n-\n #if (LIBCURL_VERSION_NUM < 0x070c04) || (LIBCURL_VERSION_NUM == 0x071000)\n #define NO_CURL_EASY_DUPHANDLE\n #endif\n \n-#if LIBCURL_VERSION_NUM < 0x070a03\n-#define CURLE_HTTP_RETURNED_ERROR CURLE_HTTP_NOT_FOUND\n-#endif\n-\n #if LIBCURL_VERSION_NUM < 0x070c03\n #define NO_CURL_IOCTL\n #endif\ndiff --git a/remote-curl.c b/remote-curl.c\nindex e953d06f6..c792942f0 100644\n--- a/remote-curl.c\n+++ b/remote-curl.c\n@@ -143,8 +143,6 @@ static int set_option(const char *name, const char *value)\n \t} else if (!strcmp(name, \"push-option\")) {\n \t\tstring_list_append(&options.push_options, value);\n \t\treturn 0;\n-\n-#if LIBCURL_VERSION_NUM >= 0x070a08\n \t} else if (!strcmp(name, \"family\")) {\n \t\tif (!strcmp(value, \"ipv4\"))\n \t\t\tgit_curl_ipresolve = CURL_IPRESOLVE_V4;\n@@ -155,7 +153,6 @@ static int set_option(const char *name, const char *value)\n \t\telse\n \t\t\treturn -1;\n \t\treturn 0;\n-#endif /* LIBCURL_VERSION_NUM >= 0x070a08 */\n \t} else {\n \t\treturn 1 /* unsupported */;\n \t}\n"},{"id":"316131","messageId":"20170404030804.tv3wfi3cko3ehjtr@sigill.intra.peff.net","threadId":"45602","inReplyTo":"20170404025438.bgxz5sfmrawqswcj@sigill.intra.peff.net","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-04T03:08:05Z","receivedAt":"2017-04-04T03:08:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 03, 2017 at 10:54:38PM -0400, Jeff King wrote:\n\n> If we declared 7.16.0 as a cutoff, we could unconditionally define\n> USE_CURL_MULTI, which gets rid of quite a few messy ifdefs.\n\nThat version came out 11 years ago. Here's what that patch would look\nlike (on top of my other one, but note I missed one older ifdef in the\nlast one that's included here).\n\nAnd we could go further. There are a number of ifdefs around 7.19.1 (Nov\n2008), 7.22 (Sep 2011). A 5-year cutoff puts us at 7.24. That's getting\nclose enough that I'd probably start looking at what long-term distros\nlike RHEL are still shipping and supporting.\n\n-Peff\n\n---\n Documentation/config.txt |  3 +-\n http-push.c              | 23 --------------\n http-walker.c            | 12 --------\n http.c                   | 57 +----------------------------------\n http.h                   | 18 -----------\n remote-curl.c            |  4 ---\n 6 files changed, 2 insertions(+), 115 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 475e874d5..2b04c1777 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1942,8 +1942,7 @@ http.maxRequests::\n http.minSessions::\n \tThe number of curl sessions (counted across slots) to be kept across\n \trequests. They will not be ended with curl_easy_cleanup() until\n-\thttp_cleanup() is invoked. If USE_CURL_MULTI is not defined, this\n-\tvalue will be capped at 1. Defaults to 1.\n+\thttp_cleanup() is invoked. Defaults to 1.\n \n http.postBuffer::\n \tMaximum size in bytes of the buffer used by smart HTTP\ndiff --git a/http-push.c b/http-push.c\nindex f0e3108f7..40146cdd6 100644\n--- a/http-push.c\n+++ b/http-push.c\n@@ -198,10 +198,8 @@ static void curl_setup_http(CURL *curl, const char *url,\n \tcurl_easy_setopt(curl, CURLOPT_INFILE, buffer);\n \tcurl_easy_setopt(curl, CURLOPT_INFILESIZE, buffer->buf.len);\n \tcurl_easy_setopt(curl, CURLOPT_READFUNCTION, fread_buffer);\n-#ifndef NO_CURL_IOCTL\n \tcurl_easy_setopt(curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);\n \tcurl_easy_setopt(curl, CURLOPT_IOCTLDATA, buffer);\n-#endif\n \tcurl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, write_fn);\n \tcurl_easy_setopt(curl, CURLOPT_NOBODY, 0);\n \tcurl_easy_setopt(curl, CURLOPT_CUSTOMREQUEST, custom_req);\n@@ -244,8 +242,6 @@ static void process_response(void *callback_data)\n \tfinish_request(request);\n }\n \n-#ifdef USE_CURL_MULTI\n-\n static void start_fetch_loose(struct transfer_request *request)\n {\n \tstruct active_request_slot *slot;\n@@ -295,7 +291,6 @@ static void start_mkcol(struct transfer_request *request)\n \t\trequest->url = NULL;\n \t}\n }\n-#endif\n \n static void start_fetch_packed(struct transfer_request *request)\n {\n@@ -600,7 +595,6 @@ static void finish_request(struct transfer_request *request)\n \t}\n }\n \n-#ifdef USE_CURL_MULTI\n static int is_running_queue;\n static int fill_active_slot(void *unused)\n {\n@@ -624,7 +618,6 @@ static int fill_active_slot(void *unused)\n \t}\n \treturn 0;\n }\n-#endif\n \n static void get_remote_object_list(unsigned char parent);\n \n@@ -653,10 +646,8 @@ static void add_fetch_request(struct object *obj)\n \trequest->next = request_queue_head;\n \trequest_queue_head = request;\n \n-#ifdef USE_CURL_MULTI\n \tfill_active_slots();\n \tstep_active_slots();\n-#endif\n }\n \n static int add_send_request(struct object *obj, struct remote_lock *lock)\n@@ -691,10 +682,8 @@ static int add_send_request(struct object *obj, struct remote_lock *lock)\n \trequest->next = request_queue_head;\n \trequest_queue_head = request;\n \n-#ifdef USE_CURL_MULTI\n \tfill_active_slots();\n \tstep_active_slots();\n-#endif\n \n \treturn 1;\n }\n@@ -1673,21 +1662,15 @@ static int delete_remote_branch(const char *pattern, int force)\n \n static void run_request_queue(void)\n {\n-#ifdef USE_CURL_MULTI\n \tis_running_queue = 1;\n \tfill_active_slots();\n \tadd_fill_function(NULL, fill_active_slot);\n-#endif\n \tdo {\n \t\tfinish_all_active_slots();\n-#ifdef USE_CURL_MULTI\n \t\tfill_active_slots();\n-#endif\n \t} while (request_queue_head && !aborted);\n \n-#ifdef USE_CURL_MULTI\n \tis_running_queue = 0;\n-#endif\n }\n \n int cmd_main(int argc, const char **argv)\n@@ -1763,10 +1746,6 @@ int cmd_main(int argc, const char **argv)\n \t\tbreak;\n \t}\n \n-#ifndef USE_CURL_MULTI\n-\tdie(\"git-push is not available for http/https repository when not compiled with USE_CURL_MULTI\");\n-#endif\n-\n \tif (!repo->url)\n \t\tusage(http_push_usage);\n \n@@ -1779,9 +1758,7 @@ int cmd_main(int argc, const char **argv)\n \n \thttp_init(NULL, repo->url, 1);\n \n-#ifdef USE_CURL_MULTI\n \tis_running_queue = 0;\n-#endif\n \n \t/* Verify DAV compliance/lock support */\n \tif (!locking_available()) {\ndiff --git a/http-walker.c b/http-walker.c\nindex ee049cb13..b5b8e03b0 100644\n--- a/http-walker.c\n+++ b/http-walker.c\n@@ -119,7 +119,6 @@ static void release_object_request(struct object_request *obj_req)\n \tfree(obj_req);\n }\n \n-#ifdef USE_CURL_MULTI\n static int fill_active_slot(struct walker *walker)\n {\n \tstruct object_request *obj_req;\n@@ -138,7 +137,6 @@ static int fill_active_slot(struct walker *walker)\n \t}\n \treturn 0;\n }\n-#endif\n \n static void prefetch(struct walker *walker, unsigned char *sha1)\n {\n@@ -155,10 +153,8 @@ static void prefetch(struct walker *walker, unsigned char *sha1)\n \thttp_is_verbose = walker->get_verbosely;\n \tlist_add_tail(&newreq->node, &object_queue_head);\n \n-#ifdef USE_CURL_MULTI\n \tfill_active_slots();\n \tstep_active_slots();\n-#endif\n }\n \n static int is_alternate_allowed(const char *url)\n@@ -346,11 +342,9 @@ static void fetch_alternates(struct walker *walker, const char *base)\n \t * wait for them to arrive and return to processing this request's\n \t * curl message\n \t */\n-#ifdef USE_CURL_MULTI\n \twhile (cdata->got_alternates == 0) {\n \t\tstep_active_slots();\n \t}\n-#endif\n \n \t/* Nothing to do if they've already been fetched */\n \tif (cdata->got_alternates == 1)\n@@ -493,12 +487,8 @@ static int fetch_object(struct walker *walker, unsigned char *sha1)\n \t\treturn 0;\n \t}\n \n-#ifdef USE_CURL_MULTI\n \twhile (obj_req->state == WAITING)\n \t\tstep_active_slots();\n-#else\n-\tstart_object_request(walker, obj_req);\n-#endif\n \n \t/*\n \t * obj_req->req might change when fetching alternates in the callback\n@@ -618,9 +608,7 @@ struct walker *get_http_walker(const char *url)\n \twalker->cleanup = cleanup;\n \twalker->data = data;\n \n-#ifdef USE_CURL_MULTI\n \tadd_fill_function(walker, (int (*)(void *)) fill_active_slot);\n-#endif\n \n \treturn walker;\n }\ndiff --git a/http.c b/http.c\nindex e9918f184..d4f8601ba 100644\n--- a/http.c\n+++ b/http.c\n@@ -19,10 +19,8 @@ size_t http_post_buffer = 16 * LARGE_PACKET_MAX;\n \n static int min_curl_sessions = 1;\n static int curl_session_count;\n-#ifdef USE_CURL_MULTI\n static int max_requests = -1;\n static CURLM *curlm;\n-#endif\n #ifndef NO_CURL_EASY_DUPHANDLE\n static CURL *curl_default;\n #endif\n@@ -99,14 +97,6 @@ static int curl_empty_auth = -1;\n \n enum http_follow_config http_follow_config = HTTP_FOLLOW_INITIAL;\n \n-#if LIBCURL_VERSION_NUM >= 0x071700\n-/* Use CURLOPT_KEYPASSWD as is */\n-#elif LIBCURL_VERSION_NUM >= 0x070903\n-#define CURLOPT_KEYPASSWD CURLOPT_SSLKEYPASSWD\n-#else\n-#define CURLOPT_KEYPASSWD CURLOPT_SSLCERTPASSWD\n-#endif\n-\n static struct credential cert_auth = CREDENTIAL_INIT;\n static int ssl_cert_password_required;\n static unsigned long http_auth_methods = CURLAUTH_ANY;\n@@ -140,7 +130,6 @@ size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void *buffer_)\n \treturn size;\n }\n \n-#ifndef NO_CURL_IOCTL\n curlioerr ioctl_buffer(CURL *handle, int cmd, void *clientp)\n {\n \tstruct buffer *buffer = clientp;\n@@ -157,7 +146,6 @@ curlioerr ioctl_buffer(CURL *handle, int cmd, void *clientp)\n \t\treturn CURLIOE_UNKNOWNCMD;\n \t}\n }\n-#endif\n \n size_t fwrite_buffer(char *ptr, size_t eltsize, size_t nmemb, void *buffer_)\n {\n@@ -205,12 +193,9 @@ static void finish_active_slot(struct active_request_slot *slot)\n \n static void xmulti_remove_handle(struct active_request_slot *slot)\n {\n-#ifdef USE_CURL_MULTI\n \tcurl_multi_remove_handle(curlm, slot->curl);\n-#endif\n }\n \n-#ifdef USE_CURL_MULTI\n static void process_curl_messages(void)\n {\n \tint num_messages;\n@@ -238,7 +223,6 @@ static void process_curl_messages(void)\n \t\tcurl_message = curl_multi_info_read(curlm, &num_messages);\n \t}\n }\n-#endif\n \n static int http_options(const char *var, const char *value, void *cb)\n {\n@@ -268,18 +252,14 @@ static int http_options(const char *var, const char *value, void *cb)\n \t}\n \tif (!strcmp(\"http.minsessions\", var)) {\n \t\tmin_curl_sessions = git_config_int(var, value);\n-#ifndef USE_CURL_MULTI\n \t\tif (min_curl_sessions > 1)\n \t\t\tmin_curl_sessions = 1;\n-#endif\n \t\treturn 0;\n \t}\n-#ifdef USE_CURL_MULTI\n \tif (!strcmp(\"http.maxrequests\", var)) {\n \t\tmax_requests = git_config_int(var, value);\n \t\treturn 0;\n \t}\n-#endif\n \tif (!strcmp(\"http.lowspeedlimit\", var)) {\n \t\tcurl_low_speed_limit = (long)git_config_int(var, value);\n \t\treturn 0;\n@@ -494,7 +474,7 @@ static void set_curl_keepalive(CURL *c)\n \tcurl_easy_setopt(c, CURLOPT_TCP_KEEPALIVE, 1);\n }\n \n-#elif LIBCURL_VERSION_NUM >= 0x071000\n+#else\n static int sockopt_callback(void *client, curl_socket_t fd, curlsocktype type)\n {\n \tint ka = 1;\n@@ -516,13 +496,6 @@ static void set_curl_keepalive(CURL *c)\n \tcurl_easy_setopt(c, CURLOPT_SOCKOPTFUNCTION, sockopt_callback);\n }\n \n-#else\n-static void set_curl_keepalive(CURL *c)\n-{\n-\t/* not supported on older curl versions */\n-}\n-#endif\n-\n static void redact_sensitive_header(struct strbuf *header)\n {\n \tconst char *sensitive_header;\n@@ -876,7 +849,6 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)\n \tno_pragma_header = curl_slist_append(http_copy_default_headers(),\n \t\t\"Pragma:\");\n \n-#ifdef USE_CURL_MULTI\n \t{\n \t\tchar *http_max_requests = getenv(\"GIT_HTTP_MAX_REQUESTS\");\n \t\tif (http_max_requests != NULL)\n@@ -886,7 +858,6 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)\n \tcurlm = curl_multi_init();\n \tif (!curlm)\n \t\tdie(\"curl_multi_init failed\");\n-#endif\n \n \tif (getenv(\"GIT_SSL_NO_VERIFY\"))\n \t\tcurl_ssl_verify = 0;\n@@ -909,10 +880,8 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)\n \t\tcurl_ssl_verify = 1;\n \n \tcurl_session_count = 0;\n-#ifdef USE_CURL_MULTI\n \tif (max_requests < 1)\n \t\tmax_requests = DEFAULT_MAX_REQUESTS;\n-#endif\n \n \tif (getenv(\"GIT_CURL_FTP_NO_EPSV\"))\n \t\tcurl_ftp_no_epsv = 1;\n@@ -949,9 +918,7 @@ void http_cleanup(void)\n \tcurl_easy_cleanup(curl_default);\n #endif\n \n-#ifdef USE_CURL_MULTI\n \tcurl_multi_cleanup(curlm);\n-#endif\n \tcurl_global_cleanup();\n \n \tcurl_slist_free_all(extra_http_headers);\n@@ -996,7 +963,6 @@ struct active_request_slot *get_active_slot(void)\n \tstruct active_request_slot *slot = active_queue_head;\n \tstruct active_request_slot *newslot;\n \n-#ifdef USE_CURL_MULTI\n \tint num_transfers;\n \n \t/* Wait for a slot to open up if the queue is full */\n@@ -1005,7 +971,6 @@ struct active_request_slot *get_active_slot(void)\n \t\tif (num_transfers < active_requests)\n \t\t\tprocess_curl_messages();\n \t}\n-#endif\n \n \twhile (slot != NULL && slot->in_use)\n \t\tslot = slot->next;\n@@ -1076,7 +1041,6 @@ struct active_request_slot *get_active_slot(void)\n \n int start_active_slot(struct active_request_slot *slot)\n {\n-#ifdef USE_CURL_MULTI\n \tCURLMcode curlm_result = curl_multi_add_handle(curlm, slot->curl);\n \tint num_transfers;\n \n@@ -1094,11 +1058,9 @@ int start_active_slot(struct active_request_slot *slot)\n \t * something.\n \t */\n \tcurl_multi_perform(curlm, &num_transfers);\n-#endif\n \treturn 1;\n }\n \n-#ifdef USE_CURL_MULTI\n struct fill_chain {\n \tvoid *data;\n \tint (*fill)(void *);\n@@ -1157,11 +1119,9 @@ void step_active_slots(void)\n \t\tfill_active_slots();\n \t}\n }\n-#endif\n \n void run_active_slot(struct active_request_slot *slot)\n {\n-#ifdef USE_CURL_MULTI\n \tfd_set readfds;\n \tfd_set writefds;\n \tfd_set excfds;\n@@ -1174,7 +1134,6 @@ void run_active_slot(struct active_request_slot *slot)\n \t\tstep_active_slots();\n \n \t\tif (slot->in_use) {\n-#if LIBCURL_VERSION_NUM >= 0x070f04\n \t\t\tlong curl_timeout;\n \t\t\tcurl_multi_timeout(curlm, &curl_timeout);\n \t\t\tif (curl_timeout == 0) {\n@@ -1186,10 +1145,6 @@ void run_active_slot(struct active_request_slot *slot)\n \t\t\t\tselect_timeout.tv_sec  =  curl_timeout / 1000;\n \t\t\t\tselect_timeout.tv_usec = (curl_timeout % 1000) * 1000;\n \t\t\t}\n-#else\n-\t\t\tselect_timeout.tv_sec  = 0;\n-\t\t\tselect_timeout.tv_usec = 50000;\n-#endif\n \n \t\t\tmax_fd = -1;\n \t\t\tFD_ZERO(&readfds);\n@@ -1212,12 +1167,6 @@ void run_active_slot(struct active_request_slot *slot)\n \t\t\tselect(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);\n \t\t}\n \t}\n-#else\n-\twhile (slot->in_use) {\n-\t\tslot->curl_result = curl_easy_perform(slot->curl);\n-\t\tfinish_active_slot(slot);\n-\t}\n-#endif\n }\n \n static void release_active_slot(struct active_request_slot *slot)\n@@ -1231,9 +1180,7 @@ static void release_active_slot(struct active_request_slot *slot)\n \t\t\tcurl_session_count--;\n \t\t}\n \t}\n-#ifdef USE_CURL_MULTI\n \tfill_active_slots();\n-#endif\n }\n \n void finish_all_active_slots(void)\n@@ -1344,12 +1291,10 @@ static int handle_curl_result(struct slot_results *results)\n \t} else {\n \t\tif (results->http_connectcode == 407)\n \t\t\tcredential_reject(&proxy_auth);\n-#if LIBCURL_VERSION_NUM >= 0x070c00\n \t\tif (!curl_errorstr[0])\n \t\t\tstrlcpy(curl_errorstr,\n \t\t\t\tcurl_easy_strerror(results->curl_result),\n \t\t\t\tsizeof(curl_errorstr));\n-#endif\n \t\treturn HTTP_ERROR;\n \t}\n }\ndiff --git a/http.h b/http.h\nindex d1de11a3d..4054af685 100644\n--- a/http.h\n+++ b/http.h\n@@ -10,26 +10,12 @@\n #include \"remote.h\"\n #include \"url.h\"\n \n-/*\n- * We detect based on the cURL version if multi-transfer is\n- * usable in this implementation and define this symbol accordingly.\n- * This shouldn't be set by the Makefile or by the user (e.g. via CFLAGS).\n- */\n-#undef USE_CURL_MULTI\n-\n-#if LIBCURL_VERSION_NUM >= 0x071000\n-#define USE_CURL_MULTI\n #define DEFAULT_MAX_REQUESTS 5\n-#endif\n \n #if (LIBCURL_VERSION_NUM < 0x070c04) || (LIBCURL_VERSION_NUM == 0x071000)\n #define NO_CURL_EASY_DUPHANDLE\n #endif\n \n-#if LIBCURL_VERSION_NUM < 0x070c03\n-#define NO_CURL_IOCTL\n-#endif\n-\n /*\n  * CURLOPT_USE_SSL was known as CURLOPT_FTP_SSL up to 7.16.4,\n  * and the constants were known as CURLFTPSSL_*\n@@ -67,9 +53,7 @@ struct buffer {\n extern size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void *strbuf);\n extern size_t fwrite_buffer(char *ptr, size_t eltsize, size_t nmemb, void *strbuf);\n extern size_t fwrite_null(char *ptr, size_t eltsize, size_t nmemb, void *strbuf);\n-#ifndef NO_CURL_IOCTL\n extern curlioerr ioctl_buffer(CURL *handle, int cmd, void *clientp);\n-#endif\n \n /* Slot lifecycle functions */\n extern struct active_request_slot *get_active_slot(void);\n@@ -86,11 +70,9 @@ extern void finish_all_active_slots(void);\n int run_one_slot(struct active_request_slot *slot,\n \t\t struct slot_results *results);\n \n-#ifdef USE_CURL_MULTI\n extern void fill_active_slots(void);\n extern void add_fill_function(void *data, int (*fill)(void *));\n extern void step_active_slots(void);\n-#endif\n \n extern void http_init(struct remote *remote, const char *url,\n \t\t      int proactive_auth);\ndiff --git a/remote-curl.c b/remote-curl.c\nindex c792942f0..4997cc193 100644\n--- a/remote-curl.c\n+++ b/remote-curl.c\n@@ -434,7 +434,6 @@ static size_t rpc_out(void *ptr, size_t eltsize,\n \treturn avail;\n }\n \n-#ifndef NO_CURL_IOCTL\n static curlioerr rpc_ioctl(CURL *handle, int cmd, void *clientp)\n {\n \tstruct rpc_state *rpc = clientp;\n@@ -455,7 +454,6 @@ static curlioerr rpc_ioctl(CURL *handle, int cmd, void *clientp)\n \t\treturn CURLIOE_UNKNOWNCMD;\n \t}\n }\n-#endif\n \n static size_t rpc_in(char *ptr, size_t eltsize,\n \t\tsize_t nmemb, void *buffer_)\n@@ -595,10 +593,8 @@ static int post_rpc(struct rpc_state *rpc)\n \t\trpc->initial_buffer = 1;\n \t\tcurl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, rpc_out);\n \t\tcurl_easy_setopt(slot->curl, CURLOPT_INFILE, rpc);\n-#ifndef NO_CURL_IOCTL\n \t\tcurl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, rpc_ioctl);\n \t\tcurl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, rpc);\n-#endif\n \t\tif (options.verbosity > 1) {\n \t\t\tfprintf(stderr, \"POST %s (chunked)\\n\", rpc->service_name);\n \t\t\tfflush(stderr);\n"},{"id":"316132","messageId":"feb8c755bfd21b3f93cf0161a6692e75.squirrel@mail.jessiehernandez.com","threadId":"45602","inReplyTo":"20170404030804.tv3wfi3cko3ehjtr@sigill.intra.peff.net","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Jessie Hernandez","fromEmail":"git@jessiehernandez.com","sentAt":"2017-04-04T05:44:24Z","receivedAt":"2017-04-04T05:45:28Z","isPatch":false,"sender":{"key":"git@jessiehernandez.com","avatar":null},"body":"> On Mon, Apr 03, 2017 at 10:54:38PM -0400, Jeff King wrote:\n>\n>> If we declared 7.16.0 as a cutoff, we could unconditionally define\n>> USE_CURL_MULTI, which gets rid of quite a few messy ifdefs.\n>\n> That version came out 11 years ago. Here's what that patch would look\n> like (on top of my other one, but note I missed one older ifdef in the\n> last one that's included here).\n>\n> And we could go further. There are a number of ifdefs around 7.19.1 (Nov\n> 2008), 7.22 (Sep 2011). A 5-year cutoff puts us at 7.24. That's getting\n> close enough that I'd probably start looking at what long-term distros\n> like RHEL are still shipping and supporting.\n\nHi Peff,\n\nI am all for making code simpler and dropping ancient versions.\nI think we have to look at about the 7.19.1 mark.\n\nI can confirm on my Centos 6.8 machine and on RHEL 6.8 on the client side\ncurl 7.19.7 [1] is used. I do not know what other distros are using.\n\n------------------------\nJessie\n\n>\n> -Peff\n>\n> ---\n>  Documentation/config.txt |  3 +-\n>  http-push.c              | 23 --------------\n>  http-walker.c            | 12 --------\n>  http.c                   | 57 +----------------------------------\n>  http.h                   | 18 -----------\n>  remote-curl.c            |  4 ---\n>  6 files changed, 2 insertions(+), 115 deletions(-)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 475e874d5..2b04c1777 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -1942,8 +1942,7 @@ http.maxRequests::\n>  http.minSessions::\n>  \tThe number of curl sessions (counted across slots) to be kept across\n>  \trequests. They will not be ended with curl_easy_cleanup() until\n> -\thttp_cleanup() is invoked. If USE_CURL_MULTI is not defined, this\n> -\tvalue will be capped at 1. Defaults to 1.\n> +\thttp_cleanup() is invoked. Defaults to 1.\n>\n>  http.postBuffer::\n>  \tMaximum size in bytes of the buffer used by smart HTTP\n> diff --git a/http-push.c b/http-push.c\n> index f0e3108f7..40146cdd6 100644\n> --- a/http-push.c\n> +++ b/http-push.c\n> @@ -198,10 +198,8 @@ static void curl_setup_http(CURL *curl, const char\n> *url,\n>  \tcurl_easy_setopt(curl, CURLOPT_INFILE, buffer);\n>  \tcurl_easy_setopt(curl, CURLOPT_INFILESIZE, buffer->buf.len);\n>  \tcurl_easy_setopt(curl, CURLOPT_READFUNCTION, fread_buffer);\n> -#ifndef NO_CURL_IOCTL\n>  \tcurl_easy_setopt(curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);\n>  \tcurl_easy_setopt(curl, CURLOPT_IOCTLDATA, buffer);\n> -#endif\n>  \tcurl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, write_fn);\n>  \tcurl_easy_setopt(curl, CURLOPT_NOBODY, 0);\n>  \tcurl_easy_setopt(curl, CURLOPT_CUSTOMREQUEST, custom_req);\n> @@ -244,8 +242,6 @@ static void process_response(void *callback_data)\n>  \tfinish_request(request);\n>  }\n>\n> -#ifdef USE_CURL_MULTI\n> -\n>  static void start_fetch_loose(struct transfer_request *request)\n>  {\n>  \tstruct active_request_slot *slot;\n> @@ -295,7 +291,6 @@ static void start_mkcol(struct transfer_request\n> *request)\n>  \t\trequest->url = NULL;\n>  \t}\n>  }\n> -#endif\n>\n>  static void start_fetch_packed(struct transfer_request *request)\n>  {\n> @@ -600,7 +595,6 @@ static void finish_request(struct transfer_request\n> *request)\n>  \t}\n>  }\n>\n> -#ifdef USE_CURL_MULTI\n>  static int is_running_queue;\n>  static int fill_active_slot(void *unused)\n>  {\n> @@ -624,7 +618,6 @@ static int fill_active_slot(void *unused)\n>  \t}\n>  \treturn 0;\n>  }\n> -#endif\n>\n>  static void get_remote_object_list(unsigned char parent);\n>\n> @@ -653,10 +646,8 @@ static void add_fetch_request(struct object *obj)\n>  \trequest->next = request_queue_head;\n>  \trequest_queue_head = request;\n>\n> -#ifdef USE_CURL_MULTI\n>  \tfill_active_slots();\n>  \tstep_active_slots();\n> -#endif\n>  }\n>\n>  static int add_send_request(struct object *obj, struct remote_lock *lock)\n> @@ -691,10 +682,8 @@ static int add_send_request(struct object *obj,\n> struct remote_lock *lock)\n>  \trequest->next = request_queue_head;\n>  \trequest_queue_head = request;\n>\n> -#ifdef USE_CURL_MULTI\n>  \tfill_active_slots();\n>  \tstep_active_slots();\n> -#endif\n>\n>  \treturn 1;\n>  }\n> @@ -1673,21 +1662,15 @@ static int delete_remote_branch(const char\n> *pattern, int force)\n>\n>  static void run_request_queue(void)\n>  {\n> -#ifdef USE_CURL_MULTI\n>  \tis_running_queue = 1;\n>  \tfill_active_slots();\n>  \tadd_fill_function(NULL, fill_active_slot);\n> -#endif\n>  \tdo {\n>  \t\tfinish_all_active_slots();\n> -#ifdef USE_CURL_MULTI\n>  \t\tfill_active_slots();\n> -#endif\n>  \t} while (request_queue_head && !aborted);\n>\n> -#ifdef USE_CURL_MULTI\n>  \tis_running_queue = 0;\n> -#endif\n>  }\n>\n>  int cmd_main(int argc, const char **argv)\n> @@ -1763,10 +1746,6 @@ int cmd_main(int argc, const char **argv)\n>  \t\tbreak;\n>  \t}\n>\n> -#ifndef USE_CURL_MULTI\n> -\tdie(\"git-push is not available for http/https repository when not\n> compiled with USE_CURL_MULTI\");\n> -#endif\n> -\n>  \tif (!repo->url)\n>  \t\tusage(http_push_usage);\n>\n> @@ -1779,9 +1758,7 @@ int cmd_main(int argc, const char **argv)\n>\n>  \thttp_init(NULL, repo->url, 1);\n>\n> -#ifdef USE_CURL_MULTI\n>  \tis_running_queue = 0;\n> -#endif\n>\n>  \t/* Verify DAV compliance/lock support */\n>  \tif (!locking_available()) {\n> diff --git a/http-walker.c b/http-walker.c\n> index ee049cb13..b5b8e03b0 100644\n> --- a/http-walker.c\n> +++ b/http-walker.c\n> @@ -119,7 +119,6 @@ static void release_object_request(struct\n> object_request *obj_req)\n>  \tfree(obj_req);\n>  }\n>\n> -#ifdef USE_CURL_MULTI\n>  static int fill_active_slot(struct walker *walker)\n>  {\n>  \tstruct object_request *obj_req;\n> @@ -138,7 +137,6 @@ static int fill_active_slot(struct walker *walker)\n>  \t}\n>  \treturn 0;\n>  }\n> -#endif\n>\n>  static void prefetch(struct walker *walker, unsigned char *sha1)\n>  {\n> @@ -155,10 +153,8 @@ static void prefetch(struct walker *walker, unsigned\n> char *sha1)\n>  \thttp_is_verbose = walker->get_verbosely;\n>  \tlist_add_tail(&newreq->node, &object_queue_head);\n>\n> -#ifdef USE_CURL_MULTI\n>  \tfill_active_slots();\n>  \tstep_active_slots();\n> -#endif\n>  }\n>\n>  static int is_alternate_allowed(const char *url)\n> @@ -346,11 +342,9 @@ static void fetch_alternates(struct walker *walker,\n> const char *base)\n>  \t * wait for them to arrive and return to processing this request's\n>  \t * curl message\n>  \t */\n> -#ifdef USE_CURL_MULTI\n>  \twhile (cdata->got_alternates == 0) {\n>  \t\tstep_active_slots();\n>  \t}\n> -#endif\n>\n>  \t/* Nothing to do if they've already been fetched */\n>  \tif (cdata->got_alternates == 1)\n> @@ -493,12 +487,8 @@ static int fetch_object(struct walker *walker,\n> unsigned char *sha1)\n>  \t\treturn 0;\n>  \t}\n>\n> -#ifdef USE_CURL_MULTI\n>  \twhile (obj_req->state == WAITING)\n>  \t\tstep_active_slots();\n> -#else\n> -\tstart_object_request(walker, obj_req);\n> -#endif\n>\n>  \t/*\n>  \t * obj_req->req might change when fetching alternates in the callback\n> @@ -618,9 +608,7 @@ struct walker *get_http_walker(const char *url)\n>  \twalker->cleanup = cleanup;\n>  \twalker->data = data;\n>\n> -#ifdef USE_CURL_MULTI\n>  \tadd_fill_function(walker, (int (*)(void *)) fill_active_slot);\n> -#endif\n>\n>  \treturn walker;\n>  }\n> diff --git a/http.c b/http.c\n> index e9918f184..d4f8601ba 100644\n> --- a/http.c\n> +++ b/http.c\n> @@ -19,10 +19,8 @@ size_t http_post_buffer = 16 * LARGE_PACKET_MAX;\n>\n>  static int min_curl_sessions = 1;\n>  static int curl_session_count;\n> -#ifdef USE_CURL_MULTI\n>  static int max_requests = -1;\n>  static CURLM *curlm;\n> -#endif\n>  #ifndef NO_CURL_EASY_DUPHANDLE\n>  static CURL *curl_default;\n>  #endif\n> @@ -99,14 +97,6 @@ static int curl_empty_auth = -1;\n>\n>  enum http_follow_config http_follow_config = HTTP_FOLLOW_INITIAL;\n>\n> -#if LIBCURL_VERSION_NUM >= 0x071700\n> -/* Use CURLOPT_KEYPASSWD as is */\n> -#elif LIBCURL_VERSION_NUM >= 0x070903\n> -#define CURLOPT_KEYPASSWD CURLOPT_SSLKEYPASSWD\n> -#else\n> -#define CURLOPT_KEYPASSWD CURLOPT_SSLCERTPASSWD\n> -#endif\n> -\n>  static struct credential cert_auth = CREDENTIAL_INIT;\n>  static int ssl_cert_password_required;\n>  static unsigned long http_auth_methods = CURLAUTH_ANY;\n> @@ -140,7 +130,6 @@ size_t fread_buffer(char *ptr, size_t eltsize, size_t\n> nmemb, void *buffer_)\n>  \treturn size;\n>  }\n>\n> -#ifndef NO_CURL_IOCTL\n>  curlioerr ioctl_buffer(CURL *handle, int cmd, void *clientp)\n>  {\n>  \tstruct buffer *buffer = clientp;\n> @@ -157,7 +146,6 @@ curlioerr ioctl_buffer(CURL *handle, int cmd, void\n> *clientp)\n>  \t\treturn CURLIOE_UNKNOWNCMD;\n>  \t}\n>  }\n> -#endif\n>\n>  size_t fwrite_buffer(char *ptr, size_t eltsize, size_t nmemb, void\n> *buffer_)\n>  {\n> @@ -205,12 +193,9 @@ static void finish_active_slot(struct\n> active_request_slot *slot)\n>\n>  static void xmulti_remove_handle(struct active_request_slot *slot)\n>  {\n> -#ifdef USE_CURL_MULTI\n>  \tcurl_multi_remove_handle(curlm, slot->curl);\n> -#endif\n>  }\n>\n> -#ifdef USE_CURL_MULTI\n>  static void process_curl_messages(void)\n>  {\n>  \tint num_messages;\n> @@ -238,7 +223,6 @@ static void process_curl_messages(void)\n>  \t\tcurl_message = curl_multi_info_read(curlm, &num_messages);\n>  \t}\n>  }\n> -#endif\n>\n>  static int http_options(const char *var, const char *value, void *cb)\n>  {\n> @@ -268,18 +252,14 @@ static int http_options(const char *var, const char\n> *value, void *cb)\n>  \t}\n>  \tif (!strcmp(\"http.minsessions\", var)) {\n>  \t\tmin_curl_sessions = git_config_int(var, value);\n> -#ifndef USE_CURL_MULTI\n>  \t\tif (min_curl_sessions > 1)\n>  \t\t\tmin_curl_sessions = 1;\n> -#endif\n>  \t\treturn 0;\n>  \t}\n> -#ifdef USE_CURL_MULTI\n>  \tif (!strcmp(\"http.maxrequests\", var)) {\n>  \t\tmax_requests = git_config_int(var, value);\n>  \t\treturn 0;\n>  \t}\n> -#endif\n>  \tif (!strcmp(\"http.lowspeedlimit\", var)) {\n>  \t\tcurl_low_speed_limit = (long)git_config_int(var, value);\n>  \t\treturn 0;\n> @@ -494,7 +474,7 @@ static void set_curl_keepalive(CURL *c)\n>  \tcurl_easy_setopt(c, CURLOPT_TCP_KEEPALIVE, 1);\n>  }\n>\n> -#elif LIBCURL_VERSION_NUM >= 0x071000\n> +#else\n>  static int sockopt_callback(void *client, curl_socket_t fd, curlsocktype\n> type)\n>  {\n>  \tint ka = 1;\n> @@ -516,13 +496,6 @@ static void set_curl_keepalive(CURL *c)\n>  \tcurl_easy_setopt(c, CURLOPT_SOCKOPTFUNCTION, sockopt_callback);\n>  }\n>\n> -#else\n> -static void set_curl_keepalive(CURL *c)\n> -{\n> -\t/* not supported on older curl versions */\n> -}\n> -#endif\n> -\n>  static void redact_sensitive_header(struct strbuf *header)\n>  {\n>  \tconst char *sensitive_header;\n> @@ -876,7 +849,6 @@ void http_init(struct remote *remote, const char *url,\n> int proactive_auth)\n>  \tno_pragma_header = curl_slist_append(http_copy_default_headers(),\n>  \t\t\"Pragma:\");\n>\n> -#ifdef USE_CURL_MULTI\n>  \t{\n>  \t\tchar *http_max_requests = getenv(\"GIT_HTTP_MAX_REQUESTS\");\n>  \t\tif (http_max_requests != NULL)\n> @@ -886,7 +858,6 @@ void http_init(struct remote *remote, const char *url,\n> int proactive_auth)\n>  \tcurlm = curl_multi_init();\n>  \tif (!curlm)\n>  \t\tdie(\"curl_multi_init failed\");\n> -#endif\n>\n>  \tif (getenv(\"GIT_SSL_NO_VERIFY\"))\n>  \t\tcurl_ssl_verify = 0;\n> @@ -909,10 +880,8 @@ void http_init(struct remote *remote, const char\n> *url, int proactive_auth)\n>  \t\tcurl_ssl_verify = 1;\n>\n>  \tcurl_session_count = 0;\n> -#ifdef USE_CURL_MULTI\n>  \tif (max_requests < 1)\n>  \t\tmax_requests = DEFAULT_MAX_REQUESTS;\n> -#endif\n>\n>  \tif (getenv(\"GIT_CURL_FTP_NO_EPSV\"))\n>  \t\tcurl_ftp_no_epsv = 1;\n> @@ -949,9 +918,7 @@ void http_cleanup(void)\n>  \tcurl_easy_cleanup(curl_default);\n>  #endif\n>\n> -#ifdef USE_CURL_MULTI\n>  \tcurl_multi_cleanup(curlm);\n> -#endif\n>  \tcurl_global_cleanup();\n>\n>  \tcurl_slist_free_all(extra_http_headers);\n> @@ -996,7 +963,6 @@ struct active_request_slot *get_active_slot(void)\n>  \tstruct active_request_slot *slot = active_queue_head;\n>  \tstruct active_request_slot *newslot;\n>\n> -#ifdef USE_CURL_MULTI\n>  \tint num_transfers;\n>\n>  \t/* Wait for a slot to open up if the queue is full */\n> @@ -1005,7 +971,6 @@ struct active_request_slot *get_active_slot(void)\n>  \t\tif (num_transfers < active_requests)\n>  \t\t\tprocess_curl_messages();\n>  \t}\n> -#endif\n>\n>  \twhile (slot != NULL && slot->in_use)\n>  \t\tslot = slot->next;\n> @@ -1076,7 +1041,6 @@ struct active_request_slot *get_active_slot(void)\n>\n>  int start_active_slot(struct active_request_slot *slot)\n>  {\n> -#ifdef USE_CURL_MULTI\n>  \tCURLMcode curlm_result = curl_multi_add_handle(curlm, slot->curl);\n>  \tint num_transfers;\n>\n> @@ -1094,11 +1058,9 @@ int start_active_slot(struct active_request_slot\n> *slot)\n>  \t * something.\n>  \t */\n>  \tcurl_multi_perform(curlm, &num_transfers);\n> -#endif\n>  \treturn 1;\n>  }\n>\n> -#ifdef USE_CURL_MULTI\n>  struct fill_chain {\n>  \tvoid *data;\n>  \tint (*fill)(void *);\n> @@ -1157,11 +1119,9 @@ void step_active_slots(void)\n>  \t\tfill_active_slots();\n>  \t}\n>  }\n> -#endif\n>\n>  void run_active_slot(struct active_request_slot *slot)\n>  {\n> -#ifdef USE_CURL_MULTI\n>  \tfd_set readfds;\n>  \tfd_set writefds;\n>  \tfd_set excfds;\n> @@ -1174,7 +1134,6 @@ void run_active_slot(struct active_request_slot\n> *slot)\n>  \t\tstep_active_slots();\n>\n>  \t\tif (slot->in_use) {\n> -#if LIBCURL_VERSION_NUM >= 0x070f04\n>  \t\t\tlong curl_timeout;\n>  \t\t\tcurl_multi_timeout(curlm, &curl_timeout);\n>  \t\t\tif (curl_timeout == 0) {\n> @@ -1186,10 +1145,6 @@ void run_active_slot(struct active_request_slot\n> *slot)\n>  \t\t\t\tselect_timeout.tv_sec  =  curl_timeout / 1000;\n>  \t\t\t\tselect_timeout.tv_usec = (curl_timeout % 1000) * 1000;\n>  \t\t\t}\n> -#else\n> -\t\t\tselect_timeout.tv_sec  = 0;\n> -\t\t\tselect_timeout.tv_usec = 50000;\n> -#endif\n>\n>  \t\t\tmax_fd = -1;\n>  \t\t\tFD_ZERO(&readfds);\n> @@ -1212,12 +1167,6 @@ void run_active_slot(struct active_request_slot\n> *slot)\n>  \t\t\tselect(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);\n>  \t\t}\n>  \t}\n> -#else\n> -\twhile (slot->in_use) {\n> -\t\tslot->curl_result = curl_easy_perform(slot->curl);\n> -\t\tfinish_active_slot(slot);\n> -\t}\n> -#endif\n>  }\n>\n>  static void release_active_slot(struct active_request_slot *slot)\n> @@ -1231,9 +1180,7 @@ static void release_active_slot(struct\n> active_request_slot *slot)\n>  \t\t\tcurl_session_count--;\n>  \t\t}\n>  \t}\n> -#ifdef USE_CURL_MULTI\n>  \tfill_active_slots();\n> -#endif\n>  }\n>\n>  void finish_all_active_slots(void)\n> @@ -1344,12 +1291,10 @@ static int handle_curl_result(struct slot_results\n> *results)\n>  \t} else {\n>  \t\tif (results->http_connectcode == 407)\n>  \t\t\tcredential_reject(&proxy_auth);\n> -#if LIBCURL_VERSION_NUM >= 0x070c00\n>  \t\tif (!curl_errorstr[0])\n>  \t\t\tstrlcpy(curl_errorstr,\n>  \t\t\t\tcurl_easy_strerror(results->curl_result),\n>  \t\t\t\tsizeof(curl_errorstr));\n> -#endif\n>  \t\treturn HTTP_ERROR;\n>  \t}\n>  }\n> diff --git a/http.h b/http.h\n> index d1de11a3d..4054af685 100644\n> --- a/http.h\n> +++ b/http.h\n> @@ -10,26 +10,12 @@\n>  #include \"remote.h\"\n>  #include \"url.h\"\n>\n> -/*\n> - * We detect based on the cURL version if multi-transfer is\n> - * usable in this implementation and define this symbol accordingly.\n> - * This shouldn't be set by the Makefile or by the user (e.g. via\n> CFLAGS).\n> - */\n> -#undef USE_CURL_MULTI\n> -\n> -#if LIBCURL_VERSION_NUM >= 0x071000\n> -#define USE_CURL_MULTI\n>  #define DEFAULT_MAX_REQUESTS 5\n> -#endif\n>\n>  #if (LIBCURL_VERSION_NUM < 0x070c04) || (LIBCURL_VERSION_NUM == 0x071000)\n>  #define NO_CURL_EASY_DUPHANDLE\n>  #endif\n>\n> -#if LIBCURL_VERSION_NUM < 0x070c03\n> -#define NO_CURL_IOCTL\n> -#endif\n> -\n>  /*\n>   * CURLOPT_USE_SSL was known as CURLOPT_FTP_SSL up to 7.16.4,\n>   * and the constants were known as CURLFTPSSL_*\n> @@ -67,9 +53,7 @@ struct buffer {\n>  extern size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void\n> *strbuf);\n>  extern size_t fwrite_buffer(char *ptr, size_t eltsize, size_t nmemb, void\n> *strbuf);\n>  extern size_t fwrite_null(char *ptr, size_t eltsize, size_t nmemb, void\n> *strbuf);\n> -#ifndef NO_CURL_IOCTL\n>  extern curlioerr ioctl_buffer(CURL *handle, int cmd, void *clientp);\n> -#endif\n>\n>  /* Slot lifecycle functions */\n>  extern struct active_request_slot *get_active_slot(void);\n> @@ -86,11 +70,9 @@ extern void finish_all_active_slots(void);\n>  int run_one_slot(struct active_request_slot *slot,\n>  \t\t struct slot_results *results);\n>\n> -#ifdef USE_CURL_MULTI\n>  extern void fill_active_slots(void);\n>  extern void add_fill_function(void *data, int (*fill)(void *));\n>  extern void step_active_slots(void);\n> -#endif\n>\n>  extern void http_init(struct remote *remote, const char *url,\n>  \t\t      int proactive_auth);\n> diff --git a/remote-curl.c b/remote-curl.c\n> index c792942f0..4997cc193 100644\n> --- a/remote-curl.c\n> +++ b/remote-curl.c\n> @@ -434,7 +434,6 @@ static size_t rpc_out(void *ptr, size_t eltsize,\n>  \treturn avail;\n>  }\n>\n> -#ifndef NO_CURL_IOCTL\n>  static curlioerr rpc_ioctl(CURL *handle, int cmd, void *clientp)\n>  {\n>  \tstruct rpc_state *rpc = clientp;\n> @@ -455,7 +454,6 @@ static curlioerr rpc_ioctl(CURL *handle, int cmd, void\n> *clientp)\n>  \t\treturn CURLIOE_UNKNOWNCMD;\n>  \t}\n>  }\n> -#endif\n>\n>  static size_t rpc_in(char *ptr, size_t eltsize,\n>  \t\tsize_t nmemb, void *buffer_)\n> @@ -595,10 +593,8 @@ static int post_rpc(struct rpc_state *rpc)\n>  \t\trpc->initial_buffer = 1;\n>  \t\tcurl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, rpc_out);\n>  \t\tcurl_easy_setopt(slot->curl, CURLOPT_INFILE, rpc);\n> -#ifndef NO_CURL_IOCTL\n>  \t\tcurl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, rpc_ioctl);\n>  \t\tcurl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, rpc);\n> -#endif\n>  \t\tif (options.verbosity > 1) {\n>  \t\t\tfprintf(stderr, \"POST %s (chunked)\\n\", rpc->service_name);\n>  \t\t\tfflush(stderr);\n>\n\n[1] curl --version\ncurl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.21 Basic ECC\nzlib/1.2.3 libidn/1.18 libssh2/1.4.2\nProtocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp\nFeatures: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz\n\n\n"},{"id":"316137","messageId":"CACBZZX78oKU5HuBEqb9qLy7--wcwhC_mW6x7Q+tB4suxohSCsQ@mail.gmail.com","threadId":"45602","inReplyTo":"20170404025438.bgxz5sfmrawqswcj@sigill.intra.peff.net","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-04T08:17:51Z","receivedAt":"2017-04-04T08:18:20Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Apr 4, 2017 at 4:54 AM, Jeff King <peff@peff.net> wrote:\n> My feeling is that this is old enough to stop caring about. Which means\n> we can drop some of the #ifdefs that clutter the HTTP code (and there's\n> a patch at the end of this mail dropping support for everything older\n> than 7.11.1). But that made wonder: how old is too old? I think it's\n> nice that we don't force people to upgrade to the latest version of\n> curl. But at some point, if you are running a 13-year-old version of\n> libcurl, how likely are you to run a brand new version of Git? :)\n>\n> If we declared 7.16.0 as a cutoff, we could unconditionally define\n> USE_CURL_MULTI, which gets rid of quite a few messy ifdefs.\n\nI don't object to this patch, but just as a general comment, in\nenterprise-y environments using an old OS (e.g. CentOS 5/6) & then\ncompiling some selected packages like git based on OS libraries is\nquite common.\n\nE.g. at work we're running git 2.12.0 compiled against CentOS 6\nlibraries, which has curl 7.20.1, released on\nApr 14 2010. Not so long ago we were still running CentOS 5 which\ncomes with 7.15.5 released in Aug 7 2006 which would break with your\npatch.\n\nWhether we support that is another question, I think it's reasonable\nto say that if you're compiling git on such an old system you also\nneed to compile a libcurl instead of using the OS version. I just\nwanted to point out that this *does* happen, someone is going to be\ncompiling new git releases on CentOS 5 & will be hit by this.\n"},{"id":"316140","messageId":"20170404083341.uajswm3qdzyvzxsp@sigill.intra.peff.net","threadId":"45602","inReplyTo":"CACBZZX78oKU5HuBEqb9qLy7--wcwhC_mW6x7Q+tB4suxohSCsQ@mail.gmail.com","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-04T08:33:41Z","receivedAt":"2017-04-04T08:40:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 04, 2017 at 10:17:51AM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> On Tue, Apr 4, 2017 at 4:54 AM, Jeff King <peff@peff.net> wrote:\n> > My feeling is that this is old enough to stop caring about. Which means\n> > we can drop some of the #ifdefs that clutter the HTTP code (and there's\n> > a patch at the end of this mail dropping support for everything older\n> > than 7.11.1). But that made wonder: how old is too old? I think it's\n> > nice that we don't force people to upgrade to the latest version of\n> > curl. But at some point, if you are running a 13-year-old version of\n> > libcurl, how likely are you to run a brand new version of Git? :)\n> >\n> > If we declared 7.16.0 as a cutoff, we could unconditionally define\n> > USE_CURL_MULTI, which gets rid of quite a few messy ifdefs.\n> \n> I don't object to this patch, but just as a general comment, in\n> enterprise-y environments using an old OS (e.g. CentOS 5/6) & then\n> compiling some selected packages like git based on OS libraries is\n> quite common.\n> \n> E.g. at work we're running git 2.12.0 compiled against CentOS 6\n> libraries, which has curl 7.20.1, released on\n> Apr 14 2010. Not so long ago we were still running CentOS 5 which\n> comes with 7.15.5 released in Aug 7 2006 which would break with your\n> patch.\n> \n> Whether we support that is another question, I think it's reasonable\n> to say that if you're compiling git on such an old system you also\n> need to compile a libcurl instead of using the OS version. I just\n> wanted to point out that this *does* happen, someone is going to be\n> compiling new git releases on CentOS 5 & will be hit by this.\n\nThanks, that's a very useful bit of data. According to:\n\n  https://access.redhat.com/support/policy/updates/errata\n\nRHEL5 (which as I understand it basically the same as CentOS 5 in terms\nof packages) ended its 10-year support cycle just a few days ago. That\nwould perhaps make 7.20.1 a reasonable cutoff.\n\nI dunno. We could also just punt on the whole thing. It was nice to see\na bunch of #ifdefs go away, but the code they're protecting is actually\nnot that complicated. Most of them do not have an #else at all, and we\njust silently skip features on old versions.\n\nI think it might be nice to declare a \"too old\" version, though, just so\nwe can stop adding _new_ ifdefs. Maybe 7.11.1 is that version now, and\nin another few years we can bump to 7.16.0. :)\n\n-Peff\n"},{"id":"316151","messageId":"CACBZZX5D2cYf0-ob_Da0EsxRtZHfegezPtCGA10-sjfi0A+AoQ@mail.gmail.com","threadId":"45602","inReplyTo":"20170404083341.uajswm3qdzyvzxsp@sigill.intra.peff.net","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-04T10:44:47Z","receivedAt":"2017-04-04T10:45:20Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Apr 4, 2017 at 10:33 AM, Jeff King <peff@peff.net> wrote:\n> On Tue, Apr 04, 2017 at 10:17:51AM +0200, Ævar Arnfjörð Bjarmason wrote:\n>\n>> On Tue, Apr 4, 2017 at 4:54 AM, Jeff King <peff@peff.net> wrote:\n>> > My feeling is that this is old enough to stop caring about. Which means\n>> > we can drop some of the #ifdefs that clutter the HTTP code (and there's\n>> > a patch at the end of this mail dropping support for everything older\n>> > than 7.11.1). But that made wonder: how old is too old? I think it's\n>> > nice that we don't force people to upgrade to the latest version of\n>> > curl. But at some point, if you are running a 13-year-old version of\n>> > libcurl, how likely are you to run a brand new version of Git? :)\n>> >\n>> > If we declared 7.16.0 as a cutoff, we could unconditionally define\n>> > USE_CURL_MULTI, which gets rid of quite a few messy ifdefs.\n>>\n>> I don't object to this patch, but just as a general comment, in\n>> enterprise-y environments using an old OS (e.g. CentOS 5/6) & then\n>> compiling some selected packages like git based on OS libraries is\n>> quite common.\n>>\n>> E.g. at work we're running git 2.12.0 compiled against CentOS 6\n>> libraries, which has curl 7.20.1, released on\n>> Apr 14 2010. Not so long ago we were still running CentOS 5 which\n>> comes with 7.15.5 released in Aug 7 2006 which would break with your\n>> patch.\n>>\n>> Whether we support that is another question, I think it's reasonable\n>> to say that if you're compiling git on such an old system you also\n>> need to compile a libcurl instead of using the OS version. I just\n>> wanted to point out that this *does* happen, someone is going to be\n>> compiling new git releases on CentOS 5 & will be hit by this.\n>\n> Thanks, that's a very useful bit of data. According to:\n>\n>   https://access.redhat.com/support/policy/updates/errata\n>\n> RHEL5 (which as I understand it basically the same as CentOS 5 in terms\n> of packages).\n\nYeah CentOS is just s/RHEL/CentOS/g across the RHEL-provided source\npackages. It's a way to use RHEL without paying for (or getting) RHEL\nsupport.\n\n> ended its 10-year support cycle just a few days ago. That\n> would perhaps make 7.20.1 a reasonable cutoff.\n\nFWIW these cut-offs don't have a lot to do with how long some\ninstallations run things like RHEL5 or CO5 actually run. RHEL5's EOP3\nphase ended days ago, but the End of Extended Life-cycle Support goes\nuntil late 2020, and for anyone running the CentOS flavors these dates\nmatter very little, since they're about how long RedHat is supporting\nit, and if you don't have RedHat support in the first place...\n\n> I dunno. We could also just punt on the whole thing. It was nice to see\n> a bunch of #ifdefs go away, but the code they're protecting is actually\n> not that complicated. Most of them do not have an #else at all, and we\n> just silently skip features on old versions.\n>\n> I think it might be nice to declare a \"too old\" version, though, just so\n> we can stop adding _new_ ifdefs. Maybe 7.11.1 is that version now, and\n> in another few years we can bump to 7.16.0. :)\n\nI think it's completely fine to include your patch as-is. At some\npoint we need to pass the burden of dealing with these old software\nversions, saying that you should use a <10 year old library isn't\nunreasonable. Anyone packaging new git on RHEL5 or derivatives can\njust package a newer libcurl as well.\n"},{"id":"316153","messageId":"alpine.DEB.2.20.1704041351350.4268@virtualbox","threadId":"45602","inReplyTo":"CACBZZX5D2cYf0-ob_Da0EsxRtZHfegezPtCGA10-sjfi0A+AoQ@mail.gmail.com","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-04-04T11:54:08Z","receivedAt":"2017-04-04T11:54:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 4 Apr 2017, Ævar Arnfjörð Bjarmason wrote:\n\n> I think it's completely fine to include your patch as-is. At some\n> point we need to pass the burden of dealing with these old software\n> versions, saying that you should use a <10 year old library isn't\n> unreasonable. Anyone packaging new git on RHEL5 or derivatives can\n> just package a newer libcurl as well.\n\nBut how much maintenance burden is it, really? Is the continued use of\nthose #ifdef's really worth this much discussion, let alone applying a\npatch that may break users who have so far been happy?\n\nIt would be a different thing if we had to have hacks to support old cURL\nversions, where we need to ship entire >10kB source files that tap into\ninternal data structures that may, or may not have changed. Such a hack, I\nwould be happy to discuss when we could possibly remove it.\n\nBut a couple of #ifdef's? C'mon, man, we can carry this *without sweat*\nindefinitely ;-)\n\nCiao,\nDscho"},{"id":"316155","messageId":"20170404133241.GA15588@gevaerts.be","threadId":"45602","inReplyTo":"20170404025438.bgxz5sfmrawqswcj@sigill.intra.peff.net","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Frank Gevaerts","fromEmail":"frank@gevaerts.be","sentAt":"2017-04-04T13:32:41Z","receivedAt":"2017-04-04T13:32:48Z","isPatch":false,"sender":{"key":"frank@gevaerts.be","avatar":null},"body":"On Mon, Apr 03, 2017 at 10:54:38PM -0400, Jeff King wrote:\n> A nearby thread raised the question of whether we can rely on a version\n> of libcurl that contains a particular feature. The version in question\n> is curl 7.11.1, which came out in March 2004.\n\nI had a quick look at the 7.11.1 support, and I found that current git\nactually doesn't build with anything older than curl 7.19.4. The issue\nis aeae4db174, which moved some stuff to a helper function but didn't\ncopy the corresponding #ifdefs.\n\nWith that issue fixed, I could build with versions back to 7.12.2, which\nis the oldest curl version I could get to build on my modern system.\nNote that while I could build with those versions, I didn't actually\ncheck if the result worked.\n\nI'd say it's going to be increasingly likely with time that similar\nissues will crop up for such old versions of dependencies.\n\nFrank\n\ndiff --git a/http.c b/http.c\nindex 96d84bbed..8c782a086 100644\n--- a/http.c\n+++ b/http.c\n@@ -674,6 +674,7 @@ void setup_curl_trace(CURL *handle)\n        curl_easy_setopt(handle, CURLOPT_DEBUGDATA, NULL);\n }\n \n+#if LIBCURL_VERSION_NUM >= 0x071304\n static long get_curl_allowed_protocols(int from_user)\n {\n        long allowed_protocols = 0;\n@@ -689,6 +690,7 @@ static long get_curl_allowed_protocols(int from_user)\n \n        return allowed_protocols;\n }\n+#endif\n \n static CURL *get_curl_handle(void)\n {\n\n-- \n\"Debugging is twice as hard as writing the code in the first place.\nTherefore, if you write the code as cleverly as possible, you are,\nby definition, not smart enough to debug it.\" - Brian W. Kernighan\n"},{"id":"316156","messageId":"CACBZZX6W+fbCg7xXKuM=iqnSYFENBYxYT1WJmoOvYYCBEkX=hQ@mail.gmail.com","threadId":"45602","inReplyTo":"alpine.DEB.2.20.1704041351350.4268@virtualbox","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-04T14:06:46Z","receivedAt":"2017-04-04T14:07:12Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Apr 4, 2017 at 1:54 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Tue, 4 Apr 2017, Ævar Arnfjörð Bjarmason wrote:\n>\n>> I think it's completely fine to include your patch as-is. At some\n>> point we need to pass the burden of dealing with these old software\n>> versions, saying that you should use a <10 year old library isn't\n>> unreasonable. Anyone packaging new git on RHEL5 or derivatives can\n>> just package a newer libcurl as well.\n>\n> But how much maintenance burden is it, really? Is the continued use of\n> those #ifdef's really worth this much discussion, let alone applying a\n> patch that may break users who have so far been happy?\n>\n> It would be a different thing if we had to have hacks to support old cURL\n> versions, where we need to ship entire >10kB source files that tap into\n> internal data structures that may, or may not have changed. Such a hack, I\n> would be happy to discuss when we could possibly remove it.\n>\n> But a couple of #ifdef's? C'mon, man, we can carry this *without sweat*\n> indefinitely ;-)\n\nI don't really care about applying this patch, but I wouldn't mind\nseeing it applied.\n\nI just wanted to clarify the counteractive point that it's not unusual\nfor some (particularly corporate) environments to be compiling fresh\nupstream releases of some software against really ancient versions of\nother upstream libraries.\n\nBut as Frank Gevaerts's reply (thanks!) which came after your reply\npoints out, this code has already been broken since v2.12.0, so it's\nrarely used enough that nobody's reported being unable to compile git\n2.12.0 on e.g. CentOS 5 >2 months since release.\n\nI think this is a stronger argument for removing stuff like this. At\nsome point we're shipping code nobody's tested in combination with the\nrest of our code. This can easily becomes a source of bugs as someone\ne.g. compiling a new git on co5 becomes literally the first person to\never test some new combination of codepaths we've added around mostly\nunused ifdefs.\n"},{"id":"316162","messageId":"20170404165321.GC189807@google.com","threadId":"45602","inReplyTo":"CACBZZX6W+fbCg7xXKuM=iqnSYFENBYxYT1WJmoOvYYCBEkX=hQ@mail.gmail.com","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-04-04T16:53:21Z","receivedAt":"2017-04-04T16:53:30Z","isPatch":false,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 04/04, Ævar Arnfjörð Bjarmason wrote:\n> On Tue, Apr 4, 2017 at 1:54 PM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> > Hi,\n> >\n> > On Tue, 4 Apr 2017, Ævar Arnfjörð Bjarmason wrote:\n> >\n> >> I think it's completely fine to include your patch as-is. At some\n> >> point we need to pass the burden of dealing with these old software\n> >> versions, saying that you should use a <10 year old library isn't\n> >> unreasonable. Anyone packaging new git on RHEL5 or derivatives can\n> >> just package a newer libcurl as well.\n> >\n> > But how much maintenance burden is it, really? Is the continued use of\n> > those #ifdef's really worth this much discussion, let alone applying a\n> > patch that may break users who have so far been happy?\n> >\n> > It would be a different thing if we had to have hacks to support old cURL\n> > versions, where we need to ship entire >10kB source files that tap into\n> > internal data structures that may, or may not have changed. Such a hack, I\n> > would be happy to discuss when we could possibly remove it.\n> >\n> > But a couple of #ifdef's? C'mon, man, we can carry this *without sweat*\n> > indefinitely ;-)\n> \n> I don't really care about applying this patch, but I wouldn't mind\n> seeing it applied.\n> \n> I just wanted to clarify the counteractive point that it's not unusual\n> for some (particularly corporate) environments to be compiling fresh\n> upstream releases of some software against really ancient versions of\n> other upstream libraries.\n> \n> But as Frank Gevaerts's reply (thanks!) which came after your reply\n> points out, this code has already been broken since v2.12.0, so it's\n> rarely used enough that nobody's reported being unable to compile git\n> 2.12.0 on e.g. CentOS 5 >2 months since release.\n> \n> I think this is a stronger argument for removing stuff like this. At\n> some point we're shipping code nobody's tested in combination with the\n> rest of our code. This can easily becomes a source of bugs as someone\n> e.g. compiling a new git on co5 becomes literally the first person to\n> ever test some new combination of codepaths we've added around mostly\n> unused ifdefs.\n\nI'm all for seeing a patch like this applied.  I agree that we can't\nexpect the world to be running the most up-to-date version of curl but\nwe should be able to select some \"oldest\" version we will support which\ncan be bumped up every couple of years.  \n\nI mean, ensuring that you are running with an up-to-date version of curl\nis really important when it comes to all of the security fixes that have\nbeen made in each revision.\n\n-- \nBrandon Williams\n"},{"id":"316165","messageId":"20170404201601.jhjq2x5qgcneroo4@sigill.intra.peff.net","threadId":"45602","inReplyTo":"CACBZZX6W+fbCg7xXKuM=iqnSYFENBYxYT1WJmoOvYYCBEkX=hQ@mail.gmail.com","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-04T20:16:01Z","receivedAt":"2017-04-04T20:16:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 04, 2017 at 04:06:46PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> > But a couple of #ifdef's? C'mon, man, we can carry this *without sweat*\n> > indefinitely ;-)\n> \n> I don't really care about applying this patch, but I wouldn't mind\n> seeing it applied.\n> \n> I just wanted to clarify the counteractive point that it's not unusual\n> for some (particularly corporate) environments to be compiling fresh\n> upstream releases of some software against really ancient versions of\n> other upstream libraries.\n> \n> But as Frank Gevaerts's reply (thanks!) which came after your reply\n> points out, this code has already been broken since v2.12.0, so it's\n> rarely used enough that nobody's reported being unable to compile git\n> 2.12.0 on e.g. CentOS 5 >2 months since release.\n\nYeah, this is exactly the kind of thing I was wondering about (but was\ntoo lazy to actually build an ancient version of curl -- thank you,\nFrank).\n\nIn this case it was a compile error, which was obvious. I'm much more\nworried about subtle interactions, or the fact that some of the ifdefs\nare around security features that get ignored. In some cases we at least\nissue a warning, but not always. E.g., we silently ignore\nhttp.sslcapath.  Depending what you're using it for that could fail\nclosed (if you were trying to add a CA) or open (if you were trying to\nrestrict to a specific CA).\n\n-Peff\n"},{"id":"316175","messageId":"alpine.DEB.2.20.1704050043370.4268@virtualbox","threadId":"45602","inReplyTo":"20170404165321.GC189807@google.com","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-04-04T22:46:16Z","receivedAt":"2017-04-04T22:46:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Brandon,\n\nOn Tue, 4 Apr 2017, Brandon Williams wrote:\n\n> I'm all for seeing a patch like this applied.  I agree that we can't\n> expect the world to be running the most up-to-date version of curl but\n> we should be able to select some \"oldest\" version we will support which\n> can be bumped up every couple of years.  \n> \n> I mean, ensuring that you are running with an up-to-date version of curl\n> is really important when it comes to all of the security fixes that have\n> been made in each revision.\n\nI am not in the business of dictating to others what software they have to\nrun. I am in the business of maintaining Git for Windows. And part of that\njob is to drag along code that is maybe not the most elegant, but works.\n\nThe patch in question resolves such a wart. Sure, it would be a cleanup.\nIs it a huge maintenance burden to keep those few #ifdef's, though?\nAbsolutely not.\n\nCiao,\nJohannes\n"},{"id":"316176","messageId":"20170404230304.GE189807@google.com","threadId":"45602","inReplyTo":"alpine.DEB.2.20.1704050043370.4268@virtualbox","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-04-04T23:03:04Z","receivedAt":"2017-04-04T23:03:12Z","isPatch":false,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 04/05, Johannes Schindelin wrote:\n> Hi Brandon,\n> \n> On Tue, 4 Apr 2017, Brandon Williams wrote:\n> \n> > I'm all for seeing a patch like this applied.  I agree that we can't\n> > expect the world to be running the most up-to-date version of curl but\n> > we should be able to select some \"oldest\" version we will support which\n> > can be bumped up every couple of years.  \n> > \n> > I mean, ensuring that you are running with an up-to-date version of curl\n> > is really important when it comes to all of the security fixes that have\n> > been made in each revision.\n> \n> I am not in the business of dictating to others what software they have to\n> run. I am in the business of maintaining Git for Windows. And part of that\n> job is to drag along code that is maybe not the most elegant, but works.\n> \n> The patch in question resolves such a wart. Sure, it would be a cleanup.\n> Is it a huge maintenance burden to keep those few #ifdef's, though?\n> Absolutely not.\n\nhaha, very true.  Of course I'm stating my opinion based on my limited\nexperience and work environment.\n\n-- \nBrandon Williams\n"},{"id":"316177","messageId":"CAGZ79kb5VeKCzzafw+nEcRda2apuit-K=qZxxZ3Li96MiMdOXA@mail.gmail.com","threadId":"45602","inReplyTo":"alpine.DEB.2.20.1704050043370.4268@virtualbox","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-04-04T23:03:19Z","receivedAt":"2017-04-04T23:03:27Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Apr 4, 2017 at 3:46 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi Brandon,\n>\n> On Tue, 4 Apr 2017, Brandon Williams wrote:\n>\n>> I'm all for seeing a patch like this applied.  I agree that we can't\n>> expect the world to be running the most up-to-date version of curl but\n>> we should be able to select some \"oldest\" version we will support which\n>> can be bumped up every couple of years.\n>>\n>> I mean, ensuring that you are running with an up-to-date version of curl\n>> is really important when it comes to all of the security fixes that have\n>> been made in each revision.\n>\n> I am not in the business of dictating to others what software they have to\n> run. I am in the business of maintaining Git for Windows. And part of that\n> job is to drag along code that is maybe not the most elegant, but works.\n>\n> The patch in question resolves such a wart. Sure, it would be a cleanup.\n> Is it a huge maintenance burden to keep those few #ifdef's, though?\n> Absolutely not.\n\nKeeping them around is the easy part, the hard part is promising to users\nthat the software you maintain is as good as your reputation, when e.g.\nwe find out that certain #ifdefs don't even compile.\n(See Frank Gevaerts answer)\n\nSo from my point of view it ought to be easier to maintain software that\nis fully compiled and tested by a lot of people, and not have a long tail\nof niche features that are not well tested.\n\nInitially I thought I had a similar stance as you (\"A well written line of code\nis cheap\") but I kept quiet, as I do not have a lot of experience with dealing\n\"old\" Software.\n\nMaybe the git community would want to take a look at the kernel community\n(or other similar communities), how they solve the \"long term stable\" problem\nof computer science.\n\nAnd there are different things to be considered:\n(1) the kernel community has \"stable\" maintainer(s) that are not the same\nas the maintainer of the bleeding edge branch. So I would expect that these\nmaintainers have expertise in \"dealing with old stuff, particular from\n$DATE_RANGE\".\n(2) one of the kernels rules is \"don't break user space\". However sometimes\nthey do remove code[1]. And then their policy seemed to be: Wait until someone\nshows up and we can revert the removal.\n\n[1] http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html\n\nSo I would propose to take this patch, but be prepared to revert it in case\nsome user yells.\n\nThanks,\nStefan\n"},{"id":"316179","messageId":"alpine.DEB.2.20.1704051031200.4268@virtualbox","threadId":"45602","inReplyTo":"CAGZ79kb5VeKCzzafw+nEcRda2apuit-K=qZxxZ3Li96MiMdOXA@mail.gmail.com","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-04-05T08:49:47Z","receivedAt":"2017-04-05T08:51:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Stefan,\n\nOn Tue, 4 Apr 2017, Stefan Beller wrote:\n\n> On Tue, Apr 4, 2017 at 3:46 PM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> >\n> > On Tue, 4 Apr 2017, Brandon Williams wrote:\n> >\n> >> I'm all for seeing a patch like this applied.  I agree that we can't\n> >> expect the world to be running the most up-to-date version of curl\n> >> but we should be able to select some \"oldest\" version we will support\n> >> which can be bumped up every couple of years.\n> >>\n> >> I mean, ensuring that you are running with an up-to-date version of\n> >> curl is really important when it comes to all of the security fixes\n> >> that have been made in each revision.\n> >\n> > I am not in the business of dictating to others what software they\n> > have to run. I am in the business of maintaining Git for Windows. And\n> > part of that job is to drag along code that is maybe not the most\n> > elegant, but works.\n> >\n> > The patch in question resolves such a wart. Sure, it would be a\n> > cleanup.  Is it a huge maintenance burden to keep those few #ifdef's,\n> > though?  Absolutely not.\n> \n> Keeping them around is the easy part, the hard part is promising to\n> users that the software you maintain is as good as your reputation, when\n> e.g.  we find out that certain #ifdefs don't even compile.  (See Frank\n> Gevaerts answer)\n\nFrom that point of view, we should drop support for platforms as soon as\nwe have a bug in our code that lets the build fail: there is little\ndifference between the #ifdef's that let Git build with older dependencies\nand #ifdef's that let Git build on platforms other than Linux.\n\nBy that reasoning, we would have dropped FreeBSD support a gazillion\ntimes. Or for that matter, Windows support.\n\nI obviously disagree with this stance.\n\n> Initially I thought I had a similar stance as you (\"A well written line\n> of code is cheap\") but I kept quiet, as I do not have a lot of\n> experience with dealing \"old\" Software.\n\nI am speaking from my point of view, of course, maintaining Git for\nWindows. Of course I would love to drop support for old MSys. But that's\nnot going to happen because at least one active contributor has a vested\ninterest in keeping it going.\n\nBut even then, it sometimes takes a while until any breakages get fixed.\nPrematurely removing a build option \"because it has been broken for a\ncouple of major versions\" would make it infinitely harder for (often\noverworked) contributors to fix the breakage.\n\nAnyway, this whole discussion took way more effort from my side than to\nmaintain a couple of slightly stale #ifdef's. From\nhttps://xkcd.com/1205/'s point of view, I should have ignored the\n\"let's rip out stuff just because we can\" patch.\n\nI just thought that we care a bit more about contributors' experience.\n\n> Maybe the git community would want to take a look at the kernel\n> community (or other similar communities), how they solve the \"long term\n> stable\" problem of computer science.\n\nIf we want to follow the example of a inclusive community that values\ncontributors' time and effort, maybe we should look elsewhere?\n\nI vividly remember hearing Greg KH's statement at Git Merge 2016 \"we\ndeliberately waste contributors' time\". Very vividly. Very, very vividly.\n\n> So I would propose to take this patch, but be prepared to revert it in case\n> some user yells.\n\nIt would be much nicer to contributors (who are likely not subscribed to\nthe Git mailing list, or at least do not read all the mails coming in on\nthat channel) if they could simply imitate the surrounding #ifdef's and\nmake that tiny patch that adds a guard around an unused static function.\n\nIf you require them to revert a patch first that reinstates an almost\nworking state with an old dependency, you expect them to know that there\nwas such a patch in the first place, and to dig it up.\n\nLet's reiterate that we are talking about some #ifdef's here that are a\ntiny maintenance burden. That may have a bug here and there, easily fixed.\n\nAgain, I am sure that we can provide a much better contributors'\nexperience.\n\nAlso, maybe, just maybe, there are more pressing issues than removing a\ncouple lines here and there? This discussion vaguely reminds me of the\nopening statement of https://en.wikipedia.org/wiki/Law_of_triviality...\nJust saying'...\n\nCiao,\nDscho\n"},{"id":"316183","messageId":"20170405092931.3n7m5lawxiyy4qae@sigill.intra.peff.net","threadId":"45602","inReplyTo":"alpine.DEB.2.20.1704051031200.4268@virtualbox","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-05T09:29:31Z","receivedAt":"2017-04-05T09:31:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 05, 2017 at 10:49:47AM +0200, Johannes Schindelin wrote:\n\n> Let's reiterate that we are talking about some #ifdef's here that are a\n> tiny maintenance burden. That may have a bug here and there, easily fixed.\n\nForget the maintenance cost for a moment. My concern is that we are\ndoing users a disservice by shipping broken and untested code without\nthem (or us) realizing it. The compile failure is the _best_ case,\nbecause they know there's a bug to be fixed. A build that quietly fails\nto enforce security properties is actively dangerous, and the user would\npotentially be better off with an #error.\n\n> Also, maybe, just maybe, there are more pressing issues than removing a\n> couple lines here and there? This discussion vaguely reminds me of the\n> opening statement of https://en.wikipedia.org/wiki/Law_of_triviality...\n> Just saying'...\n\nIt's not just removing a couple of lines. It's remembering to check and\n#ifdef new lines that get added, too (this conversation started because\nof review on another patch which failed to do so). Is our attitude \"add\nit and when somebody with an ancient curl complains and provides a\npatch, we'll #ifdef it\"?\n\n-Peff\n"},{"id":"316184","messageId":"d6ba17f0-3da9-8699-8d5c-5ebf1eaef00e@jupiterrise.com","threadId":"45602","inReplyTo":"20170404025438.bgxz5sfmrawqswcj@sigill.intra.peff.net","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Tom G. Christensen","fromEmail":"tgc@jupiterrise.com","sentAt":"2017-04-05T09:33:37Z","receivedAt":"2017-04-05T09:36:40Z","isPatch":false,"sender":{"key":"tgc@jupiterrise.com","avatar":"https://avatars.githubusercontent.com/u/912180?v=4"},"body":"On 04/04/17 04:54, Jeff King wrote:\n> A nearby thread raised the question of whether we can rely on a version\n> of libcurl that contains a particular feature. The version in question\n> is curl 7.11.1, which came out in March 2004.\n>\n> My feeling is that this is old enough to stop caring about. Which means\n> we can drop some of the #ifdefs that clutter the HTTP code (and there's\n> a patch at the end of this mail dropping support for everything older\n> than 7.11.1). But that made wonder: how old is too old? I think it's\n> nice that we don't force people to upgrade to the latest version of\n> curl. But at some point, if you are running a 13-year-old version of\n> libcurl, how likely are you to run a brand new version of Git? :)\n>\n\nFWIW I maintain freely available updated git packages for RHEL 3, 4, 5, \n6 and 7.\n\nThey can be found here:\nhttps://jupiterrise.com/blog/jrpms/\n\nAnd direct access here:\nhttps://jupiterrise.com/jrpms/ (for el3,el4,el5)\nhttps://jupiterrise.com/jrpmsplus/ (for el6, el7)\n\nThey are built against system versions of curl though a few patches are \nrequired for 7.10.6 (el3) and 7.12.1 (el4) support.\nPatches can be found in the src.rpm, though I can also post them here as \npatch series, they cover more than just curl.\n\nI don't use the el3 and el4 versions much any more and el5 use will also \ndrop of now as I'm busy converting machines from el5 to el7.\n\n-tgc\n"},{"id":"316188","messageId":"CACBZZX450tRRsy-Sj8igZthYov7UxFMRJ51M-b1cgYBLo782jQ@mail.gmail.com","threadId":"45602","inReplyTo":"d6ba17f0-3da9-8699-8d5c-5ebf1eaef00e@jupiterrise.com","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-05T10:51:38Z","receivedAt":"2017-04-05T10:55:17Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 5, 2017 at 11:33 AM, Tom G. Christensen <tgc@jupiterrise.com> wrote:\n> On 04/04/17 04:54, Jeff King wrote:\n>>\n>> A nearby thread raised the question of whether we can rely on a version\n>> of libcurl that contains a particular feature. The version in question\n>> is curl 7.11.1, which came out in March 2004.\n>>\n>> My feeling is that this is old enough to stop caring about. Which means\n>> we can drop some of the #ifdefs that clutter the HTTP code (and there's\n>> a patch at the end of this mail dropping support for everything older\n>> than 7.11.1). But that made wonder: how old is too old? I think it's\n>> nice that we don't force people to upgrade to the latest version of\n>> curl. But at some point, if you are running a 13-year-old version of\n>> libcurl, how likely are you to run a brand new version of Git? :)\n>>\n>\n> FWIW I maintain freely available updated git packages for RHEL 3, 4, 5, 6\n> and 7.\n>\n> They can be found here:\n> https://jupiterrise.com/blog/jrpms/\n>\n> And direct access here:\n> https://jupiterrise.com/jrpms/ (for el3,el4,el5)\n> https://jupiterrise.com/jrpmsplus/ (for el6, el7)\n>\n> They are built against system versions of curl though a few patches are\n> required for 7.10.6 (el3) and 7.12.1 (el4) support.\n\nWhoah. So my assumption in\n<CACBZZX78oKU5HuBEqb9qLy7--wcwhC_mW6x7Q+tB4suxohSCsQ@mail.gmail.com>\nthat nobody was compiling this & thus not reporting failures was\nfalse. Rather there's an entire community & distribution mechanism\naround patching git for older EL versions, but the patches aren't\nmaking it upstream.\n\n$ grep -h -e ^Subject -e ^Date *patch\nDate: Tue, 13 Oct 2009 11:34:11 +0200\nSubject: [PATCH 1/7] Make NO_PERL_MAKEMAKER behave more like\nDate: Fri, 13 Jun 2014 11:02:02 +0200\nSubject: [PATCH 2/7] Install man pages when NO_PERL_MAKEMAKER is used\nDate: Mon, 22 Sep 2014 13:42:50 +0200\nSubject: [PATCH 3/7] Allow svnrdump_sim.py to be used with Python 2.2\nDate: Tue, 8 Mar 2016 09:31:56 +0100\nSubject: [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7\nDate: Tue, 23 Aug 2016 10:32:51 +0200\nSubject: [PATCH 5/7] Add support for gnupg < 1.4\nDate: Tue, 23 Aug 2016 18:15:13 +0200\nSubject: [PATCH 6/7] Handle missing CURLINFO_SSL_DATA_{IN,OUT}\nDate: Tue, 23 Aug 2016 18:26:54 +0200\nSubject: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0\nDate: Wed, 2 Feb 2011 21:24:44 -0500\nSubject: [PATCH] Restore vc-git.el for basic compatibility on EL-5\nDate: Mon, 23 Mar 2009 00:03:36 -0400\nSubject: [PATCH] git-cvsimport: Ignore cvsps-2.2b1 Branches: output\n\n> Patches can be found in the src.rpm, though I can also post them here as\n> patch series, they cover more than just curl.\n>\n> I don't use the el3 and el4 versions much any more and el5 use will also\n> drop of now as I'm busy converting machines from el5 to el7.\n\nIt would be great to have them on-list, as far as I can tell they were\nnever submitted? Is there some time/administrative reason for why\nyou're not submitting them? Some of these are many years old, it would\nbe great to have them on-list for wider review & included so vanilla\ngit works on these platforms.\n"},{"id":"316190","messageId":"20170405130424.13803-4-tgc@jupiterrise.com","threadId":"45602","inReplyTo":"20170405130424.13803-1-tgc@jupiterrise.com","subject":"[PATCH 3/7] Allow svnrdump_sim.py to be used with Python 2.2","fromName":"Tom G. Christensen","fromEmail":"tgc@jupiterrise.com","sentAt":"2017-04-05T13:04:20Z","receivedAt":"2017-04-05T13:07:17Z","isPatch":true,"sender":{"key":"tgc@jupiterrise.com","avatar":"https://avatars.githubusercontent.com/u/912180?v=4"},"body":"This allows running the git-svn testsuite with Python 2.2.\n\nSigned-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n---\n contrib/svn-fe/svnrdump_sim.py | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py\nindex 11ac6f692..86bf4a742 100755\n--- a/contrib/svn-fe/svnrdump_sim.py\n+++ b/contrib/svn-fe/svnrdump_sim.py\n@@ -8,9 +8,9 @@ to the highest revision that should be available.\n import sys\n import os\n \n-if sys.hexversion < 0x02040000:\n+if sys.hexversion < 0x02020000:\n     # The limiter is the ValueError() calls. This may be too conservative\n-    sys.stderr.write(\"svnrdump-sim.py: requires Python 2.4 or later.\\n\")\n+    sys.stderr.write(\"svnrdump-sim.py: requires Python 2.2 or later.\\n\")\n     sys.exit(1)\n \n \n-- \n2.12.2\n\n"},{"id":"316191","messageId":"20170405130424.13803-2-tgc@jupiterrise.com","threadId":"45602","inReplyTo":"20170405130424.13803-1-tgc@jupiterrise.com","subject":"[PATCH 1/7] Make NO_PERL_MAKEMAKER behave more like ExtUtils::MakeMaker","fromName":"Tom G. Christensen","fromEmail":"tgc@jupiterrise.com","sentAt":"2017-04-05T13:04:18Z","receivedAt":"2017-04-05T13:07:18Z","isPatch":true,"sender":{"key":"tgc@jupiterrise.com","avatar":"https://avatars.githubusercontent.com/u/912180?v=4"},"body":"This change makes NO_PERL_MAKEMAKER behave more as ExtUtils::MakeMaker\nby installing the modules into the perl libdir and not $(prefix)/lib.\nIt will default to sitelib but will allow the user to choose by setting\nthe INSTALLDIRS variable which is also honored by ExtUtils::MakeMaker.\n\nSigned-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n---\n perl/Makefile | 7 ++++++-\n 1 file changed, 6 insertions(+), 1 deletion(-)\n\ndiff --git a/perl/Makefile b/perl/Makefile\nindex 15d96fcc7..ce53a240c 100644\n--- a/perl/Makefile\n+++ b/perl/Makefile\n@@ -25,7 +25,12 @@ clean:\n $(makfile): PM.stamp\n \n ifdef NO_PERL_MAKEMAKER\n-instdir_SQ = $(subst ','\\'',$(prefix)/lib)\n+perllib = site\n+ifdef INSTALLDIRS\n+perllib = $(INSTALLDIRS)\n+endif\n+perlinstdir := $(shell sh -c \"$(PERL_PATH_SQ) -V:install$(perllib)lib | cut -d\\' -f2\")\n+instdir_SQ = $(subst ','\\'',$(perlinstdir))\n \n modules += Git\n modules += Git/I18N\n-- \n2.12.2\n\n"},{"id":"316192","messageId":"20170405130424.13803-5-tgc@jupiterrise.com","threadId":"45602","inReplyTo":"20170405130424.13803-1-tgc@jupiterrise.com","subject":"[PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7","fromName":"Tom G. Christensen","fromEmail":"tgc@jupiterrise.com","sentAt":"2017-04-05T13:04:21Z","receivedAt":"2017-04-05T13:07:22Z","isPatch":true,"sender":{"key":"tgc@jupiterrise.com","avatar":"https://avatars.githubusercontent.com/u/912180?v=4"},"body":"With curl < 7.10.7 we cannot get the proxy CONNECT response code.\nAs a workaround set it to zero which means no response code available.\n\nSigned-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n---\n http.c | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/http.c b/http.c\nindex 96d84bbed..ce618bdca 100644\n--- a/http.c\n+++ b/http.c\n@@ -214,8 +214,12 @@ static void finish_active_slot(struct active_request_slot *slot)\n \t\tslot->results->auth_avail = 0;\n #endif\n \n+#if LIBCURL_VERSION_NUM >= 0x070a07\n \t\tcurl_easy_getinfo(slot->curl, CURLINFO_HTTP_CONNECTCODE,\n \t\t\t&slot->results->http_connectcode);\n+#else\n+\t\tslot->results->http_connectcode = 0;\n+#endif\n \t}\n \n \t/* Run callback if appropriate */\n-- \n2.12.2\n\n"},{"id":"316193","messageId":"20170405130424.13803-3-tgc@jupiterrise.com","threadId":"45602","inReplyTo":"20170405130424.13803-1-tgc@jupiterrise.com","subject":"[PATCH 2/7] Install man pages when NO_PERL_MAKEMAKER is used","fromName":"Tom G. Christensen","fromEmail":"tgc@jupiterrise.com","sentAt":"2017-04-05T13:04:19Z","receivedAt":"2017-04-05T13:08:03Z","isPatch":true,"sender":{"key":"tgc@jupiterrise.com","avatar":"https://avatars.githubusercontent.com/u/912180?v=4"},"body":"This adds man page installation when using NO_PERL_MAKEMAKER to ensure\nparity with the normal case where ExtUtils::MakeMaker is used.\n\nSigned-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n---\n perl/Makefile | 13 +++++++++++++\n 1 file changed, 13 insertions(+)\n\ndiff --git a/perl/Makefile b/perl/Makefile\nindex ce53a240c..c4b96b058 100644\n--- a/perl/Makefile\n+++ b/perl/Makefile\n@@ -31,6 +31,11 @@ perllib = $(INSTALLDIRS)\n endif\n perlinstdir := $(shell sh -c \"$(PERL_PATH_SQ) -V:install$(perllib)lib | cut -d\\' -f2\")\n instdir_SQ = $(subst ','\\'',$(perlinstdir))\n+ifdef mandir\n+mandir_SQ = $(subst ',''\\'',$(mandir))\n+else\n+mandir_SQ = /usr/share/man\n+endif\n \n modules += Git\n modules += Git/I18N\n@@ -74,9 +79,17 @@ $(makfile): ../GIT-CFLAGS Makefile\n \t\telse \\\n \t\t\tsubdir=/$${i%/*}; \\\n \t\tfi; \\\n+\t\tif test -z $$subdir; \\\n+\t\tthen \\\n+\t\t\tmanpage=$$i; \\\n+\t\telse \\\n+\t\t\tmanpage=$$(echo $$i|sed 's#/#::#g'); \\\n+\t\tfi; \\\n \t\techo '\t$(RM) \"$$(DESTDIR)$(instdir_SQ)/'$$i'.pm\"' >> $@; \\\n \t\techo '\tmkdir -p \"$$(DESTDIR)$(instdir_SQ)'$$subdir'\"' >> $@; \\\n \t\techo '\tcp '$$i'.pm \"$$(DESTDIR)$(instdir_SQ)/'$$i'.pm\"' >> $@; \\\n+\t\techo '\tmkdir -p \"$$(DESTDIR)$(mandir_SQ)/man3\"' >> $@; \\\n+\t\techo '\tpod2man '$$i'.pm \"$$(DESTDIR)$(mandir_SQ)/man3/'$$manpage'.3pm\"' >> $@; \\\n \tdone\n \techo '\t$(RM) \"$$(DESTDIR)$(instdir_SQ)/Error.pm\"' >> $@\n \t'$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \\\n-- \n2.12.2\n\n"},{"id":"316194","messageId":"20170405130424.13803-1-tgc@jupiterrise.com","threadId":"45602","inReplyTo":"CACBZZX450tRRsy-Sj8igZthYov7UxFMRJ51M-b1cgYBLo782jQ@mail.gmail.com","subject":"[PATCH 0/7] Patches to support older RHEL releases","fromName":"Tom G. Christensen","fromEmail":"tgc@jupiterrise.com","sentAt":"2017-04-05T13:04:17Z","receivedAt":"2017-04-05T13:08:06Z","isPatch":true,"sender":{"key":"tgc@jupiterrise.com","avatar":"https://avatars.githubusercontent.com/u/912180?v=4"},"body":"These are patches currently needed to support building and running git\non RHEL/CentOS 3 and 4.\n\nTom G. Christensen (7):\n  Make NO_PERL_MAKEMAKER behave more like ExtUtils::MakeMaker\n  Install man pages when NO_PERL_MAKEMAKER is used\n  Allow svnrdump_sim.py to be used with Python 2.2\n  Handle missing HTTP_CONNECTCODE in curl < 7.10.7\n  Add support for gnupg < 1.4\n  Handle missing CURLINFO_SSL_DATA_{IN,OUT}\n  Do not use curl_easy_strerror with curl < 7.12.0\n\n Makefile                       |  6 ++++++\n contrib/svn-fe/svnrdump_sim.py |  4 ++--\n gpg-interface.c                |  2 ++\n http.c                         | 12 ++++++++++++\n perl/Makefile                  | 20 +++++++++++++++++++-\n 5 files changed, 41 insertions(+), 3 deletions(-)\n\n-- \n2.12.2\n\n"},{"id":"316195","messageId":"20170405130424.13803-6-tgc@jupiterrise.com","threadId":"45602","inReplyTo":"20170405130424.13803-1-tgc@jupiterrise.com","subject":"[PATCH 5/7] Add support for gnupg < 1.4","fromName":"Tom G. Christensen","fromEmail":"tgc@jupiterrise.com","sentAt":"2017-04-05T13:04:22Z","receivedAt":"2017-04-05T13:08:08Z","isPatch":true,"sender":{"key":"tgc@jupiterrise.com","avatar":"https://avatars.githubusercontent.com/u/912180?v=4"},"body":"This adds an OLD_GNUPG define to the Makefile which when activated will\nensure git does not use the --keyid-format argument when calling the\n'gpg' program.\nThis is consistent with how 'gpg' was used in git < 2.10.0 and slightly\ndecreases security.\n\nSigned-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n---\n Makefile        | 6 ++++++\n gpg-interface.c | 2 ++\n 2 files changed, 8 insertions(+)\n\ndiff --git a/Makefile b/Makefile\nindex ca9f16d19..f8f585d21 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -386,6 +386,8 @@ all::\n #\n # to say \"export LESS=FRX (and LV=-c) if the environment variable\n # LESS (and LV) is not set, respectively\".\n+#\n+# Define OLD_GNUPG if you need support for gnupg < 1.4.\n \n GIT-VERSION-FILE: FORCE\n \t@$(SHELL_PATH) ./GIT-VERSION-GEN\n@@ -1529,6 +1531,10 @@ ifndef PAGER_ENV\n PAGER_ENV = LESS=FRX LV=-c\n endif\n \n+ifdef OLD_GNUPG\n+\tBASIC_CFLAGS += -DOLD_GNUPG\n+endif\n+\n QUIET_SUBDIR0  = +$(MAKE) -C # space to separate -C and subdir\n QUIET_SUBDIR1  =\n \ndiff --git a/gpg-interface.c b/gpg-interface.c\nindex e44cc27da..57f1ea792 100644\n--- a/gpg-interface.c\n+++ b/gpg-interface.c\n@@ -224,7 +224,9 @@ int verify_signed_buffer(const char *payload, size_t payload_size,\n \targv_array_pushl(&gpg.args,\n \t\t\t gpg_program,\n \t\t\t \"--status-fd=1\",\n+#ifndef OLD_GNUPG\n \t\t\t \"--keyid-format=long\",\n+#endif\n \t\t\t \"--verify\", temp.filename.buf, \"-\",\n \t\t\t NULL);\n \n-- \n2.12.2\n\n"},{"id":"316196","messageId":"20170405130424.13803-7-tgc@jupiterrise.com","threadId":"45602","inReplyTo":"20170405130424.13803-1-tgc@jupiterrise.com","subject":"[PATCH 6/7] Handle missing CURLINFO_SSL_DATA_{IN,OUT}","fromName":"Tom G. Christensen","fromEmail":"tgc@jupiterrise.com","sentAt":"2017-04-05T13:04:23Z","receivedAt":"2017-04-05T13:08:10Z","isPatch":true,"sender":{"key":"tgc@jupiterrise.com","avatar":"https://avatars.githubusercontent.com/u/912180?v=4"},"body":"Do not try and use CURLINFO_SSL_DATA_{IN,OUT} for curl < 7.12.1.\n\nSigned-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n---\n http.c | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/http.c b/http.c\nindex ce618bdca..a46ab23af 100644\n--- a/http.c\n+++ b/http.c\n@@ -649,10 +649,12 @@ static int curl_trace(CURL *handle, curl_infotype type, char *data, size_t size,\n \t\ttext = \"=> Send data\";\n \t\tcurl_dump_data(text, (unsigned char *)data, size);\n \t\tbreak;\n+#if LIBCURL_VERSION_NUM >= 0x070c01\n \tcase CURLINFO_SSL_DATA_OUT:\n \t\ttext = \"=> Send SSL data\";\n \t\tcurl_dump_data(text, (unsigned char *)data, size);\n \t\tbreak;\n+#endif\n \tcase CURLINFO_HEADER_IN:\n \t\ttext = \"<= Recv header\";\n \t\tcurl_dump_header(text, (unsigned char *)data, size, NO_FILTER);\n@@ -661,10 +663,12 @@ static int curl_trace(CURL *handle, curl_infotype type, char *data, size_t size,\n \t\ttext = \"<= Recv data\";\n \t\tcurl_dump_data(text, (unsigned char *)data, size);\n \t\tbreak;\n+#if LIBCURL_VERSION_NUM >= 0x070c01\n \tcase CURLINFO_SSL_DATA_IN:\n \t\ttext = \"<= Recv SSL data\";\n \t\tcurl_dump_data(text, (unsigned char *)data, size);\n \t\tbreak;\n+#endif\n \t}\n \treturn 0;\n }\n-- \n2.12.2\n\n"},{"id":"316197","messageId":"20170405130424.13803-8-tgc@jupiterrise.com","threadId":"45602","inReplyTo":"20170405130424.13803-1-tgc@jupiterrise.com","subject":"[PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0","fromName":"Tom G. Christensen","fromEmail":"tgc@jupiterrise.com","sentAt":"2017-04-05T13:04:24Z","receivedAt":"2017-04-05T13:08:18Z","isPatch":true,"sender":{"key":"tgc@jupiterrise.com","avatar":"https://avatars.githubusercontent.com/u/912180?v=4"},"body":"Commit 17966c0a added an unguarded use of curl_easy_strerror.\nThis adds a guard so it is not used with curl < 7.12.0.\n\nSigned-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n---\n http.c | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/http.c b/http.c\nindex a46ab23af..104caaa75 100644\n--- a/http.c\n+++ b/http.c\n@@ -2116,8 +2116,12 @@ static size_t fwrite_sha1_file(char *ptr, size_t eltsize, size_t nmemb,\n \t\tCURLcode c = curl_easy_getinfo(slot->curl, CURLINFO_HTTP_CODE,\n \t\t\t\t\t\t&slot->http_code);\n \t\tif (c != CURLE_OK)\n+#if LIBCURL_VERSION_NUM >= 0x070c00\n \t\t\tdie(\"BUG: curl_easy_getinfo for HTTP code failed: %s\",\n \t\t\t\tcurl_easy_strerror(c));\n+#else\n+\t\t\tdie(\"BUG: curl_easy_getinfo for HTTP code failed\");\n+#endif\n \t\tif (slot->http_code >= 300)\n \t\t\treturn size;\n \t}\n-- \n2.12.2\n\n"},{"id":"316198","messageId":"4e30ae33-d508-9bb8-74e6-8204967c4538@jupiterrise.com","threadId":"45602","inReplyTo":"CACBZZX450tRRsy-Sj8igZthYov7UxFMRJ51M-b1cgYBLo782jQ@mail.gmail.com","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Tom G. Christensen","fromEmail":"tgc@jupiterrise.com","sentAt":"2017-04-05T13:04:32Z","receivedAt":"2017-04-05T13:08:30Z","isPatch":false,"sender":{"key":"tgc@jupiterrise.com","avatar":"https://avatars.githubusercontent.com/u/912180?v=4"},"body":"On 05/04/17 12:51, Ævar Arnfjörð Bjarmason wrote:\n> On Wed, Apr 5, 2017 at 11:33 AM, Tom G. Christensen <tgc@jupiterrise.com> wrote:\n> Whoah. So my assumption in\n> <CACBZZX78oKU5HuBEqb9qLy7--wcwhC_mW6x7Q+tB4suxohSCsQ@mail.gmail.com>\n> that nobody was compiling this & thus not reporting failures was\n> false. Rather there's an entire community & distribution mechanism\n> around patching git for older EL versions, but the patches aren't\n> making it upstream.\n>\n\nThe community as I know it consists of me and EPEL5 (now dead and archived).\nThe packages that I build are probably only used by me and the company I \nwork for as they are not exactly easy to find via search engines.\nEPEL5 supported git 1.8.3.2 but the Fedora git specfile still contains \nall the infrastructure though I cannot know if it actually got used with \nanything later than 1.8.3.2.\n\nI don't know of anyone that actually *needs* to use the latest git on \nRHEL < 5, myself included. I kept the support for RHEL < 5 because I \ncould and it was good fun to tinker with.\n\nAlso I should say that testresults are good, no problems there except a \nfew small nits as revealed in the specfile:\n%if %{?el4:1}0\n# These tests fail with subversion 1.1.4\nexport GIT_SKIP_TESTS=\"t9140.4\"\n%ifarch x86_64\n# These tests fail with subversion 1.1.4 but only on x86_64\nexport GIT_SKIP_TESTS=\"$GIT_SKIP_TESTS t9106.7 t9106.8 t9106.9 t9106.10 \nt9137.4 t9164.5 t9164.6 t9164.7 t9164.8\"\n%endif\n%endif\n%if %{?el3:1}%{?el4:1}0\n# not ok 6 - url high-bit escapes\nexport GIT_SKIP_TESTS=\"$GIT_SKIP_TESTS t0110.6\"\n# not ok 32 - ref name 'heads/foo' is invalid\nexport GIT_SKIP_TESTS=\"$GIT_SKIP_TESTS t1402.32\"\n%endif\n%if %{?el3:1}0\n# t7800 failed 17 among 56 test(s)\nexport GIT_SKIP_TESTS=\"$GIT_SKIP_TESTS t7800\"\n%endif\n\nIt's been a little while since I did a build without those exclusions \nbut I doubt much has changed.\n\n> $ grep -h -e ^Subject -e ^Date *patch\n> Date: Tue, 13 Oct 2009 11:34:11 +0200\n> Subject: [PATCH 1/7] Make NO_PERL_MAKEMAKER behave more like\n> Date: Fri, 13 Jun 2014 11:02:02 +0200\n> Subject: [PATCH 2/7] Install man pages when NO_PERL_MAKEMAKER is used\n> Date: Mon, 22 Sep 2014 13:42:50 +0200\n> Subject: [PATCH 3/7] Allow svnrdump_sim.py to be used with Python 2.2\n> Date: Tue, 8 Mar 2016 09:31:56 +0100\n> Subject: [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7\n> Date: Tue, 23 Aug 2016 10:32:51 +0200\n> Subject: [PATCH 5/7] Add support for gnupg < 1.4\n> Date: Tue, 23 Aug 2016 18:15:13 +0200\n> Subject: [PATCH 6/7] Handle missing CURLINFO_SSL_DATA_{IN,OUT}\n> Date: Tue, 23 Aug 2016 18:26:54 +0200\n> Subject: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0\n\nAll original work done by me.\n\n> Date: Wed, 2 Feb 2011 21:24:44 -0500\n> Subject: [PATCH] Restore vc-git.el for basic compatibility on EL-5\n> Date: Mon, 23 Mar 2009 00:03:36 -0400\n> Subject: [PATCH] git-cvsimport: Ignore cvsps-2.2b1 Branches: output\n>\n\nThese two I can't claim credit for. They are lifted verbatim from \nFedora/EPEL and as the headers reveal they were created by Todd Zullinger.\nI won't submit them for inclusion since I am not familiar with nor a \nuser of the parts they touch.\n\n>> Patches can be found in the src.rpm, though I can also post them here as\n>> patch series, they cover more than just curl.\n>>\n>> I don't use the el3 and el4 versions much any more and el5 use will also\n>> drop of now as I'm busy converting machines from el5 to el7.\n>\n> It would be great to have them on-list, as far as I can tell they were\n> never submitted? Is there some time/administrative reason for why\n> you're not submitting them?\n\nWell I recently took the time to clean them up with the intention of \nmaybe finally submitting them but I never got that far.\n\nThe first one in the series I actually submitted many years ago but it \nwas ultimately rejected.\n\nI've submitted a few patches over the years to support older RHEL \nreleases and some of them ended up being included.\n\n> Some of these are many years old, it would\n> be great to have them on-list for wider review & included so vanilla\n> git works on these platforms.\n>\n\nI just posted them now. The series was made against the v2.12.2 tag.\n\n-tgc\n"},{"id":"316200","messageId":"CACBZZX7_tH-Q6PWdj=2BryLnSw-dX__fuR8hvbwXG4sSaM61bg@mail.gmail.com","threadId":"45602","inReplyTo":"20170405130424.13803-4-tgc@jupiterrise.com","subject":"Re: [PATCH 3/7] Allow svnrdump_sim.py to be used with Python 2.2","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-05T13:40:56Z","receivedAt":"2017-04-05T13:41:49Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen <tgc@jupiterrise.com> wrote:\n> This allows running the git-svn testsuite with Python 2.2.\n\n+CC-ing Eric S. Raymond who added these version limitations in a33faf2827.\n\nAlso, in his patch contrib/svn-fe/svnrdump_sim.py,\ngit_remote_helpers/git/__init__.py & git-p4.py is set to >=2.4 or\nlater.\n\nAre you skipping those tests & they don't work under 2.2?\n\n> Signed-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n> ---\n>  contrib/svn-fe/svnrdump_sim.py | 4 ++--\n>  1 file changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py\n> index 11ac6f692..86bf4a742 100755\n> --- a/contrib/svn-fe/svnrdump_sim.py\n> +++ b/contrib/svn-fe/svnrdump_sim.py\n> @@ -8,9 +8,9 @@ to the highest revision that should be available.\n>  import sys\n>  import os\n>\n> -if sys.hexversion < 0x02040000:\n> +if sys.hexversion < 0x02020000:\n>      # The limiter is the ValueError() calls. This may be too conservative\n> -    sys.stderr.write(\"svnrdump-sim.py: requires Python 2.4 or later.\\n\")\n> +    sys.stderr.write(\"svnrdump-sim.py: requires Python 2.2 or later.\\n\")\n>      sys.exit(1)\n>\n>\n> --\n> 2.12.2\n>\n"},{"id":"316201","messageId":"CACBZZX6bYLRSUAy2GUYhBVet3tjzrBQ40L49KxetAvBdgx_x+w@mail.gmail.com","threadId":"45602","inReplyTo":"20170405130424.13803-6-tgc@jupiterrise.com","subject":"Re: [PATCH 5/7] Add support for gnupg < 1.4","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-05T13:45:54Z","receivedAt":"2017-04-05T13:46:29Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen <tgc@jupiterrise.com> wrote:\n> This adds an OLD_GNUPG define to the Makefile which when activated will\n> ensure git does not use the --keyid-format argument when calling the\n> 'gpg' program.\n> This is consistent with how 'gpg' was used in git < 2.10.0 and slightly\n> decreases security.\n\nThis changes the code Linus Torvalds added in b624a3e67f to mitigate\nthe evil32 project generating keys which looked the same for 32 bit\nsignatures.\n\nI think this change makes sense, but the Makefile should have a\nslightly scarier warning, something like:\n\n\"Define OLD_GNUPG if you need support for gnupg <1.4. Note that this\nwill cause git to only show the first 32 bits of PGP keys instead of\n64, and there's a wide variety of brute-forced 32 bit keys in the wild\nthanks to the evil32 project (https://evil32.com). Enabling this will\nmake GPG work old versions, but you might be fooled into accepting\nmalicious keys as a result\".\n\n> Signed-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n> ---\n>  Makefile        | 6 ++++++\n>  gpg-interface.c | 2 ++\n>  2 files changed, 8 insertions(+)\n>\n> diff --git a/Makefile b/Makefile\n> index ca9f16d19..f8f585d21 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -386,6 +386,8 @@ all::\n>  #\n>  # to say \"export LESS=FRX (and LV=-c) if the environment variable\n>  # LESS (and LV) is not set, respectively\".\n> +#\n> +# Define OLD_GNUPG if you need support for gnupg < 1.4.\n>\n>  GIT-VERSION-FILE: FORCE\n>         @$(SHELL_PATH) ./GIT-VERSION-GEN\n> @@ -1529,6 +1531,10 @@ ifndef PAGER_ENV\n>  PAGER_ENV = LESS=FRX LV=-c\n>  endif\n>\n> +ifdef OLD_GNUPG\n> +       BASIC_CFLAGS += -DOLD_GNUPG\n> +endif\n> +\n>  QUIET_SUBDIR0  = +$(MAKE) -C # space to separate -C and subdir\n>  QUIET_SUBDIR1  =\n>\n> diff --git a/gpg-interface.c b/gpg-interface.c\n> index e44cc27da..57f1ea792 100644\n> --- a/gpg-interface.c\n> +++ b/gpg-interface.c\n> @@ -224,7 +224,9 @@ int verify_signed_buffer(const char *payload, size_t payload_size,\n>         argv_array_pushl(&gpg.args,\n>                          gpg_program,\n>                          \"--status-fd=1\",\n> +#ifndef OLD_GNUPG\n>                          \"--keyid-format=long\",\n> +#endif\n>                          \"--verify\", temp.filename.buf, \"-\",\n>                          NULL);\n>\n> --\n> 2.12.2\n>\n"},{"id":"316203","messageId":"CACBZZX43nYQH3+TX5vvrM-btzQNWsOWi62G6zPXw_BZmZb2dJA@mail.gmail.com","threadId":"45602","inReplyTo":"20170405130424.13803-7-tgc@jupiterrise.com","subject":"Re: [PATCH 6/7] Handle missing CURLINFO_SSL_DATA_{IN,OUT}","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-05T13:52:24Z","receivedAt":"2017-04-05T13:54:13Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen <tgc@jupiterrise.com> wrote:\n> Do not try and use CURLINFO_SSL_DATA_{IN,OUT} for curl < 7.12.1.\n\nDisables code added by Elia Pinto in 74c682d3c6. Looks harmless to me\nsince it's just omitting some information when GIT_TRACE_CURL is set.\n\n> Signed-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n> ---\n>  http.c | 4 ++++\n>  1 file changed, 4 insertions(+)\n>\n> diff --git a/http.c b/http.c\n> index ce618bdca..a46ab23af 100644\n> --- a/http.c\n> +++ b/http.c\n> @@ -649,10 +649,12 @@ static int curl_trace(CURL *handle, curl_infotype type, char *data, size_t size,\n>                 text = \"=> Send data\";\n>                 curl_dump_data(text, (unsigned char *)data, size);\n>                 break;\n> +#if LIBCURL_VERSION_NUM >= 0x070c01\n>         case CURLINFO_SSL_DATA_OUT:\n>                 text = \"=> Send SSL data\";\n>                 curl_dump_data(text, (unsigned char *)data, size);\n>                 break;\n> +#endif\n>         case CURLINFO_HEADER_IN:\n>                 text = \"<= Recv header\";\n>                 curl_dump_header(text, (unsigned char *)data, size, NO_FILTER);\n> @@ -661,10 +663,12 @@ static int curl_trace(CURL *handle, curl_infotype type, char *data, size_t size,\n>                 text = \"<= Recv data\";\n>                 curl_dump_data(text, (unsigned char *)data, size);\n>                 break;\n> +#if LIBCURL_VERSION_NUM >= 0x070c01\n>         case CURLINFO_SSL_DATA_IN:\n>                 text = \"<= Recv SSL data\";\n>                 curl_dump_data(text, (unsigned char *)data, size);\n>                 break;\n> +#endif\n>         }\n>         return 0;\n>  }\n> --\n> 2.12.2\n>\n"},{"id":"316204","messageId":"CACBZZX7wc+aMgonzeLpv-O7c2p0AC9-q+EP5rf+SuR89V=WEVw@mail.gmail.com","threadId":"45602","inReplyTo":"20170405130424.13803-8-tgc@jupiterrise.com","subject":"Re: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-05T13:53:29Z","receivedAt":"2017-04-05T13:55:32Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen <tgc@jupiterrise.com> wrote:\n> Commit 17966c0a added an unguarded use of curl_easy_strerror.\n> This adds a guard so it is not used with curl < 7.12.0.\n\nLooks good to me. Eric Wong added this in 17966c0a63.\n\n> Signed-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n> ---\n>  http.c | 4 ++++\n>  1 file changed, 4 insertions(+)\n>\n> diff --git a/http.c b/http.c\n> index a46ab23af..104caaa75 100644\n> --- a/http.c\n> +++ b/http.c\n> @@ -2116,8 +2116,12 @@ static size_t fwrite_sha1_file(char *ptr, size_t eltsize, size_t nmemb,\n>                 CURLcode c = curl_easy_getinfo(slot->curl, CURLINFO_HTTP_CODE,\n>                                                 &slot->http_code);\n>                 if (c != CURLE_OK)\n> +#if LIBCURL_VERSION_NUM >= 0x070c00\n>                         die(\"BUG: curl_easy_getinfo for HTTP code failed: %s\",\n>                                 curl_easy_strerror(c));\n> +#else\n> +                       die(\"BUG: curl_easy_getinfo for HTTP code failed\");\n> +#endif\n>                 if (slot->http_code >= 300)\n>                         return size;\n>         }\n> --\n> 2.12.2\n>\n"},{"id":"316205","messageId":"CACBZZX4OVy0QOnPLYNY0pptvno+OJ-c6=sRtVWcT+40aaEGY2w@mail.gmail.com","threadId":"45602","inReplyTo":"20170405130424.13803-5-tgc@jupiterrise.com","subject":"Re: [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-05T13:50:58Z","receivedAt":"2017-04-05T13:56:02Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen <tgc@jupiterrise.com> wrote:\n> With curl < 7.10.7 we cannot get the proxy CONNECT response code.\n> As a workaround set it to zero which means no response code available.\n\nCC-ing Knut Franke <k.franke@science-computing.de> which added this\ncode in 372370f167.\n\nThis effectively disables that code & this later check:\n\n+               if (results->http_connectcode == 407)\n+                       credential_reject(&proxy_auth);\n\nWhat's the impact of not taking that branch when the proxy returns a 407?\n\n> Signed-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n> ---\n>  http.c | 4 ++++\n>  1 file changed, 4 insertions(+)\n>\n> diff --git a/http.c b/http.c\n> index 96d84bbed..ce618bdca 100644\n> --- a/http.c\n> +++ b/http.c\n> @@ -214,8 +214,12 @@ static void finish_active_slot(struct active_request_slot *slot)\n>                 slot->results->auth_avail = 0;\n>  #endif\n>\n> +#if LIBCURL_VERSION_NUM >= 0x070a07\n>                 curl_easy_getinfo(slot->curl, CURLINFO_HTTP_CONNECTCODE,\n>                         &slot->results->http_connectcode);\n> +#else\n> +               slot->results->http_connectcode = 0;\n> +#endif\n>         }\n>\n>         /* Run callback if appropriate */\n> --\n> 2.12.2\n>\n"},{"id":"316207","messageId":"53a2d323-bbae-88b7-b0fb-aecdc36b8eb4@jupiterrise.com","threadId":"45602","inReplyTo":"CACBZZX7_tH-Q6PWdj=2BryLnSw-dX__fuR8hvbwXG4sSaM61bg@mail.gmail.com","subject":"Re: [PATCH 3/7] Allow svnrdump_sim.py to be used with Python 2.2","fromName":"Tom G. Christensen","fromEmail":"tgc@jupiterrise.com","sentAt":"2017-04-05T14:36:38Z","receivedAt":"2017-04-05T14:37:19Z","isPatch":true,"sender":{"key":"tgc@jupiterrise.com","avatar":"https://avatars.githubusercontent.com/u/912180?v=4"},"body":"On 05/04/17 15:40, Ævar Arnfjörð Bjarmason wrote:\n> On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen <tgc@jupiterrise.com> wrote:\n>> This allows running the git-svn testsuite with Python 2.2.\n>\n> +CC-ing Eric S. Raymond who added these version limitations in a33faf2827.\n>\n> Also, in his patch contrib/svn-fe/svnrdump_sim.py,\n> git_remote_helpers/git/__init__.py & git-p4.py is set to >=2.4 or\n> later.\n>\n> Are you skipping those tests & they don't work under 2.2?\n>\n\nI don't know what git_remote_helpers/git/__init__.py does or which tests \nwould run it.\nI know that git-p4 tests require p4 which I don't have hence the tests \nare automatically skipped.\n\n-tgc\n"},{"id":"316210","messageId":"20170405155827.GE6493@science-computing.de","threadId":"45602","inReplyTo":"CACBZZX4OVy0QOnPLYNY0pptvno+OJ-c6=sRtVWcT+40aaEGY2w@mail.gmail.com","subject":"Re: [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7","fromName":"Franke, Knut","fromEmail":"knut.franke@atos.net","sentAt":"2017-04-05T15:58:27Z","receivedAt":"2017-04-05T16:05:17Z","isPatch":true,"sender":{"key":"knut.franke@atos.net","avatar":null},"body":"On 2017-04-05 15:50, Ævar Arnfjörð Bjarmason wrote:\n> This effectively disables that code & this later check:\n> \n> +               if (results->http_connectcode == 407)\n> +                       credential_reject(&proxy_auth);\n> \n> What's the impact of not taking that branch when the proxy returns a 407?\n\nWe might be storing incorrect proxy credentials via the credential helper. If we can't get the\nproxy's connect code, we should probably invalidate proxy credentials whenever http_code indicates\nfailure, since that's the only effect we'll see of a mistyped proxy password.\n"},{"id":"316246","messageId":"20170406005301.4vmjkiu6qkj3g276@genre.crustytoothpaste.net","threadId":"45602","inReplyTo":"CACBZZX450tRRsy-Sj8igZthYov7UxFMRJ51M-b1cgYBLo782jQ@mail.gmail.com","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2017-04-06T00:53:01Z","receivedAt":"2017-04-06T00:53:21Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Wed, Apr 05, 2017 at 12:51:38PM +0200, Ævar Arnfjörð Bjarmason wrote:\n> On Wed, Apr 5, 2017 at 11:33 AM, Tom G. Christensen <tgc@jupiterrise.com> wrote:\n> Whoah. So my assumption in\n> <CACBZZX78oKU5HuBEqb9qLy7--wcwhC_mW6x7Q+tB4suxohSCsQ@mail.gmail.com>\n> that nobody was compiling this & thus not reporting failures was\n> false. Rather there's an entire community & distribution mechanism\n> around patching git for older EL versions, but the patches aren't\n> making it upstream.\n> \n> $ grep -h -e ^Subject -e ^Date *patch\n> Date: Tue, 13 Oct 2009 11:34:11 +0200\n> Subject: [PATCH 1/7] Make NO_PERL_MAKEMAKER behave more like\n> Date: Fri, 13 Jun 2014 11:02:02 +0200\n> Subject: [PATCH 2/7] Install man pages when NO_PERL_MAKEMAKER is used\n> Date: Mon, 22 Sep 2014 13:42:50 +0200\n> Subject: [PATCH 3/7] Allow svnrdump_sim.py to be used with Python 2.2\n> Date: Tue, 8 Mar 2016 09:31:56 +0100\n> Subject: [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7\n> Date: Tue, 23 Aug 2016 10:32:51 +0200\n> Subject: [PATCH 5/7] Add support for gnupg < 1.4\n> Date: Tue, 23 Aug 2016 18:15:13 +0200\n> Subject: [PATCH 6/7] Handle missing CURLINFO_SSL_DATA_{IN,OUT}\n> Date: Tue, 23 Aug 2016 18:26:54 +0200\n> Subject: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0\n> Date: Wed, 2 Feb 2011 21:24:44 -0500\n> Subject: [PATCH] Restore vc-git.el for basic compatibility on EL-5\n> Date: Mon, 23 Mar 2009 00:03:36 -0400\n> Subject: [PATCH] git-cvsimport: Ignore cvsps-2.2b1 Branches: output\n> \n> > Patches can be found in the src.rpm, though I can also post them here as\n> > patch series, they cover more than just curl.\n> >\n> > I don't use the el3 and el4 versions much any more and el5 use will also\n> > drop of now as I'm busy converting machines from el5 to el7.\n> \n> It would be great to have them on-list, as far as I can tell they were\n> never submitted? Is there some time/administrative reason for why\n> you're not submitting them? Some of these are many years old, it would\n> be great to have them on-list for wider review & included so vanilla\n> git works on these platforms.\n\nI'm very opposed to accepting patches for operating systems that are no\nlonger security supported.  Having insecure systems directly or\nindirectly connected to the Internet is a very bad thing, and we\nshouldn't make it easier for people who want to do that.\n\nCentOS 6 and 7 are still in use and security supported, and I think we\nshould support them.  CentOS 5 is EOL, although RHEL 5 is still\nsupported in some cases.  RHEL 4 and earlier are definitely out of\nsupport and we shouldn't support or consider them further.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"316247","messageId":"20170406011610.GF25542@zaya.teonanacatl.net","threadId":"45602","inReplyTo":"20170406005301.4vmjkiu6qkj3g276@genre.crustytoothpaste.net","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2017-04-06T01:16:10Z","receivedAt":"2017-04-06T01:16:21Z","isPatch":false,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"brian m. carlson wrote:\n> On Wed, Apr 05, 2017 at 12:51:38PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>> On Wed, Apr 5, 2017 at 11:33 AM, Tom G. Christensen <tgc@jupiterrise.com> wrote:\n>> Whoah. So my assumption in \n>> <CACBZZX78oKU5HuBEqb9qLy7--wcwhC_mW6x7Q+tB4suxohSCsQ@mail.gmail.com>\n>> that nobody was compiling this & thus not reporting failures was \n>> false. Rather there's an entire community & distribution mechanism \n>> around patching git for older EL versions, but the patches aren't \n>> making it upstream.\n>>\n>> $ grep -h -e ^Subject -e ^Date *patch \n>> Date: Tue, 13 Oct 2009 11:34:11 +0200 \n>> Subject: [PATCH 1/7] Make NO_PERL_MAKEMAKER behave more like \n>> Date: Fri, 13 Jun 2014 11:02:02 +0200 \n>> Subject: [PATCH 2/7] Install man pages when NO_PERL_MAKEMAKER is used \n>> Date: Mon, 22 Sep 2014 13:42:50 +0200 \n>> Subject: [PATCH 3/7] Allow svnrdump_sim.py to be used with Python 2.2 \n>> Date: Tue, 8 Mar 2016 09:31:56 +0100 \n>> Subject: [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7 \n>> Date: Tue, 23 Aug 2016 10:32:51 +0200 \n>> Subject: [PATCH 5/7] Add support for gnupg < 1.4 \n>> Date: Tue, 23 Aug 2016 18:15:13 +0200 \n>> Subject: [PATCH 6/7] Handle missing CURLINFO_SSL_DATA_{IN,OUT} \n>> Date: Tue, 23 Aug 2016 18:26:54 +0200 \n>> Subject: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0 \n>> Date: Wed, 2 Feb 2011 21:24:44 -0500 \n>> Subject: [PATCH] Restore vc-git.el for basic compatibility on EL-5 \n>> Date: Mon, 23 Mar 2009 00:03:36 -0400 \n>> Subject: [PATCH] git-cvsimport: Ignore cvsps-2.2b1 Branches: output\n>>\n>>> Patches can be found in the src.rpm, though I can also post them here as \n>>> patch series, they cover more than just curl.\n>>>\n>>> I don't use the el3 and el4 versions much any more and el5 use will also \n>>> drop of now as I'm busy converting machines from el5 to el7.\n>>\n>> It would be great to have them on-list, as far as I can tell they were \n>> never submitted? Is there some time/administrative reason for why \n>> you're not submitting them? Some of these are many years old, it would \n>> be great to have them on-list for wider review & included so vanilla \n>> git works on these platforms.\n\nThe vc-git.el patch which I think came from the Fedora/EPEL package \nfor EL-5 was only intended to restore functionality to support the \nolder emacs on EL-5.  Now that EL-5 is EOL, it can (thankfully, IMO) \ndie off.\n\nThe git-csvimport patch looks to be in the same category (assuming it \nwas similar to what we included in the EPEL packages for EL-5 \nsupport).  It was only needed (and applied) to support older systems \nand wasn't something worth carrying upstream.\n\n> I'm very opposed to accepting patches for operating systems that are no \n> longer security supported.  Having insecure systems directly or \n> indirectly connected to the Internet is a very bad thing, and we \n> shouldn't make it easier for people who want to do that.\n\nI concur.  I (or we, the Fedora/EPEL package maintainers for git) have \ntried to ensure that the packages for the latest Fedora release build \ncleanly for all supported Fedora and EL releases.  I think that is \nuseful for those who use CentOS/RHEL and still want to have a recent \ngit build.\n\nI don't see any benefit in making it easier for folks to run systems \nthat are no longer receiving updates for critical security issues.    \nIt's surely hard enough to support EL-6 as it ages. ;)\n\n> CentOS 6 and 7 are still in use and security supported, and I think \n> we should support them.  CentOS 5 is EOL, although RHEL 5 is still \n> supported in some cases.  RHEL 4 and earlier are definitely out of \n> support and we shouldn't support or consider them further.\n\nI know RHEL 5 has some extended support from Red Hat, but EPEL-5 is \ndead.  So from my perspective, supporting EL-5 isn't worth the effort.\n\n-- \nTodd\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nStatistics are like a lamp-post to a drunken man - more for leaning on\nthan illumination.\n\n"},{"id":"316265","messageId":"20170406091857.hl4ndn52kj2z4ujh@sigill.intra.peff.net","threadId":"45602","inReplyTo":"20170405130424.13803-8-tgc@jupiterrise.com","subject":"Re: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-06T09:18:57Z","receivedAt":"2017-04-06T09:19:20Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 05, 2017 at 03:04:24PM +0200, Tom G. Christensen wrote:\n\n> Commit 17966c0a added an unguarded use of curl_easy_strerror.\n> This adds a guard so it is not used with curl < 7.12.0.\n> \n> Signed-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n> ---\n>  http.c | 4 ++++\n>  1 file changed, 4 insertions(+)\n> \n> diff --git a/http.c b/http.c\n> index a46ab23af..104caaa75 100644\n> --- a/http.c\n> +++ b/http.c\n> @@ -2116,8 +2116,12 @@ static size_t fwrite_sha1_file(char *ptr, size_t eltsize, size_t nmemb,\n>  \t\tCURLcode c = curl_easy_getinfo(slot->curl, CURLINFO_HTTP_CODE,\n>  \t\t\t\t\t\t&slot->http_code);\n>  \t\tif (c != CURLE_OK)\n> +#if LIBCURL_VERSION_NUM >= 0x070c00\n>  \t\t\tdie(\"BUG: curl_easy_getinfo for HTTP code failed: %s\",\n>  \t\t\t\tcurl_easy_strerror(c));\n> +#else\n> +\t\t\tdie(\"BUG: curl_easy_getinfo for HTTP code failed\");\n> +#endif\n\nThese kinds of interleaved conditionals make me nervous that we'll get\nsomething wrong (especially without braces, it's not immediately clear\nthat both sides are a single statement).\n\nI wonder if it would be more readable to do something like:\n\n  #if LIBCURL_VERSION_NUM < 0x070c00\n  static const char *curl_easy_strerror(CURL *curl)\n  {\n\treturn \"[error code unavailable; curl version too old]\";\n  }\n  #endif\n\nThen callers don't have to individually deal with the ifdef. It does\nmean that the user sees that kind-of ugly message, but maybe that is a\ngood thing. They know they need to upgrade curl to see more details.\n\n-Peff\n"},{"id":"316266","messageId":"20170406092122.titsfyxpucj6xoe4@sigill.intra.peff.net","threadId":"45602","inReplyTo":"d6ba17f0-3da9-8699-8d5c-5ebf1eaef00e@jupiterrise.com","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-06T09:21:22Z","receivedAt":"2017-04-06T09:21:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 05, 2017 at 11:33:37AM +0200, Tom G. Christensen wrote:\n\n> FWIW I maintain freely available updated git packages for RHEL 3, 4, 5, 6\n> and 7.\n> \n> They can be found here:\n> https://jupiterrise.com/blog/jrpms/\n> \n> And direct access here:\n> https://jupiterrise.com/jrpms/ (for el3,el4,el5)\n> https://jupiterrise.com/jrpmsplus/ (for el6, el7)\n> \n> They are built against system versions of curl though a few patches are\n> required for 7.10.6 (el3) and 7.12.1 (el4) support.\n> Patches can be found in the src.rpm, though I can also post them here as\n> patch series, they cover more than just curl.\n> \n> I don't use the el3 and el4 versions much any more and el5 use will also\n> drop of now as I'm busy converting machines from el5 to el7.\n\nThanks for sharing, that's a really interesting data point.\n\nI'm not quite sure what to take away from it, though. Either \"yes,\nsomebody really is using Git with antique versions of curl\". Or \"even\nthe antique people are giving up el4, and it might be reasonable to\nstart requiring curl >= 7.11.0\".\n\n-Peff\n"},{"id":"316267","messageId":"20170406092942.ow4mvce5miyzbgld@sigill.intra.peff.net","threadId":"45602","inReplyTo":"20170406005301.4vmjkiu6qkj3g276@genre.crustytoothpaste.net","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-06T09:29:42Z","receivedAt":"2017-04-06T09:31:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 06, 2017 at 12:53:01AM +0000, brian m. carlson wrote:\n\n> > It would be great to have them on-list, as far as I can tell they were\n> > never submitted? Is there some time/administrative reason for why\n> > you're not submitting them? Some of these are many years old, it would\n> > be great to have them on-list for wider review & included so vanilla\n> > git works on these platforms.\n> \n> I'm very opposed to accepting patches for operating systems that are no\n> longer security supported.  Having insecure systems directly or\n> indirectly connected to the Internet is a very bad thing, and we\n> shouldn't make it easier for people who want to do that.\n\nHmm. I'm not sure whether I agree with that or not. I certainly wouldn't\nwant to _encourage_ people to use ancient unpatched systems. But I'm\nalso not entirely comfortable passing judgements on people's OS choices.\nSecurity isn't a discrete variable, and there are lots of situations\nwhere it makes sense to stick with an old, unpatched system because the\nrisk of changing it outweighs the risk of it being attacked (think\nmission-critical systems sitting behind firewalls).\n\nThat said, I don't mind the argument \"even the people who made this OS\nare no longer supporting it; why should we?\". And the response from Todd\nseems to reinforce that.\n\nAnd it's not like people on ancient mission-critical systems get cut\noff. They can still run the version of Git they were running when their\nOS went out of support.\n\n-Peff\n"},{"id":"316290","messageId":"ef64656b-12d7-a041-e1b9-ce83f8cbd2fc@jupiterrise.com","threadId":"45602","inReplyTo":"20170406092122.titsfyxpucj6xoe4@sigill.intra.peff.net","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Tom G. Christensen","fromEmail":"tgc@jupiterrise.com","sentAt":"2017-04-06T16:43:06Z","receivedAt":"2017-04-06T16:43:18Z","isPatch":false,"sender":{"key":"tgc@jupiterrise.com","avatar":"https://avatars.githubusercontent.com/u/912180?v=4"},"body":"On 06/04/17 11:21, Jeff King wrote:\n> On Wed, Apr 05, 2017 at 11:33:37AM +0200, Tom G. Christensen wrote:\n>> I don't use the el3 and el4 versions much any more and el5 use will also\n>> drop of now as I'm busy converting machines from el5 to el7.\n>\n> Thanks for sharing, that's a really interesting data point.\n>\n> I'm not quite sure what to take away from it, though. Either \"yes,\n> somebody really is using Git with antique versions of curl\". Or \"even\n> the antique people are giving up el4, and it might be reasonable to\n> start requiring curl >= 7.11.0\".\n>\n\nI do not know of anyone who actually need to have the latest git on \ntheir el3 or el4 system, myself included.\nI'm not here to champion the inclusion of support for el3 and el4, there \nis no point.\nI kept git buildable on those platforms since I could do so with minimal \neffort and good testresults, but this was entirely for my own satisfaction.\n\nI know of no users of the packages that I make available other than \nmyself and my work place (only el5 and later, soon just el6 and later).\n\nThere is not currently any patches needed to use git on el5 with curl \n7.15.5. The only thing not working out of the box in 2.12.2 would be the \nemacs integration.\n\nIf you must drop support for old curl releases then from my perspective \nthe cutoff should be 7.19.7 at the latest since that is what ships with \nRHEL 6 and that is still supported by Red Hat.\nOther long term supported Linux releases may have different ideas, I \nwouldn't know.\n\n-tgc\n"},{"id":"316319","messageId":"20170407045427.rqrqdt5mxzudonzo@sigill.intra.peff.net","threadId":"45602","inReplyTo":"ef64656b-12d7-a041-e1b9-ce83f8cbd2fc@jupiterrise.com","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-07T04:54:27Z","receivedAt":"2017-04-07T04:54:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 06, 2017 at 06:43:06PM +0200, Tom G. Christensen wrote:\n\n> On 06/04/17 11:21, Jeff King wrote:\n> > On Wed, Apr 05, 2017 at 11:33:37AM +0200, Tom G. Christensen wrote:\n> > > I don't use the el3 and el4 versions much any more and el5 use will also\n> > > drop of now as I'm busy converting machines from el5 to el7.\n> > \n> > Thanks for sharing, that's a really interesting data point.\n> > \n> > I'm not quite sure what to take away from it, though. Either \"yes,\n> > somebody really is using Git with antique versions of curl\". Or \"even\n> > the antique people are giving up el4, and it might be reasonable to\n> > start requiring curl >= 7.11.0\".\n\n[Aside: re-reading my second paragraph above, it sounds like I am\n complaining that your comment wasn't clear. But you were perfectly\n clear. It's just that with your data point I am more conflicted than\n ever].\n\n> I know of no users of the packages that I make available other than myself\n> and my work place (only el5 and later, soon just el6 and later).\n> \n> There is not currently any patches needed to use git on el5 with curl\n> 7.15.5. The only thing not working out of the box in 2.12.2 would be the\n> emacs integration.\n\nI think I'm leaning towards the very first patch I posted, that assumes\n7.11.0 and later. And then hold off on the others for a few years. In\nterms of \"number of ifdefs removed\" we could go further, but I think it\nwas the first patch that removes a lot of the really questionable bits\n(like silently ignoring security-related features).\n\n> If you must drop support for old curl releases then from my perspective the\n> cutoff should be 7.19.7 at the latest since that is what ships with RHEL 6\n> and that is still supported by Red Hat.\n\nYeah, I think 7.19.7 would be the next reasonable cutoff (it shipped in\nRHEL6, which is a reasonable standard for long-term support; and it\ncatches quite a few ifdefs in our code). But I think we can give RHEL5 a\nbit more time. It just left its support window a few days ago.\n\n-Peff\n"},{"id":"316332","messageId":"alpine.DEB.2.20.1704071257560.4268@virtualbox","threadId":"45602","inReplyTo":"20170406092942.ow4mvce5miyzbgld@sigill.intra.peff.net","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-04-07T11:18:30Z","receivedAt":"2017-04-07T11:19:30Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Thu, 6 Apr 2017, Jeff King wrote:\n\n> And it's not like people on ancient mission-critical systems get cut\n> off. They can still run the version of Git they were running when their\n> OS went out of support.\n\nYou keep baiting me, so I'll bite, after resisting the urge for so long.\n\nLet me share a little story of my own. So that this is not some academic,\ntheoretical wanking off, but something very tangible, very concrete, and\nsomething very hard to handwave away.\n\nAs you know, in my previous job I was working as a scientist. Part of my\njob was to support other scientists e.g. when they were using that really\nbig, really expensive, really advanced and super cool microscope. The\n\"really advanced\" part only applied to the hardware, though, they were\nrunning a super old CentOS, and everything was clamped down pretty good\n(as many microscope vendors are wont to do), so there was no way to\nupgrade the OS (I do not recall whether the drivers were only available\nfor this particular version of CentOS, but it would make sense, wouldn't\nit, now, as microscope vendors are much more of experts in microscope\nhardware than in anything vaguely related to software, even if they like\nto pretend to be experts in both).\n\nI did have access to gcc, though. And I did have to get Git working to be\nable to install and develop additional software on that machine. It did\ntake me a while to get things to compile because of ancient libraries\nbeing installed on that machine. Since only trusted people were allowed to\nuse that machine, security on that box was not really an issue. It did\nmake work for my colleagues substantially easier once I could develop on\nthat machine, using Git.\n\nJust imagine how thankful I was that support for these old library\nversions was almost working, still, and the one bigger problem I had was\neasily solved by a patch that a quick web search found!\n\nThis. This is the impact of supporting older library versions, even if\nthey are long EOL.\n\nDo not get me wrong: I am all for dropping support that is a huge\nmaintenance burden. You probably do not know the full back story, but let\nme tell you what a relief it was to drop Windows XP support in Git for\nWindows (and the Cygwin developers can sing several epic, Lord of the\nRings sized war songs about that, too).\n\nAt the same time, I want us to do better than all those maintainers out\nthere who drop backwards-compatibility just for the heck of it, not\nbecause it would be a huge maintenance burden. \"Everybody should upgrade,\nanyway\" is usually the naive excuse for not knowing why users are often\nunable to upgrade.\n\nGit is incredibly popular, and part of that is due to us being inclusive\nand open and supporting a wide range of platforms. Yes, we can always do a\nbetter job, that is true. We are also doing pretty well, though, and I\nthink that part of the reason is that we weigh carefully the maintenance\ncost against the benefit of our users. Tiny \"cleanup\" patches that fail to\nimprove the maintenance burden substantially, and that also make users'\nlives harder, are rightfully rejected. A little harder work from us\nmaintainers goes a long way to make a lot of users a lot happier.\n\nMy former self in my former life as a scientist is very thankful for the\nconsideration that goes into each and every \"should we drop supporting\nXYZ?\" decision.\n\nVery, very thankful.\n\nCiao,\nDscho\n"},{"id":"316506","messageId":"20170410182215.figy7hm4sogwipyz@sigill.intra.peff.net","threadId":"45602","inReplyTo":"alpine.DEB.2.20.1704071257560.4268@virtualbox","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-10T18:22:15Z","receivedAt":"2017-04-10T18:22:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 07, 2017 at 01:18:30PM +0200, Johannes Schindelin wrote:\n\n> On Thu, 6 Apr 2017, Jeff King wrote:\n> \n> > And it's not like people on ancient mission-critical systems get cut\n> > off. They can still run the version of Git they were running when their\n> > OS went out of support.\n> \n> You keep baiting me, so I'll bite, after resisting the urge for so long.\n\nI wasn't going to respond to this, because I didn't feel like the\ndiscussion was going anywhere. But I ran across yet another issue\nrelated to this today that hadn't been mentioned yet.\n\nYour story shows that yes, it's convenient when old libraries are\nsupported. I don't dispute that. But one of my earlier points is that\nthis isn't just about maintenance burden (which I agree is not huge);\nit's about whether we do a disservice to users to pretend that Git is\neven remotely tested with older versions of curl.\n\nFor instance, did you know that versions of curl prior to v7.17 rely on\nany strings fed via curl_easy_setopt() remaining valid for the lifetime\nof the curl handle[1]?\n\nWe have some workarounds for this in old code (for example, see the\nhandling of CURLOPT_PASSWORD in http.c), but a lot of calls have been\nadded since then. I think there's a very good chance there are\nuse-after-free bugs when Git is compiled against an older curl.\n\nI'm concerned that we're giving users a false sense of what is\nreasonable to compile against.  You can reframe that as a maintenance\nquestion (we _could_ find and fix those bugs), but that changes the\ncost/benefit analysis.\n\n[1] http://public-inbox.org/git/alpine.DEB.2.00.1306180825460.24456@tvnag.unkk.fr/\n\n-Peff\n"},{"id":"316714","messageId":"xmqqbms0q0s3.fsf@gitster.mtv.corp.google.com","threadId":"45602","inReplyTo":"20170406091857.hl4ndn52kj2z4ujh@sigill.intra.peff.net","subject":"Re: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-13T06:28:28Z","receivedAt":"2017-04-13T06:28:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Apr 05, 2017 at 03:04:24PM +0200, Tom G. Christensen wrote:\n> ...\n> These kinds of interleaved conditionals make me nervous that we'll get\n> something wrong (especially without braces, it's not immediately clear\n> that both sides are a single statement).\n>\n> I wonder if it would be more readable to do something like:\n>\n>   #if LIBCURL_VERSION_NUM < 0x070c00\n>   static const char *curl_easy_strerror(CURL *curl)\n>   {\n> \treturn \"[error code unavailable; curl version too old]\";\n>   }\n>   #endif\n>\n> Then callers don't have to individually deal with the ifdef. It does\n> mean that the user sees that kind-of ugly message, but maybe that is a\n> good thing. They know they need to upgrade curl to see more details.\n\nYup, thanks for a very good suggestion.\n"},{"id":"316715","messageId":"xmqq7f2oq0mq.fsf@gitster.mtv.corp.google.com","threadId":"45602","inReplyTo":"CACBZZX6bYLRSUAy2GUYhBVet3tjzrBQ40L49KxetAvBdgx_x+w@mail.gmail.com","subject":"Re: [PATCH 5/7] Add support for gnupg < 1.4","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-13T06:31:41Z","receivedAt":"2017-04-13T06:31:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen <tgc@jupiterrise.com> wrote:\n>> This adds an OLD_GNUPG define to the Makefile which when activated will\n>> ensure git does not use the --keyid-format argument when calling the\n>> 'gpg' program.\n>> This is consistent with how 'gpg' was used in git < 2.10.0 and slightly\n>> decreases security.\n>\n> This changes the code Linus Torvalds added in b624a3e67f to mitigate\n> the evil32 project generating keys which looked the same for 32 bit\n> signatures.\n>\n> I think this change makes sense, but the Makefile should have a\n> slightly scarier warning, something like:\n>\n> \"Define OLD_GNUPG if you need support for gnupg <1.4. Note that this\n> will cause git to only show the first 32 bits of PGP keys instead of\n> 64, and there's a wide variety of brute-forced 32 bit keys in the wild\n> thanks to the evil32 project (https://evil32.com). Enabling this will\n> make GPG work old versions, but you might be fooled into accepting\n> malicious keys as a result\".\n\nVery good point.  It surprised me somewhat to see that this is the\nonly change necessary (iow, there is no need to tweak anything in t/\ndirectory).  Perhaps we would need a test or two (and need to figure\nout a way to make them work with both old and more recent GnuPG)?\n"},{"id":"316720","messageId":"CA+P7+xpnbcaJ8ucxfF9pGiN6=72jbq=EvRfX1qKOkG_QjWh+DA@mail.gmail.com","threadId":"45602","inReplyTo":"xmqqbms0q0s3.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-04-13T10:52:21Z","receivedAt":"2017-04-13T10:52:48Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Apr 12, 2017 at 11:28 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>\n>> On Wed, Apr 05, 2017 at 03:04:24PM +0200, Tom G. Christensen wrote:\n>> ...\n>> These kinds of interleaved conditionals make me nervous that we'll get\n>> something wrong (especially without braces, it's not immediately clear\n>> that both sides are a single statement).\n>>\n>> I wonder if it would be more readable to do something like:\n>>\n>>   #if LIBCURL_VERSION_NUM < 0x070c00\n>>   static const char *curl_easy_strerror(CURL *curl)\n>>   {\n>>       return \"[error code unavailable; curl version too old]\";\n>>   }\n>>   #endif\n>>\n>> Then callers don't have to individually deal with the ifdef. It does\n>> mean that the user sees that kind-of ugly message, but maybe that is a\n>> good thing. They know they need to upgrade curl to see more details.\n>\n> Yup, thanks for a very good suggestion.\n\nI also think this is a good solution..\n\nThanks,\nJake\n"},{"id":"316723","messageId":"CACBZZX56Fx+niwwsiJeMwvaZkuR3h4zxytu+xx_sanobMPGobg@mail.gmail.com","threadId":"45602","inReplyTo":"CACBZZX6bYLRSUAy2GUYhBVet3tjzrBQ40L49KxetAvBdgx_x+w@mail.gmail.com","subject":"Re: [PATCH 5/7] Add support for gnupg < 1.4","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-13T15:17:59Z","receivedAt":"2017-04-13T15:18:26Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 5, 2017 at 3:45 PM, Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> On Wed, Apr 5, 2017 at 3:04 PM, Tom G. Christensen <tgc@jupiterrise.com> wrote:\n>> This adds an OLD_GNUPG define to the Makefile which when activated will\n>> ensure git does not use the --keyid-format argument when calling the\n>> 'gpg' program.\n>> This is consistent with how 'gpg' was used in git < 2.10.0 and slightly\n>> decreases security.\n>\n> This changes the code Linus Torvalds added in b624a3e67f to mitigate\n> the evil32 project generating keys which looked the same for 32 bit\n> signatures.\n>\n> I think this change makes sense, but the Makefile should have a\n> slightly scarier warning, something like:\n>\n> \"Define OLD_GNUPG if you need support for gnupg <1.4. Note that this\n> will cause git to only show the first 32 bits of PGP keys instead of\n> 64, and there's a wide variety of brute-forced 32 bit keys in the wild\n> thanks to the evil32 project (https://evil32.com). Enabling this will\n> make GPG work old versions, but you might be fooled into accepting\n\ngrammar fix: \"work on older versions\"....\n\n> malicious keys as a result\".\n>\n>> Signed-off-by: Tom G. Christensen <tgc@jupiterrise.com>\n>> ---\n>>  Makefile        | 6 ++++++\n>>  gpg-interface.c | 2 ++\n>>  2 files changed, 8 insertions(+)\n>>\n>> diff --git a/Makefile b/Makefile\n>> index ca9f16d19..f8f585d21 100644\n>> --- a/Makefile\n>> +++ b/Makefile\n>> @@ -386,6 +386,8 @@ all::\n>>  #\n>>  # to say \"export LESS=FRX (and LV=-c) if the environment variable\n>>  # LESS (and LV) is not set, respectively\".\n>> +#\n>> +# Define OLD_GNUPG if you need support for gnupg < 1.4.\n>>\n>>  GIT-VERSION-FILE: FORCE\n>>         @$(SHELL_PATH) ./GIT-VERSION-GEN\n>> @@ -1529,6 +1531,10 @@ ifndef PAGER_ENV\n>>  PAGER_ENV = LESS=FRX LV=-c\n>>  endif\n>>\n>> +ifdef OLD_GNUPG\n>> +       BASIC_CFLAGS += -DOLD_GNUPG\n>> +endif\n>> +\n>>  QUIET_SUBDIR0  = +$(MAKE) -C # space to separate -C and subdir\n>>  QUIET_SUBDIR1  =\n>>\n>> diff --git a/gpg-interface.c b/gpg-interface.c\n>> index e44cc27da..57f1ea792 100644\n>> --- a/gpg-interface.c\n>> +++ b/gpg-interface.c\n>> @@ -224,7 +224,9 @@ int verify_signed_buffer(const char *payload, size_t payload_size,\n>>         argv_array_pushl(&gpg.args,\n>>                          gpg_program,\n>>                          \"--status-fd=1\",\n>> +#ifndef OLD_GNUPG\n>>                          \"--keyid-format=long\",\n>> +#endif\n>>                          \"--verify\", temp.filename.buf, \"-\",\n>>                          NULL);\n>>\n>> --\n>> 2.12.2\n>>\n"},{"id":"316811","messageId":"xmqq4lxrnsza.fsf@gitster.mtv.corp.google.com","threadId":"45602","inReplyTo":"20170407045427.rqrqdt5mxzudonzo@sigill.intra.peff.net","subject":"Re: [RFC] dropping support for ancient versions of curl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-14T11:12:09Z","receivedAt":"2017-04-14T11:12:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I think I'm leaning towards the very first patch I posted, that assumes\n> 7.11.0 and later. And then hold off on the others for a few years. In\n> terms of \"number of ifdefs removed\" we could go further, but I think it\n> was the first patch that removes a lot of the really questionable bits\n> (like silently ignoring security-related features).\n\nI do not have problems with setting cut-off at 7.11.0; I do not\nforesee anybody who actively maintains a port for a platform whose\ncURL is older than that version would step up ;-)\n\nThanks.\n"}]}