{"thread":{"id":"62308","subject":"[PATCH 01/13] git-curl-compat: remove check for curl 7.21.5","startedAt":"2024-10-10T23:56:34Z","lastAt":"2024-10-24T21:53:19Z","messageCount":56,"participants":["brian m. carlson","Patrick Steinhardt","Jeff King","Oswald Buddenhagen","Alejandro R. Sedeño","Junio C Hamano","Eric Sunshine","Taylor Blau","Eli Schwartz","rsbecker@nexbridge.com"],"isPatch":true,"patchVersion":1,"patchTotal":13},"messages":[{"id":"504759","messageId":"20241010235621.738239-2-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH 01/13] git-curl-compat: remove check for curl 7.21.5","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:09Z","receivedAt":"2024-10-10T23:56:34Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.21.5 was released in April 2011, which is well over ten years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 7, RHEL 7, and Ubuntu 12.04, all of which are\nout of mainstream security support, have all supported a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 7 -------\n 1 file changed, 7 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex e1d0bdd273..c24ed686c1 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,13 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURL_SOCKOPT_OK was added in 7.21.5, released in April 2011.\n- */\n-#if LIBCURL_VERSION_NUM < 0x071505\n-#define CURL_SOCKOPT_OK 0\n-#endif\n-\n /**\n * CURLOPT_TCP_KEEPALIVE was added in 7.25.0, released in March 2012.\n */\n"},{"id":"504760","messageId":"20241010235621.738239-1-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":null,"subject":"[PATCH 00/13] Update versions of libcurl and Perl","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:08Z","receivedAt":"2024-10-10T23:56:34Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"For a long time, we ended up with protracted discussions on the mailing\nlist about what versions of software we should support. Oftentimes, we\nbroke long-obsolete operating system versions by using something shipped\nslightly more recently.\n\nFortunately, we now have a platform support policy to guide us in our\napproach to dependencies, so we can make updates without worrying about\nbreaking systems that have not received security support in several\nyears.\n\nThis series updates our requirements for libcurl to 7.61.0 (the version\nin RHEL 8) and for Perl to 5.26.0 (the version in 15.6). I considered\nthe mainstream LTS versions of RHEL, Debian, Ubuntu, and SLES, but\nomitted consideration of paid support extended LTS, since we cannot\nexpect Git developers to have to pay a large corporation lots of money\njust to test functionality. This is in conformance with our policy,\nwhich states that versions must be \"in line with the version used by\nother long-term-support distributions\", which does not include extended\nLTS distributions.\n\nThe libcurl dependency changes come in incremental patches so that if we\nhave people on unsupported systems, they can simply revert the patches\nthat they'd like to omit. It also makes the changes easier to review\nthan one giant commit.\n\nThe Perl changes are a huge upgrade. 5.8.1, our former supported\nversion, was from 2003. 5.26 has substantially improved Unicode support\n(including Unicode strings), s///r (to allow returning a modified value\ninstead of modifying it in place), postderef syntax (which also provides\nbetter interpolation for complex expressions), and subroutine signatures\n(although these are experimental until 5.36). These allow us much more\nreadable, modern Perl.\n\nThe final commit introduces a small but useful change that we can now\ntake advantage of with our newly updated Perl dependency as an example\nof why this is a generally beneficial change. It can be omitted without\nproblem if it is judged to be too noisy.\n\nbrian m. carlson (13):\n git-curl-compat: remove check for curl 7.21.5\n git-curl-compat: remove check for curl 7.25.0\n git-curl-compat: remove check for curl 7.34.0\n git-curl-compat: remove check for curl 7.39.0\n git-curl-compat: remove check for curl 7.43.0\n git-curl-compat: remove check for curl 7.44.0\n git-curl-compat: remove check for curl 7.52.0\n git-curl-compat: remove check for curl 7.53.0\n git-curl-compat: remove check for curl 7.56.0\n INSTALL: document requirement for libcurl 7.61.0\n Require Perl 5.26.0\n INSTALL: require Perl 5.26.0\n gitweb: make use of s///r\n\n INSTALL | 13 +---\n contrib/diff-highlight/DiffHighlight.pm | 2 +-\n contrib/mw-to-git/Git/Mediawiki.pm | 2 +-\n git-archimport.perl | 2 +-\n git-curl-compat.h | 98 -------------------------\n git-cvsexportcommit.perl | 2 +-\n git-cvsimport.perl | 2 +-\n git-cvsserver.perl | 2 +-\n git-send-email.perl | 2 +-\n git-svn.perl | 2 +-\n gitweb/gitweb.perl | 6 +-\n http.c | 58 ---------------\n imap-send.c | 4 -\n perl/Git.pm | 2 +-\n perl/Git/I18N.pm | 2 +-\n perl/Git/LoadCPAN.pm | 2 +-\n perl/Git/Packet.pm | 2 +-\n t/t0202/test.pl | 2 +-\n t/t5562/invoke-with-content-length.pl | 2 +-\n t/t9700/test.pl | 2 +-\n t/test-terminal.perl | 2 +-\n 21 files changed, 23 insertions(+), 188 deletions(-)\n\n"},{"id":"504761","messageId":"20241010235621.738239-3-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH 02/13] git-curl-compat: remove check for curl 7.25.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:10Z","receivedAt":"2024-10-10T23:56:34Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.25.0 was released in March 2012, which is well over ten years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 8, RHEL 7, and Ubuntu 12.10, all of which are\nout of mainstream security support, have all supported a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 8 --------\n http.c | 24 ------------------------\n 2 files changed, 32 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex c24ed686c1..9100af027f 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,14 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURLOPT_TCP_KEEPALIVE was added in 7.25.0, released in March 2012.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x071900\n-#define GITCURL_HAVE_CURLOPT_TCP_KEEPALIVE 1\n-#endif\n-\n-\n /**\n * CURLOPT_LOGIN_OPTIONS was added in 7.34.0, released in December\n * 2013.\ndiff --git a/http.c b/http.c\nindex d59e59f66b..633bbf74ee 100644\n--- a/http.c\n+++ b/http.c\n@@ -716,35 +716,11 @@ static int has_proxy_cert_password(void)\n }\n #endif\n \n-#ifdef GITCURL_HAVE_CURLOPT_TCP_KEEPALIVE\n static void set_curl_keepalive(CURL *c)\n {\n \tcurl_easy_setopt(c, CURLOPT_TCP_KEEPALIVE, 1);\n }\n \n-#else\n-static int sockopt_callback(void *client, curl_socket_t fd, curlsocktype type)\n-{\n-\tint ka = 1;\n-\tint rc;\n-\tsocklen_t len = (socklen_t)sizeof(ka);\n-\n-\tif (type != CURLSOCKTYPE_IPCXN)\n-\t\treturn 0;\n-\n-\trc = setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, (void *)&ka, len);\n-\tif (rc < 0)\n-\t\twarning_errno(\"unable to set SO_KEEPALIVE on socket\");\n-\n-\treturn CURL_SOCKOPT_OK;\n-}\n-\n-static void set_curl_keepalive(CURL *c)\n-{\n-\tcurl_easy_setopt(c, CURLOPT_SOCKOPTFUNCTION, sockopt_callback);\n-}\n-#endif\n-\n /* Return 1 if redactions have been made, 0 otherwise. */\n static int redact_sensitive_header(struct strbuf *header, size_t offset)\n {\n"},{"id":"504762","messageId":"20241010235621.738239-4-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH 03/13] git-curl-compat: remove check for curl 7.34.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:11Z","receivedAt":"2024-10-10T23:56:34Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.34.0 was released in December 2013, which is well over ten\nyears ago, and no major operating system vendor is still providing\nsecurity support for it. Debian 8 and Ubuntu 14.04, both of which are\nout of mainstream security support, have supported a newer version, and\nRHEL 8, which is still in support, also has a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 22 ----------------------\n http.c | 2 --\n imap-send.c | 4 ----\n 3 files changed, 28 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex 9100af027f..21306fa88f 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,28 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURLOPT_LOGIN_OPTIONS was added in 7.34.0, released in December\n- * 2013.\n- *\n- * If we start requiring 7.34.0 we might also be able to remove the\n- * code conditional on USE_CURL_FOR_IMAP_SEND in imap-send.c, see\n- * 1e16b255b95 (git-imap-send: use libcurl for implementation,\n- * 2014-11-09) and the check it added for \"072200\" in the Makefile.\n-\n- */\n-#if LIBCURL_VERSION_NUM >= 0x072200\n-#define GIT_CURL_HAVE_CURLOPT_LOGIN_OPTIONS 1\n-#endif\n-\n-/**\n- * CURL_SSLVERSION_TLSv1_[012] was added in 7.34.0, released in\n- * December 2013.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x072200\n-#define GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_0\n-#endif\n-\n /**\n * CURLOPT_PINNEDPUBLICKEY was added in 7.39.0, released in November\n * 2014. CURLE_SSL_PINNEDPUBKEYNOTMATCH was added in that same version.\ndiff --git a/http.c b/http.c\nindex 633bbf74ee..ac4b98baa0 100644\n--- a/http.c\n+++ b/http.c\n@@ -52,11 +52,9 @@ static struct {\n \t{ \"sslv2\", CURL_SSLVERSION_SSLv2 },\n \t{ \"sslv3\", CURL_SSLVERSION_SSLv3 },\n \t{ \"tlsv1\", CURL_SSLVERSION_TLSv1 },\n-#ifdef GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_0\n \t{ \"tlsv1.0\", CURL_SSLVERSION_TLSv1_0 },\n \t{ \"tlsv1.1\", CURL_SSLVERSION_TLSv1_1 },\n \t{ \"tlsv1.2\", CURL_SSLVERSION_TLSv1_2 },\n-#endif\n #ifdef GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_3\n \t{ \"tlsv1.3\", CURL_SSLVERSION_TLSv1_3 },\n #endif\ndiff --git a/imap-send.c b/imap-send.c\nindex ec68a06687..954cc9be65 100644\n--- a/imap-send.c\n+++ b/imap-send.c\n@@ -1417,15 +1417,11 @@ static CURL *setup_curl(struct imap_server_conf *srvc, struct credential *cred)\n \tcurl_easy_setopt(curl, CURLOPT_PORT, srvc->port);\n \n \tif (srvc->auth_method) {\n-#ifndef GIT_CURL_HAVE_CURLOPT_LOGIN_OPTIONS\n-\t\twarning(\"No LOGIN_OPTIONS support in this cURL version\");\n-#else\n \t\tstruct strbuf auth = STRBUF_INIT;\n \t\tstrbuf_addstr(&auth, \"AUTH=\");\n \t\tstrbuf_addstr(&auth, srvc->auth_method);\n \t\tcurl_easy_setopt(curl, CURLOPT_LOGIN_OPTIONS, auth.buf);\n \t\tstrbuf_release(&auth);\n-#endif\n \t}\n \n \tif (!srvc->use_ssl)\n"},{"id":"504766","messageId":"20241010235621.738239-5-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH 04/13] git-curl-compat: remove check for curl 7.39.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:12Z","receivedAt":"2024-10-10T23:56:34Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.39.0 was released in November 2014, which is almost ten years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 9 and Ubuntu 16.04, both of which are out of\nmainstream security support, have supported a newer version, and RHEL 8,\nwhich is still in support, also has a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 9 ---------\n http.c | 11 -----------\n 2 files changed, 20 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex 21306fa88f..b301ef154c 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,15 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURLOPT_PINNEDPUBLICKEY was added in 7.39.0, released in November\n- * 2014. CURLE_SSL_PINNEDPUBKEYNOTMATCH was added in that same version.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x072c00\n-#define GIT_CURL_HAVE_CURLOPT_PINNEDPUBLICKEY 1\n-#define GIT_CURL_HAVE_CURLE_SSL_PINNEDPUBKEYNOTMATCH 1\n-#endif\n-\n /**\n * CURL_HTTP_VERSION_2 was added in 7.43.0, released in June 2015.\n *\ndiff --git a/http.c b/http.c\nindex ac4b98baa0..cdef059090 100644\n--- a/http.c\n+++ b/http.c\n@@ -63,9 +63,7 @@ static char *ssl_key;\n static char *ssl_key_type;\n static char *ssl_capath;\n static char *curl_no_proxy;\n-#ifdef GIT_CURL_HAVE_CURLOPT_PINNEDPUBLICKEY\n static char *ssl_pinnedkey;\n-#endif\n static char *ssl_cainfo;\n static long curl_low_speed_limit = -1;\n static long curl_low_speed_time = -1;\n@@ -509,12 +507,7 @@ static int http_options(const char *var, const char *value,\n \t}\n \n \tif (!strcmp(\"http.pinnedpubkey\", var)) {\n-#ifdef GIT_CURL_HAVE_CURLOPT_PINNEDPUBLICKEY\n \t\treturn git_config_pathname(&ssl_pinnedkey, var, value);\n-#else\n-\t\twarning(_(\"Public key pinning not supported with cURL < 7.39.0\"));\n-\t\treturn 0;\n-#endif\n \t}\n \n \tif (!strcmp(\"http.extraheader\", var)) {\n@@ -1104,10 +1097,8 @@ static CURL *get_curl_handle(void)\n \t\tcurl_easy_setopt(result, CURLOPT_SSLKEYTYPE, ssl_key_type);\n \tif (ssl_capath)\n \t\tcurl_easy_setopt(result, CURLOPT_CAPATH, ssl_capath);\n-#ifdef GIT_CURL_HAVE_CURLOPT_PINNEDPUBLICKEY\n \tif (ssl_pinnedkey)\n \t\tcurl_easy_setopt(result, CURLOPT_PINNEDPUBLICKEY, ssl_pinnedkey);\n-#endif\n \tif (http_ssl_backend && !strcmp(\"schannel\", http_ssl_backend) &&\n \t !http_schannel_use_ssl_cainfo) {\n \t\tcurl_easy_setopt(result, CURLOPT_CAINFO, NULL);\n@@ -1825,10 +1816,8 @@ static int handle_curl_result(struct slot_results *results)\n \t\t */\n \t\tcredential_reject(&cert_auth);\n \t\treturn HTTP_NOAUTH;\n-#ifdef GIT_CURL_HAVE_CURLE_SSL_PINNEDPUBKEYNOTMATCH\n \t} else if (results->curl_result == CURLE_SSL_PINNEDPUBKEYNOTMATCH) {\n \t\treturn HTTP_NOMATCHPUBLICKEY;\n-#endif\n \t} else if (missing_target(results))\n \t\treturn HTTP_MISSING_TARGET;\n \telse if (results->http_code == 401) {\n"},{"id":"504763","messageId":"20241010235621.738239-6-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH 05/13] git-curl-compat: remove check for curl 7.43.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:13Z","receivedAt":"2024-10-10T23:56:37Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.43.0 was released in June 2015, which is over nine years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 9 and Ubuntu 16.04, both of which are out of\nmainstream security support, have supported a newer version, and RHEL 8,\nwhich is still in support, also has a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 11 -----------\n http.c | 5 -----\n 2 files changed, 16 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex b301ef154c..cd970e34d6 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,17 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURL_HTTP_VERSION_2 was added in 7.43.0, released in June 2015.\n- *\n- * The CURL_HTTP_VERSION_2 alias (but not CURL_HTTP_VERSION_2_0) has\n- * always been a macro, not an enum field (checked on curl version\n- * 7.78.0)\n- */\n-#if LIBCURL_VERSION_NUM >= 0x072b00\n-#define GIT_CURL_HAVE_CURL_HTTP_VERSION_2 1\n-#endif\n-\n /**\n * CURLSSLOPT_NO_REVOKE was added in 7.44.0, released in August 2015.\n *\ndiff --git a/http.c b/http.c\nindex cdef059090..945df9a628 100644\n--- a/http.c\n+++ b/http.c\n@@ -980,7 +980,6 @@ static long get_curl_allowed_protocols(int from_user, struct strbuf *list)\n \treturn bits;\n }\n \n-#ifdef GIT_CURL_HAVE_CURL_HTTP_VERSION_2\n static int get_curl_http_version_opt(const char *version_string, long *opt)\n {\n \tint i;\n@@ -1003,8 +1002,6 @@ static int get_curl_http_version_opt(const char *version_string, long *opt)\n \treturn -1; /* not found */\n }\n \n-#endif\n-\n static CURL *get_curl_handle(void)\n {\n \tCURL *result = curl_easy_init();\n@@ -1022,7 +1019,6 @@ static CURL *get_curl_handle(void)\n \t\tcurl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, 2);\n \t}\n \n-#ifdef GIT_CURL_HAVE_CURL_HTTP_VERSION_2\n if (curl_http_version) {\n \t\tlong opt;\n \t\tif (!get_curl_http_version_opt(curl_http_version, &opt)) {\n@@ -1030,7 +1026,6 @@ static CURL *get_curl_handle(void)\n \t\t\tcurl_easy_setopt(result, CURLOPT_HTTP_VERSION, opt);\n \t\t}\n }\n-#endif\n \n \tcurl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);\n \tcurl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);\n"},{"id":"504764","messageId":"20241010235621.738239-7-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH 06/13] git-curl-compat: remove check for curl 7.44.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:14Z","receivedAt":"2024-10-10T23:56:37Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.44.0 was released in August 2015, which is over nine years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 9 and Ubuntu 16.04, both of which are out of\nmainstream security support, have supported a newer version, and RHEL 8,\nwhich is still in support, also has a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 10 ----------\n http.c | 4 ----\n 2 files changed, 14 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex cd970e34d6..6b05d70d42 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,16 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURLSSLOPT_NO_REVOKE was added in 7.44.0, released in August 2015.\n- *\n- * The CURLSSLOPT_NO_REVOKE is, has always been a macro, not an enum\n- * field (checked on curl version 7.78.0)\n- */\n-#if LIBCURL_VERSION_NUM >= 0x072c00\n-#define GIT_CURL_HAVE_CURLSSLOPT_NO_REVOKE 1\n-#endif\n-\n /**\n * CURLOPT_PROXY_CAINFO was added in 7.52.0, released in August 2017.\n */\ndiff --git a/http.c b/http.c\nindex 945df9a628..bdf8bf7b59 100644\n--- a/http.c\n+++ b/http.c\n@@ -1048,11 +1048,7 @@ static CURL *get_curl_handle(void)\n \n \tif (http_ssl_backend && !strcmp(\"schannel\", http_ssl_backend) &&\n \t !http_schannel_check_revoke) {\n-#ifdef GIT_CURL_HAVE_CURLSSLOPT_NO_REVOKE\n \t\tcurl_easy_setopt(result, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE);\n-#else\n-\t\twarning(_(\"CURLSSLOPT_NO_REVOKE not supported with cURL < 7.44.0\"));\n-#endif\n \t}\n \n \tif (http_proactive_auth != PROACTIVE_AUTH_NONE)\n"},{"id":"504765","messageId":"20241010235621.738239-8-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH 07/13] git-curl-compat: remove check for curl 7.52.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:15Z","receivedAt":"2024-10-10T23:56:38Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.52.0 was released in August 2017, which is over seven years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 9 and Ubuntu 18.04, both of which are out of\nmainstream security support, have supported a newer version, and RHEL 8,\nwhich is still in support, also has a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 15 ---------------\n http.c | 8 --------\n 2 files changed, 23 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex 6b05d70d42..edee8f2ba0 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,21 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURLOPT_PROXY_CAINFO was added in 7.52.0, released in August 2017.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x073400\n-#define GIT_CURL_HAVE_CURLOPT_PROXY_CAINFO 1\n-#endif\n-\n-/**\n- * CURLOPT_PROXY_{KEYPASSWD,SSLCERT,SSLKEY} was added in 7.52.0,\n- * released in August 2017.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x073400\n-#define GIT_CURL_HAVE_CURLOPT_PROXY_KEYPASSWD 1\n-#endif\n-\n /**\n * CURL_SSLVERSION_TLSv1_3 was added in 7.53.0, released in February\n * 2017.\ndiff --git a/http.c b/http.c\nindex bdf8bf7b59..24764f1272 100644\n--- a/http.c\n+++ b/http.c\n@@ -691,7 +691,6 @@ static int has_cert_password(void)\n \treturn 1;\n }\n \n-#ifdef GIT_CURL_HAVE_CURLOPT_PROXY_KEYPASSWD\n static int has_proxy_cert_password(void)\n {\n \tif (http_proxy_ssl_cert == NULL || proxy_ssl_cert_password_required != 1)\n@@ -705,7 +704,6 @@ static int has_proxy_cert_password(void)\n \t}\n \treturn 1;\n }\n-#endif\n \n static void set_curl_keepalive(CURL *c)\n {\n@@ -1093,16 +1091,12 @@ static CURL *get_curl_handle(void)\n \tif (http_ssl_backend && !strcmp(\"schannel\", http_ssl_backend) &&\n \t !http_schannel_use_ssl_cainfo) {\n \t\tcurl_easy_setopt(result, CURLOPT_CAINFO, NULL);\n-#ifdef GIT_CURL_HAVE_CURLOPT_PROXY_CAINFO\n \t\tcurl_easy_setopt(result, CURLOPT_PROXY_CAINFO, NULL);\n-#endif\n \t} else if (ssl_cainfo != NULL || http_proxy_ssl_ca_info != NULL) {\n \t\tif (ssl_cainfo)\n \t\t\tcurl_easy_setopt(result, CURLOPT_CAINFO, ssl_cainfo);\n-#ifdef GIT_CURL_HAVE_CURLOPT_PROXY_CAINFO\n \t\tif (http_proxy_ssl_ca_info)\n \t\t\tcurl_easy_setopt(result, CURLOPT_PROXY_CAINFO, http_proxy_ssl_ca_info);\n-#endif\n \t}\n \n \tif (curl_low_speed_limit > 0 && curl_low_speed_time > 0) {\n@@ -1198,7 +1192,6 @@ static CURL *get_curl_handle(void)\n \t\telse if (starts_with(curl_http_proxy, \"socks\"))\n \t\t\tcurl_easy_setopt(result,\n \t\t\t\tCURLOPT_PROXYTYPE, CURLPROXY_SOCKS4);\n-#ifdef GIT_CURL_HAVE_CURLOPT_PROXY_KEYPASSWD\n \t\telse if (starts_with(curl_http_proxy, \"https\")) {\n \t\t\tcurl_easy_setopt(result, CURLOPT_PROXYTYPE, CURLPROXY_HTTPS);\n \n@@ -1211,7 +1204,6 @@ static CURL *get_curl_handle(void)\n \t\t\tif (has_proxy_cert_password())\n \t\t\t\tcurl_easy_setopt(result, CURLOPT_PROXY_KEYPASSWD, proxy_cert_auth.password);\n \t\t}\n-#endif\n \t\tif (strstr(curl_http_proxy, \"://\"))\n \t\t\tcredential_from_url(&proxy_auth, curl_http_proxy);\n \t\telse {\n"},{"id":"504767","messageId":"20241010235621.738239-10-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH 09/13] git-curl-compat: remove check for curl 7.56.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:17Z","receivedAt":"2024-10-10T23:56:38Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.56.0 was released in September 2017, which is over seven years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 10, which is out of mainstream security support,\nhas supported a newer version, and Ubuntu 20.04 and RHEL 8, which are\nstill in support, also have a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 8 --------\n http.c | 2 --\n 2 files changed, 10 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex 65ba1ee0f8..703756ba85 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,14 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURLSSLSET_{NO_BACKENDS,OK,TOO_LATE,UNKNOWN_BACKEND} were added in\n- * 7.56.0, released in September 2017.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x073800\n-#define GIT_CURL_HAVE_CURLSSLSET_NO_BACKENDS\n-#endif\n-\n /**\n * Versions before curl 7.66.0 (September 2019) required manually setting the\n * transfer-encoding for a streaming POST; after that this is handled\ndiff --git a/http.c b/http.c\nindex c5fdf1cd4c..4d59f11ad2 100644\n--- a/http.c\n+++ b/http.c\n@@ -1275,7 +1275,6 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)\n \tfree(normalized_url);\n \tstring_list_clear(&config.vars, 1);\n \n-#ifdef GIT_CURL_HAVE_CURLSSLSET_NO_BACKENDS\n \tif (http_ssl_backend) {\n \t\tconst curl_ssl_backend **backends;\n \t\tstruct strbuf buf = STRBUF_INIT;\n@@ -1300,7 +1299,6 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)\n \t\t\tbreak; /* Okay! */\n \t\t}\n \t}\n-#endif\n \n \tif (curl_global_init(CURL_GLOBAL_ALL) != CURLE_OK)\n \t\tdie(\"curl_global_init failed\");\n"},{"id":"504768","messageId":"20241010235621.738239-11-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH 10/13] INSTALL: document requirement for libcurl 7.61.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:18Z","receivedAt":"2024-10-10T23:56:38Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Our platform support policy states that we require \"versions of\ndependencies which are generally accepted as stable and supportable,\ne.g., in line with the version used by other long-term-support\ndistributions\". Of Debian, Ubuntu, and RHEL, the three most common\ndistributions that provide LTS versions, the version with mainstream\nlong-term security support with the oldest libcurl is 7.61.0 in RHEL 8.\n\nUpdate the documentation to state that this is the new base version for\nlibcurl. Remove text that is no longer applicable to older versions.\n\nSigned-off-by: brian m. carlson \n---\n INSTALL | 11 +++--------\n 1 file changed, 3 insertions(+), 8 deletions(-)\n\ndiff --git a/INSTALL b/INSTALL\nindex 2a46d04592..6e0321ff0e 100644\n--- a/INSTALL\n+++ b/INSTALL\n@@ -129,17 +129,12 @@ Issues of note:\n \t itself, e.g. Digest::MD5, File::Spec, File::Temp, Net::Domain,\n \t Net::SMTP, and Time::HiRes.\n \n-\t- git-imap-send needs the OpenSSL library to talk IMAP over SSL if\n-\t you are using libcurl older than 7.34.0. Otherwise you can use\n-\t NO_OPENSSL without losing git-imap-send.\n-\n \t- \"libcurl\" library is used for fetching and pushing\n \t repositories over http:// or https://, as well as by\n-\t git-imap-send if the curl version is >= 7.34.0. If you do\n-\t not need that functionality, use NO_CURL to build without\n-\t it.\n+\t git-imap-send. If you do not need that functionality,\n+\t use NO_CURL to build without it.\n \n-\t Git requires version \"7.21.3\" or later of \"libcurl\" to build\n+\t Git requires version \"7.61.0\" or later of \"libcurl\" to build\n \t without NO_CURL. This version requirement may be bumped in\n \t the future.\n \n"},{"id":"504769","messageId":"20241010235621.738239-13-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH 12/13] INSTALL: require Perl 5.26.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:20Z","receivedAt":"2024-10-10T23:56:38Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Our platform support policy states that we require \"versions of\ndependencies which are generally accepted as stable and supportable,\ne.g., in line with the version used by other long-term-support\ndistributions\". Of Debian, Ubuntu, RHEL, and SLES, the four most common\ndistributions that provide LTS versions, the version with mainstream\nlong-term security support with the oldest Perl is 5.26.0 in SLES 15.6.\n\nThis is a major upgrade, since Perl 5.8.1, according to the Perl\ndocumentation, was released in September of 2003. It brings a lot of\nnew features that we can choose to use, such as s///r to return the\nmodified string, the postderef functionality, and subroutine signatures,\nalthough the latter was still considered experimental until 5.36.\n\nUpdate the INSTALL file to reflect our new dependency requirement.\n\nSigned-off-by: brian m. carlson \n---\n INSTALL | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/INSTALL b/INSTALL\nindex 6e0321ff0e..54d7528f9e 100644\n--- a/INSTALL\n+++ b/INSTALL\n@@ -119,7 +119,7 @@ Issues of note:\n \t- A POSIX-compliant shell is required to run some scripts needed\n \t for everyday use (e.g. \"bisect\", \"request-pull\").\n \n-\t- \"Perl\" version 5.8.1 or later is needed to use some of the\n+\t- \"Perl\" version 5.26.0 or later is needed to use some of the\n \t features (e.g. sending patches using \"git send-email\",\n \t interacting with svn repositories with \"git svn\"). If you can\n \t live without these, use NO_PERL. Note that recent releases of\n"},{"id":"504770","messageId":"20241010235621.738239-12-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH 11/13] Require Perl 5.26.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:19Z","receivedAt":"2024-10-10T23:56:38Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Our platform support policy states that we require \"versions of\ndependencies which are generally accepted as stable and supportable,\ne.g., in line with the version used by other long-term-support\ndistributions\". Of Debian, Ubuntu, RHEL, and SLES, the four most common\ndistributions that provide LTS versions, the version with mainstream\nlong-term security support with the oldest Perl is 5.26.0 in SLES 15.6.\n\nThis is a major upgrade, since Perl 5.8.1, according to the Perl\ndocumentation, was released in September of 2003. It brings a lot of\nnew features that we can choose to use, such as s///r to return the\nmodified string, the postderef functionality, and subroutine signatures,\nalthough the latter was still considered experimental until 5.36.\n\nThis change was made with the following one-liner, which intentionally\nexcludes modifying the vendored modules we include to avoid conflicts:\n\n git grep -l 'use 5.008001' | grep -v 'LoadCPAN/' | xargs perl -pi -e 's/use 5.008001/use 5.026000/'\n\nSigned-off-by: brian m. carlson \n---\n contrib/diff-highlight/DiffHighlight.pm | 2 +-\n contrib/mw-to-git/Git/Mediawiki.pm | 2 +-\n git-archimport.perl | 2 +-\n git-cvsexportcommit.perl | 2 +-\n git-cvsimport.perl | 2 +-\n git-cvsserver.perl | 2 +-\n git-send-email.perl | 2 +-\n git-svn.perl | 2 +-\n gitweb/gitweb.perl | 2 +-\n perl/Git.pm | 2 +-\n perl/Git/I18N.pm | 2 +-\n perl/Git/LoadCPAN.pm | 2 +-\n perl/Git/Packet.pm | 2 +-\n t/t0202/test.pl | 2 +-\n t/t5562/invoke-with-content-length.pl | 2 +-\n t/t9700/test.pl | 2 +-\n t/test-terminal.perl | 2 +-\n 17 files changed, 17 insertions(+), 17 deletions(-)\n\ndiff --git a/contrib/diff-highlight/DiffHighlight.pm b/contrib/diff-highlight/DiffHighlight.pm\nindex 636add6968..15be2a49a2 100644\n--- a/contrib/diff-highlight/DiffHighlight.pm\n+++ b/contrib/diff-highlight/DiffHighlight.pm\n@@ -1,6 +1,6 @@\n package DiffHighlight;\n \n-use 5.008001;\n+use 5.026000;\n use warnings FATAL => 'all';\n use strict;\n \ndiff --git a/contrib/mw-to-git/Git/Mediawiki.pm b/contrib/mw-to-git/Git/Mediawiki.pm\nindex ff7811225e..0c0df63d54 100644\n--- a/contrib/mw-to-git/Git/Mediawiki.pm\n+++ b/contrib/mw-to-git/Git/Mediawiki.pm\n@@ -1,6 +1,6 @@\n package Git::Mediawiki;\n \n-use 5.008001;\n+use 5.026000;\n use strict;\n use POSIX;\n use Git;\ndiff --git a/git-archimport.perl b/git-archimport.perl\nindex f5a317b899..0a1e08f6c3 100755\n--- a/git-archimport.perl\n+++ b/git-archimport.perl\n@@ -54,7 +54,7 @@ =head1 Devel Notes\n \n =cut\n \n-use 5.008001;\n+use 5.026000;\n use strict;\n use warnings;\n use Getopt::Std;\ndiff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl\nindex 1e03ba94d1..c4fbb4bef3 100755\n--- a/git-cvsexportcommit.perl\n+++ b/git-cvsexportcommit.perl\n@@ -1,6 +1,6 @@\n #!/usr/bin/perl\n \n-use 5.008001;\n+use 5.026000;\n use strict;\n use warnings;\n use Getopt::Std;\ndiff --git a/git-cvsimport.perl b/git-cvsimport.perl\nindex 211ec8459a..d7229679cf 100755\n--- a/git-cvsimport.perl\n+++ b/git-cvsimport.perl\n@@ -13,7 +13,7 @@\n # The head revision is on branch \"origin\" by default.\n # You can change that with the '-o' option.\n \n-use 5.008001;\n+use 5.026000;\n use strict;\n use warnings;\n use Getopt::Long;\ndiff --git a/git-cvsserver.perl b/git-cvsserver.perl\nindex 124f598bdc..145e12cb3e 100755\n--- a/git-cvsserver.perl\n+++ b/git-cvsserver.perl\n@@ -15,7 +15,7 @@\n ####\n ####\n \n-use 5.008001;\n+use 5.026000;\n use strict;\n use warnings;\n use bytes;\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex c835d4c11a..166d6635bc 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -16,7 +16,7 @@\n # and second line is the subject of the message.\n #\n \n-use 5.008001;\n+use 5.026000;\n use strict;\n use warnings $ENV{GIT_PERL_FATAL_WARNINGS} ? qw(FATAL all) : ();\n use Getopt::Long;\ndiff --git a/git-svn.perl b/git-svn.perl\nindex 01e7a70de1..d1e969feb9 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -1,7 +1,7 @@\n #!/usr/bin/perl\n # Copyright (C) 2006, Eric Wong \n # License: GPL v2 or later\n-use 5.008001;\n+use 5.026000;\n use warnings $ENV{GIT_PERL_FATAL_WARNINGS} ? qw(FATAL all) : ();\n use strict;\n use vars qw/\t$AUTHOR $VERSION\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex b09a8d0523..c4f92386eb 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -7,7 +7,7 @@\n #\n # This program is licensed under the GPLv2\n \n-use 5.008001;\n+use 5.026000;\n use strict;\n use warnings;\n # handle ACL in file access tests\ndiff --git a/perl/Git.pm b/perl/Git.pm\nindex 667152c6c6..b6312e6156 100644\n--- a/perl/Git.pm\n+++ b/perl/Git.pm\n@@ -7,7 +7,7 @@ =head1 NAME\n \n package Git;\n \n-use 5.008001;\n+use 5.026000;\n use strict;\n use warnings $ENV{GIT_PERL_FATAL_WARNINGS} ? qw(FATAL all) : ();\n \ndiff --git a/perl/Git/I18N.pm b/perl/Git/I18N.pm\nindex 475e90a6df..cdffe19a59 100644\n--- a/perl/Git/I18N.pm\n+++ b/perl/Git/I18N.pm\n@@ -1,5 +1,5 @@\n package Git::I18N;\n-use 5.008001;\n+use 5.026000;\n use strict;\n use warnings $ENV{GIT_PERL_FATAL_WARNINGS} ? qw(FATAL all) : ();\n BEGIN {\ndiff --git a/perl/Git/LoadCPAN.pm b/perl/Git/LoadCPAN.pm\nindex 8c7fa805f9..c2bbcdc957 100644\n--- a/perl/Git/LoadCPAN.pm\n+++ b/perl/Git/LoadCPAN.pm\n@@ -1,5 +1,5 @@\n package Git::LoadCPAN;\n-use 5.008001;\n+use 5.026000;\n use strict;\n use warnings $ENV{GIT_PERL_FATAL_WARNINGS} ? qw(FATAL all) : ();\n \ndiff --git a/perl/Git/Packet.pm b/perl/Git/Packet.pm\nindex d896e69523..9ffe3a17c5 100644\n--- a/perl/Git/Packet.pm\n+++ b/perl/Git/Packet.pm\n@@ -1,5 +1,5 @@\n package Git::Packet;\n-use 5.008001;\n+use 5.026000;\n use strict;\n use warnings $ENV{GIT_PERL_FATAL_WARNINGS} ? qw(FATAL all) : ();\n BEGIN {\ndiff --git a/t/t0202/test.pl b/t/t0202/test.pl\nindex 47d96a2a13..853f3ddc47 100755\n--- a/t/t0202/test.pl\n+++ b/t/t0202/test.pl\n@@ -1,5 +1,5 @@\n #!/usr/bin/perl\n-use 5.008001;\n+use 5.026000;\n use lib (split(/:/, $ENV{GITPERLLIB}));\n use strict;\n use warnings;\ndiff --git a/t/t5562/invoke-with-content-length.pl b/t/t5562/invoke-with-content-length.pl\nindex 9babb9a375..ef9671ca51 100644\n--- a/t/t5562/invoke-with-content-length.pl\n+++ b/t/t5562/invoke-with-content-length.pl\n@@ -1,4 +1,4 @@\n-use 5.008001;\n+use 5.026000;\n use strict;\n use warnings;\n \ndiff --git a/t/t9700/test.pl b/t/t9700/test.pl\nindex 2e1d50d4d1..7572c638bf 100755\n--- a/t/t9700/test.pl\n+++ b/t/t9700/test.pl\n@@ -1,7 +1,7 @@\n #!/usr/bin/perl\n use lib (split(/:/, $ENV{GITPERLLIB}));\n \n-use 5.008001;\n+use 5.026000;\n use warnings;\n use strict;\n \ndiff --git a/t/test-terminal.perl b/t/test-terminal.perl\nindex b8fd6a4f13..77e79db553 100755\n--- a/t/test-terminal.perl\n+++ b/t/test-terminal.perl\n@@ -1,5 +1,5 @@\n #!/usr/bin/perl\n-use 5.008001;\n+use 5.026000;\n use strict;\n use warnings;\n use IO::Pty;\n"},{"id":"504771","messageId":"20241010235621.738239-9-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH 08/13] git-curl-compat: remove check for curl 7.53.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:16Z","receivedAt":"2024-10-10T23:56:38Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.53.0 was released in February 2017, which is over seven years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 10 and Ubuntu 18.04, both of which are out of\nmainstream security support, have supported a newer version, and RHEL 8,\nwhich is still in support, also has a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 8 --------\n http.c | 2 --\n 2 files changed, 10 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex edee8f2ba0..65ba1ee0f8 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,14 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURL_SSLVERSION_TLSv1_3 was added in 7.53.0, released in February\n- * 2017.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x073400\n-#define GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_3 1\n-#endif\n-\n /**\n * CURLSSLSET_{NO_BACKENDS,OK,TOO_LATE,UNKNOWN_BACKEND} were added in\n * 7.56.0, released in September 2017.\ndiff --git a/http.c b/http.c\nindex 24764f1272..c5fdf1cd4c 100644\n--- a/http.c\n+++ b/http.c\n@@ -55,9 +55,7 @@ static struct {\n \t{ \"tlsv1.0\", CURL_SSLVERSION_TLSv1_0 },\n \t{ \"tlsv1.1\", CURL_SSLVERSION_TLSv1_1 },\n \t{ \"tlsv1.2\", CURL_SSLVERSION_TLSv1_2 },\n-#ifdef GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_3\n \t{ \"tlsv1.3\", CURL_SSLVERSION_TLSv1_3 },\n-#endif\n };\n static char *ssl_key;\n static char *ssl_key_type;\n"},{"id":"504772","messageId":"20241010235621.738239-14-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH 13/13] gitweb: make use of s///r","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-10T23:56:21Z","receivedAt":"2024-10-10T23:56:39Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"In Perl 5.14, released in May 2011, the r modifier was added to the s///\noperator to allow it to return the modified string instead of modifying\nthe string in place. This allows to write nicer, more succinct code in\nseveral cases, so let's do that here.\n\nSigned-off-by: brian m. carlson \n---\n gitweb/gitweb.perl | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex c4f92386eb..f0d8fac7ba 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -1188,7 +1188,7 @@ sub evaluate_and_validate_params {\n \t\tif ($search_use_regexp) {\n \t\t\t$search_regexp = $searchtext;\n \t\t\tif (!eval { qr/$search_regexp/; 1; }) {\n-\t\t\t\t(my $error = $@) =~ s/ at \\S+ line \\d+.*\\n?//;\n+\t\t\t\tmy $error = $@ =~ s/ at \\S+ line \\d+.*\\n?//r;\n \t\t\t\tdie_error(400, \"Invalid search regexp '$search_regexp'\",\n \t\t\t\t esc_html($error));\n \t\t\t}\n@@ -2700,7 +2700,7 @@ sub git_cmd {\n # Try to avoid using this function wherever possible.\n sub quote_command {\n \treturn join(' ',\n-\t\tmap { my $a = $_; $a =~ s/(['!])/'\\\\$1'/g; \"'$a'\" } @_ );\n+\t\tmap { my $a = $_ =~ s/(['!])/'\\\\$1'/gr; \"'$a'\" } @_ );\n }\n \n # get HEAD ref of given project as hash\n"},{"id":"504802","messageId":"ZwjKTJye2OmQClSW@pks.im","threadId":"62308","inReplyTo":"20241010235621.738239-10-sandals@crustytoothpaste.net","subject":"Re: [PATCH 09/13] git-curl-compat: remove check for curl 7.56.0","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-10-11T06:48:51Z","receivedAt":"2024-10-11T06:48:58Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Oct 10, 2024 at 11:56:17PM +0000, brian m. carlson wrote:\n> libcurl 7.56.0 was released in September 2017, which is over seven years\n> ago, and no major operating system vendor is still providing security\n> support for it. Debian 10, which is out of mainstream security support,\n> has supported a newer version, and Ubuntu 20.04 and RHEL 8, which are\n> still in support, also have a newer version.\n> \n> Remove the check for this version and use this functionality\n> unconditionally.\n> \n> Signed-off-by: brian m. carlson \n> ---\n> git-curl-compat.h | 8 --------\n> http.c | 2 --\n> 2 files changed, 10 deletions(-)\n> \n> diff --git a/git-curl-compat.h b/git-curl-compat.h\n> index 65ba1ee0f8..703756ba85 100644\n> --- a/git-curl-compat.h\n> +++ b/git-curl-compat.h\n> @@ -28,14 +28,6 @@\n> * introduced, oldest first, in the official version of cURL library.\n> */\n> \n> -/**\n> - * CURLSSLSET_{NO_BACKENDS,OK,TOO_LATE,UNKNOWN_BACKEND} were added in\n> - * 7.56.0, released in September 2017.\n> - */\n> -#if LIBCURL_VERSION_NUM >= 0x073800\n> -#define GIT_CURL_HAVE_CURLSSLSET_NO_BACKENDS\n> -#endif\n> -\n> /**\n> * Versions before curl 7.66.0 (September 2019) required manually setting the\n> * transfer-encoding for a streaming POST; after that this is handled\n> diff --git a/http.c b/http.c\n> index c5fdf1cd4c..4d59f11ad2 100644\n> --- a/http.c\n> +++ b/http.c\n> @@ -1275,7 +1275,6 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)\n> \tfree(normalized_url);\n> \tstring_list_clear(&config.vars, 1);\n> \n> -#ifdef GIT_CURL_HAVE_CURLSSLSET_NO_BACKENDS\n> \tif (http_ssl_backend) {\n> \t\tconst curl_ssl_backend **backends;\n> \t\tstruct strbuf buf = STRBUF_INIT;\n> @@ -1300,7 +1299,6 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)\n> \t\t\tbreak; /* Okay! */\n> \t\t}\n> \t}\n> -#endif\n> \n> \tif (curl_global_init(CURL_GLOBAL_ALL) != CURLE_OK)\n> \t\tdie(\"curl_global_init failed\");\n> \n\nI wonder whether we want to have something like the below patch to give\npeople a better error message in case they have a version that is too\nold now.\n\nOther than that I agree with the sentiment of this patch series.\nSupporting ancient dependency versions that aren't used by any\nstill-supported and available distro doesn't feel sensible to me, and\nscenarios like this are why we have introduced the platform support\npolicy in the first place.\n\nPatrick\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex e1d0bdd2735..d65b5f55126 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -143,4 +143,8 @@\n #define GIT_CURL_HAVE_CURLOPT_PROTOCOLS_STR 1\n #endif\n \n+#if LIBCURL_VERSION_NUM < 0x073d00\n+# error \"Your version of curl is too old. You need to have at least curl 7.61.0\"\n+#endif\n+\n #endif\n"},{"id":"504814","messageId":"20241011073326.GB18010@coredump.intra.peff.net","threadId":"62308","inReplyTo":"ZwjKTJye2OmQClSW@pks.im","subject":"Re: [PATCH 09/13] git-curl-compat: remove check for curl 7.56.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-10-11T07:33:26Z","receivedAt":"2024-10-11T07:33:35Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 11, 2024 at 08:48:51AM +0200, Patrick Steinhardt wrote:\n\n> I wonder whether we want to have something like the below patch to give\n> people a better error message in case they have a version that is too\n> old now.\n> [...]\n> +#if LIBCURL_VERSION_NUM < 0x073d00\n> +# error \"Your version of curl is too old. You need to have at least curl 7.61.0\"\n> +#endif\n\nIIRC we ran into some interesting situations in the past where some\ndistros had older versions that had backported some features. So Git\nwould continue to compile, even though it was not technically the\nversion we said was needed. And a patch like the one above would break\nthose systems, even they'd otherwise be OK.\n\nNow possibly that is a little bit insane and not something we should\nworry about. I don't have good examples of what kinds of things got\nbackported, but searching the archive for LIBCURL_VERSION_NUM and\n\"backport\" yielded this:\n\n https://lore.kernel.org/git/4d29d43d458f61c6dabca093f591ad8698ca2ceb.1502462884.git.tgc@jupiterrise.com/\n\nand I seem to recall most of the discussion of this was around that\nauthor and RHEL/EPEL.\n\n-Peff\n"},{"id":"504815","messageId":"20241011074022.GC18010@coredump.intra.peff.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-10-11T07:40:22Z","receivedAt":"2024-10-11T07:40:23Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 10, 2024 at 11:56:08PM +0000, brian m. carlson wrote:\n\n> This series updates our requirements for libcurl to 7.61.0 (the version\n> in RHEL 8) and for Perl to 5.26.0 (the version in 15.6). I considered\n> the mainstream LTS versions of RHEL, Debian, Ubuntu, and SLES, but\n> omitted consideration of paid support extended LTS, since we cannot\n> expect Git developers to have to pay a large corporation lots of money\n> just to test functionality. This is in conformance with our policy,\n> which states that versions must be \"in line with the version used by\n> other long-term-support distributions\", which does not include extended\n> LTS distributions.\n> \n> The libcurl dependency changes come in incremental patches so that if we\n> have people on unsupported systems, they can simply revert the patches\n> that they'd like to omit. It also makes the changes easier to review\n> than one giant commit.\n\nThe libcurl changes all looked OK to me. I was a little surprised that\nwe could move to 7.61.0, which is only 6 years old, since many long-term\nreleases target 10 years. I guess the ones you looked at have had point\nreleases with updated libcurl?\n\nI don't have a strong opinion on the extended LTS issue. Like you, I\ndon't really care about dealing with paid support. OTOH, I think in many\ncases there was little to no maintenance burden for these older\nversions, since we'd already done the work to #ifdef them. But I guess\nsince you broke up the patches, they can always choose to revert or\ninclude what they want.\n\n> The Perl changes are a huge upgrade. 5.8.1, our former supported\n> version, was from 2003. 5.26 has substantially improved Unicode support\n> (including Unicode strings), s///r (to allow returning a modified value\n> instead of modifying it in place), postderef syntax (which also provides\n> better interpolation for complex expressions), and subroutine signatures\n> (although these are experimental until 5.36). These allow us much more\n> readable, modern Perl.\n\nI'm OK with a move to perl 5.26. It does feel a little weird to be\nmass-updating the \"require\" lines in stuff in contrib/ (specifically I\nnoticed diff-highlight, since I maintain it). But 5.008 is so absurdly\nold that I find it hard to believe anybody would ever notice the\ndifference.\n\n-Peff\n"},{"id":"504816","messageId":"ZwjYinN7oKSw2DIq@pks.im","threadId":"62308","inReplyTo":"20241011073326.GB18010@coredump.intra.peff.net","subject":"Re: [PATCH 09/13] git-curl-compat: remove check for curl 7.56.0","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-10-11T07:49:30Z","receivedAt":"2024-10-11T07:49:36Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Oct 11, 2024 at 03:33:26AM -0400, Jeff King wrote:\n> On Fri, Oct 11, 2024 at 08:48:51AM +0200, Patrick Steinhardt wrote:\n> \n> > I wonder whether we want to have something like the below patch to give\n> > people a better error message in case they have a version that is too\n> > old now.\n> > [...]\n> > +#if LIBCURL_VERSION_NUM < 0x073d00\n> > +# error \"Your version of curl is too old. You need to have at least curl 7.61.0\"\n> > +#endif\n> \n> IIRC we ran into some interesting situations in the past where some\n> distros had older versions that had backported some features. So Git\n> would continue to compile, even though it was not technically the\n> version we said was needed. And a patch like the one above would break\n> those systems, even they'd otherwise be OK.\n> \n> Now possibly that is a little bit insane and not something we should\n> worry about. I don't have good examples of what kinds of things got\n> backported, but searching the archive for LIBCURL_VERSION_NUM and\n> \"backport\" yielded this:\n> \n> https://lore.kernel.org/git/4d29d43d458f61c6dabca093f591ad8698ca2ceb.1502462884.git.tgc@jupiterrise.com/\n> \n> and I seem to recall most of the discussion of this was around that\n> author and RHEL/EPEL.\n\nHuh, interesting, thanks for the context! I'm not really sure whether we\nreally should worry about such weird backports all that much. But in any\ncase I'm okay with not pursuing the error.\n\nPatrick\n"},{"id":"504832","messageId":"ZwjyHl98xRs9TDQZ@ugly","threadId":"62308","inReplyTo":"20241010235621.738239-13-sandals@crustytoothpaste.net","subject":"Re: [PATCH 12/13] INSTALL: require Perl 5.26.0","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2024-10-11T09:38:38Z","receivedAt":"2024-10-11T09:38:56Z","isPatch":true,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Thu, Oct 10, 2024 at 11:56:20PM +0000, brian m. carlson wrote:\n>Update the INSTALL file to reflect our new dependency requirement.\n>\nany particular reason not to squash this into the parent commit?\ni see how the separation makes sense for the libcurl sub-series, but\nthat doesn't seem applicable here.\n\nregarding the actual `use` statements, you could make them somewhat more\nlegible by using 'v5.26' as the version number.\n\nanother aspect to consider is that the statement doesn't just specify\nthe minimal version, but also subtly changes behavior. for example, the\n`use strict;` statements become redundant.\n\ncf. https://perldoc.perl.org/functions/use#use-VERSION\n\nlastly, it would be nice to update the build systems to reflect the\nversion requirements. though the only pre-existing version check i found\nis the libcurl one in contrib/buildsystems/CMakeLists.txt.\n\n"},{"id":"504837","messageId":"20241011132308.2469679-1-asedeno@mit.edu","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"Alejandro R. Sedeño","fromEmail":"asedeno@mit.edu","sentAt":"2024-10-11T13:23:08Z","receivedAt":"2024-10-11T13:23:25Z","isPatch":true,"sender":{"key":"asedeno@mit.edu","avatar":"https://avatars.githubusercontent.com/u/28302?v=4"},"body":"On Thu, Oct 10, 2024 at 23:56:08 +0000, brian m. carlson wrote:\n> The libcurl dependency changes come in incremental patches so that if we\n> have people on unsupported systems, they can simply revert the patches\n> that they'd like to omit. It also makes the changes easier to review\n> than one giant commit.\n...\n> brian m. carlson (13):\n> git-curl-compat: remove check for curl 7.21.5\n> git-curl-compat: remove check for curl 7.25.0\n> git-curl-compat: remove check for curl 7.34.0\n\nStrictly speaking, the first three of these in the series can be\nsquashed, as support for libcurl older than 7.37.0 is already\nbroken. Reverting any subset of these patches will not achieve the\ngoal of allowing people to get back to a working build.\n\nPersonally, I'd still prefer to see support maintained, but on a more\nphilosophical level, I agree that this patch series a better course of\naction.\n\n-Alejandro\n"},{"id":"504849","messageId":"xmqqa5fah9pr.fsf@gitster.g","threadId":"62308","inReplyTo":"20241011074022.GC18010@coredump.intra.peff.net","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-10-11T16:42:56Z","receivedAt":"2024-10-11T16:42:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> The libcurl changes all looked OK to me. I was a little surprised that\n> we could move to 7.61.0, which is only 6 years old, since many long-term\n> releases target 10 years. I guess the ones you looked at have had point\n> releases with updated libcurl?\n\nLikewise for me, as 10 years was the random number floated around,\nif I remember correctly, back when we discussed the platform support\npolicy.\n\n> But 5.008 is so absurdly\n> old that I find it hard to believe anybody would ever notice the\n> difference.\n\nAnybody who find that the update from 5.008 should be to 5.10, like\nI initially did, should feel absurdly old themselves ;-)\n\n\n"},{"id":"504851","messageId":"xmqq1q0mh9gn.fsf@gitster.g","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-10-11T16:48:24Z","receivedAt":"2024-10-11T16:48:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> The final commit introduces a small but useful change that we can now\n> take advantage of with our newly updated Perl dependency as an example\n> of why this is a generally beneficial change. It can be omitted without\n> problem if it is judged to be too noisy.\n\nQuite honestly, these two changes, each of which is a one-liner, are\nso boringly trivial for being \"too noisy\". But on the other hand, I\nam not sure it demonstrates why it is a \"generally beneficial\nchange\" sufficiently well, either. The pre-s///r idiom\n\n (my $result = $orig_to_be_kept) =~ s/...//;\n\nwas concice enough that\n\n my $result = ($orig_to_be_kept =~ s/...//r);\n\ndoes not make all that much improvement. Where it shines, I would\nimagine, is to rewrite an original that did not use the idiom using\nthe 'r' modifier, but fortunately we didn't have such a code?\n\n\n"},{"id":"504852","messageId":"xmqqwmiefun1.fsf@gitster.g","threadId":"62308","inReplyTo":"ZwjYinN7oKSw2DIq@pks.im","subject":"Re: [PATCH 09/13] git-curl-compat: remove check for curl 7.56.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-10-11T16:53:54Z","receivedAt":"2024-10-11T16:53:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n>> > I wonder whether we want to have something like the below patch to give\n>> > people a better error message in case they have a version that is too\n>> > old now.\n>> > [...]\n>> > +#if LIBCURL_VERSION_NUM < 0x073d00\n>> > +# error \"Your version of curl is too old. You need to have at least curl 7.61.0\"\n>> > +#endif\n>> \n>> IIRC we ran into some interesting situations in the past where some\n>> distros had older versions that had backported some features. So Git\n>> would continue to compile, even though it was not technically the\n>> version we said was needed. And a patch like the one above would break\n>> those systems, even they'd otherwise be OK.\n>> \n>> Now possibly that is a little bit insane and not something we should\n>> worry about. I don't have good examples of what kinds of things got\n>> backported, but searching the archive for LIBCURL_VERSION_NUM and\n>> \"backport\" yielded this:\n>> \n>> https://lore.kernel.org/git/4d29d43d458f61c6dabca093f591ad8698ca2ceb.1502462884.git.tgc@jupiterrise.com/\n>> \n>> and I seem to recall most of the discussion of this was around that\n>> author and RHEL/EPEL.\n>\n> Huh, interesting, thanks for the context! I'm not really sure whether we\n> really should worry about such weird backports all that much. But in any\n> case I'm okay with not pursuing the error.\n\nYup, the runtime die() would work it around for such versions of\nlibcURL with silent backports.\n\nThe message should be made _(\"localizable\"), though.\n\nThanks.\n"},{"id":"504865","messageId":"CAPig+cRmyZhq1qtomTFP7p7XMqrCP8-u7ah8D2+yUtrL880y7g@mail.gmail.com","threadId":"62308","inReplyTo":"20241011074022.GC18010@coredump.intra.peff.net","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-10-11T18:09:14Z","receivedAt":"2024-10-11T18:09:27Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Oct 11, 2024 at 3:40 AM Jeff King wrote:\n> On Thu, Oct 10, 2024 at 11:56:08PM +0000, brian m. carlson wrote:\n> > This series updates our requirements for libcurl to 7.61.0 (the version\n> > in RHEL 8) and for Perl to 5.26.0 (the version in 15.6). I considered\n> > the mainstream LTS versions of RHEL, Debian, Ubuntu, and SLES, but\n> > omitted consideration of paid support extended LTS, since we cannot\n> > expect Git developers to have to pay a large corporation lots of money\n> > just to test functionality. This is in conformance with our policy,\n> > which states that versions must be \"in line with the version used by\n> > other long-term-support distributions\", which does not include extended\n> > LTS distributions.\n>\n> I don't have a strong opinion on the extended LTS issue. Like you, I\n> don't really care about dealing with paid support. OTOH, I think in many\n> cases there was little to no maintenance burden for these older\n> versions, since we'd already done the work to #ifdef them. But I guess\n> since you broke up the patches, they can always choose to revert or\n> include what they want.\n\nI may be in the minority here, but I'm fairly negative on this entire\npatch series. As you say, supporting these old versions is effectively\nzero-cost, so how does this project benefit from these changes which\npotentially \"break\" Git for users on older platforms? I see no upside\nhere. The cover letter provides no strong justification for\n(potentially) inconveniencing people; the argument about being able to\nutilize more modern Perl features is weak[1] at best and is not\nconvincing.\n\nAlthough brian is (quite rightly) concerned about security (or lack\nthereof with older installations), it is not this project's\nresponsibility to \"force\" people to upgrade their insecure\ninstallations. And it is not at all uncommon in the \"Real World\" for\ndecade-or-more old installations to be running in production\nenvironments, and programmers need to work within those environments,\nhowever, those installations are, for various business reasons (such\nas cost-effectiveness and known stability), unlikely to (ever) be\nupgraded to more modern versions. I, personally, deal with such\ninstallations on a very regular basis, and in my experience, the only\ntime upgrades are undertaken (in production settings) is when the\nsystems break completely and there is no choice but to replace them.\n\nFinally, there clearly are real-world cases[2] which benefit from Git\ncontinuing to support older platforms; why should we abandon them\nintentionally? And why should we turn down[3] the periodic trivial\npatch[4] which trickles in to help people on older platforms?\n\n[1]: https://lore.kernel.org/git/xmqq1q0mh9gn.fsf@gitster.g/\n[2]: https://lore.kernel.org/git/CAOO-Oz0NUA-YeyFT1MJ=XKyLWJvQoFH1b-F0EFOzvy8iWka3KA@mail.gmail.com/\n[3]: https://lore.kernel.org/git/ZwhMmGt0kZvaSzSL@tapette.crustytoothpaste.net/\n[4]: https://lore.kernel.org/git/CAOO-Oz1KhFcyErVx1Qb142PtPJS=UpgSD-FacckqNS4_okAtFQ@mail.gmail.com/\n"},{"id":"504869","messageId":"xmqqttdicws8.fsf@gitster.g","threadId":"62308","inReplyTo":"CAPig+cRmyZhq1qtomTFP7p7XMqrCP8-u7ah8D2+yUtrL880y7g@mail.gmail.com","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-10-11T18:35:51Z","receivedAt":"2024-10-11T18:35:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> I may be in the minority here, but I'm fairly negative on this entire\n> patch series. As you say, supporting these old versions is effectively\n> zero-cost, so how does this project benefit from these changes which\n> potentially \"break\" Git for users on older platforms? I see no upside\n> here. The cover letter provides no strong justification for\n> (potentially) inconveniencing people; the argument about being able to\n> utilize more modern Perl features is weak[1] at best and is not\n> convincing.\n\nWhile I agree with all you said above, one thing I find missing is\nthat even with #ifdef, we won't be shipping what we tested in real,\nas nobody, not just the author that touches the same file with the\n#ifdef we added 6 months ago is in, but all other developers who\nlooked at the change. It merely is \"we have #ifdef here and those\nwith ancient version of the library shouldn't see this new code\",\nwhich certainly is good enough for those of us who consider the\nancient platform support as a \"best effort\" thing.\n\nBut that does not, in my dictionary, quite qualify for the verb\n\"support\". A variable declared only inside #ifdef may be used\noutside it, or a variable declared without initialization outside\nthat is only assigned inside #ifdef may be used after matching\n#endif, which would not be noticed by anybody because nobody among\nus would be running such an ancient version without the feature\n#ifdef guards.\n\nSo I dunno.\n\nHaving said all that, I did find it was surprising that we raised to\na merely 6-year old cutoff point. If it were discarding versions of\nlibraries that are older than 12 years (instead of 6 years), would\nyou be having the same reaction?\n\nThanks.\n\n\n"},{"id":"504874","messageId":"20241011190812.2654837-1-asedeno@mit.edu","threadId":"62308","inReplyTo":"xmqqttdicws8.fsf@gitster.g","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"Alejandro R. Sedeño","fromEmail":"asedeno@mit.edu","sentAt":"2024-10-11T19:08:12Z","receivedAt":"2024-10-11T19:08:27Z","isPatch":true,"sender":{"key":"asedeno@mit.edu","avatar":"https://avatars.githubusercontent.com/u/28302?v=4"},"body":"Junio C Hamano writes:\n> Eric Sunshine writes:\n>\n> > I may be in the minority here, but I'm fairly negative on this entire\n> > patch series. As you say, supporting these old versions is effectively\n> > zero-cost, so how does this project benefit from these changes which\n> > potentially \"break\" Git for users on older platforms? I see no upside\n> > here. The cover letter provides no strong justification for\n> > (potentially) inconveniencing people; the argument about being able to\n> > utilize more modern Perl features is weak[1] at best and is not\n> > convincing.\n>\n> While I agree with all you said above, one thing I find missing is\n> that even with #ifdef, we won't be shipping what we tested in real,\n> as nobody, not just the author that touches the same file with the\n> #ifdef we added 6 months ago is in, but all other developers who\n> looked at the change. It merely is \"we have #ifdef here and those\n> with ancient version of the library shouldn't see this new code\",\n> which certainly is good enough for those of us who consider the\n> ancient platform support as a \"best effort\" thing.\n\nShould I go ahead and send the patch series that I had planned to fix\nthe breakage for old libcurl after all? I've gone ahead and built the\nlatest version for one of the ancient platforms I inexplicably build\ngit for, but am now dealing with breakage on another (SunOS 5.10).\n\n(Specifically, the new unit test framework stuff was failing to\ngenerate a suite file, patch forthcoming, and depends on mkdtemp,\nwhich we check for in configure but use unconditionally in the\nnewly-imported clar, and which I don't have here.)\n\n-Alejandro\n"},{"id":"504876","messageId":"CAPig+cRo3ptvgxctL-pjupzHsPeXCb3KfaBTwdzawGNezML6VA@mail.gmail.com","threadId":"62308","inReplyTo":"xmqqttdicws8.fsf@gitster.g","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-10-11T19:22:55Z","receivedAt":"2024-10-11T19:23:07Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Oct 11, 2024 at 2:35 PM Junio C Hamano wrote:\n> Eric Sunshine writes:\n> > I may be in the minority here, but I'm fairly negative on this entire\n> > patch series. As you say, supporting these old versions is effectively\n> > zero-cost, so how does this project benefit from these changes which\n> > potentially \"break\" Git for users on older platforms? I see no upside\n> > here. The cover letter provides no strong justification for\n> > (potentially) inconveniencing people; the argument about being able to\n> > utilize more modern Perl features is weak[1] at best and is not\n> > convincing.\n>\n> Having said all that, I did find it was surprising that we raised to\n> a merely 6-year old cutoff point. If it were discarding versions of\n> libraries that are older than 12 years (instead of 6 years), would\n> you be having the same reaction?\n\nI almost certainly would have had the same reaction had it been 12\nyears instead of 6. As one who \"lives\" with these old platforms both\nprofessionally and personally, I'm sensitive to the issue because I\nhave been burned too many times by projects arbitrarily dropping\nsupport for older platforms (or, more generally, not taking their user\npopulation into consideration when making arbitrary changes).\n\nI would be much more tolerant and understanding of changes with\nsubstantial and provable value, such as ridding the project of a\nhigh-cost maintenance burden, or eliminating some maldesign which\nimpedes implementation of some new important feature (or even which\nimpedes fixing some serious flaw). But the patch series under\ndiscussion does not fall into those categories; it (potentially)\npenalizes an arbitrary chunk of the Git user base without any obvious\nbenefit to the project itself.\n"},{"id":"504877","messageId":"ZwmEDt7ftJabvMUH@tapette.crustytoothpaste.net","threadId":"62308","inReplyTo":"CAPig+cRmyZhq1qtomTFP7p7XMqrCP8-u7ah8D2+yUtrL880y7g@mail.gmail.com","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-11T20:01:18Z","receivedAt":"2024-10-11T20:01:21Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-10-11 at 18:09:14, Eric Sunshine wrote:\n> I may be in the minority here, but I'm fairly negative on this entire\n> patch series. As you say, supporting these old versions is effectively\n> zero-cost, so how does this project benefit from these changes which\n> potentially \"break\" Git for users on older platforms? I see no upside\n> here. The cover letter provides no strong justification for\n> (potentially) inconveniencing people; the argument about being able to\n> utilize more modern Perl features is weak[1] at best and is not\n> convincing.\n\nIt is not effectively zero cost. When I want to write a patch, I must\nmake sure that it works on all the platforms we support, or my patch\nwill get reverted or not picked up. That means I have to expend\nadditional effort when adding features to look through the supported\nversions of our dependencies and either conditionally check them or skip\nthe feature. Sometimes I have to rewrite that feature in a different\nway, or ship a compatibility stub for a system that doesn't support it.\n\nI have actually spent a decent amount of work getting things to work\nacross older versions of software, both in Git and elsewhere. The more\nwe honour the policy we have already made and agreed upon, the less work\nGit developers have to do to support adding and maintaining these\nfeatures.\n\nI should be clear that I do very much value the portability of Git\nacross systems and architectures: my first laptop was a PowerPC Mac\nrunning Linux and I've owned UltraSPARC, ARM64, and MIPS hardware. I\nreally try to write code that doesn't have weird portability problems\nacross architectures or OSes, and that's relatively easy to do. But I'm\nnot willing to do lots of extra work to reimplement features or\nwork around ancient systems because people can't upgrade their OS and\ndependencies.\n\n> Although brian is (quite rightly) concerned about security (or lack\n> thereof with older installations), it is not this project's\n> responsibility to \"force\" people to upgrade their insecure\n> installations. And it is not at all uncommon in the \"Real World\" for\n> decade-or-more old installations to be running in production\n> environments, and programmers need to work within those environments,\n> however, those installations are, for various business reasons (such\n> as cost-effectiveness and known stability), unlikely to (ever) be\n> upgraded to more modern versions. I, personally, deal with such\n> installations on a very regular basis, and in my experience, the only\n> time upgrades are undertaken (in production settings) is when the\n> systems break completely and there is no choice but to replace them.\n\nIt isn't acceptable to run systems that don't have security updates\napplied that are connected to the Internet, period. In this day and\nage, it's very easy to have bugs in things like TLS or HTTP libraries\nthat are written in C and have security-sensitive implications and that\nare exploitable remotely.\n\nNo matter how stable your systems may be, it's very easy for unpatched\nsystems to quickly become part of a botnet, which is a problem for\neveryone else. Typically most businesses that sell to other businesses\nhave to be in compliance with certain security policies, especially if\nthey have user or corporate data. My employer simply cannot refuse to\nupgrade because we risk major legal problems (e.g., GDPR or PIPEDA\nproblems) or loss of most of our corporate customers because they won't\nor can't (due to regulatory requirements) do business with people who\nhave lax security. So I very much doubt that there is, in the general\ncase, any compelling business reason not to upgrade to a patched OS.\n\nCertainly we cannot force people to upgrade, but we also don't have to\nsupport those people. Git is an open-source project, and people are\nwelcome to make changes that they want to it without our approval, as\nlong as they comply with the license.\n\nI've worked at multiple companies where we had obsolete systems that\nneeded to be upgraded but hadn't been and have dealt with that pain,\nincluding when it negatively affected us shipping Git. I still think\nthat this is the appropriate policy to have.\n\nThere's also discussion about adding Rust to Git. Assuming we do that,\nwe're going to have to work with Rust's requirements for OSes, which\nusually follow major supported distros (for Linux) or upstream's policy\n(for the BSDs). So we're going to have the same problem in that people\nare actually going to have to upgrade to a supported OS, except it's\nreally not going to be optional because the code simply won't compile.\nWe might as well get used to doing that now.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"505017","messageId":"20241014132856.3558224-1-asedeno@mit.edu","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"Alejandro R. Sedeño","fromEmail":"asedeno@mit.edu","sentAt":"2024-10-14T13:28:56Z","receivedAt":"2024-10-14T13:29:07Z","isPatch":true,"sender":{"key":"asedeno@mit.edu","avatar":"https://avatars.githubusercontent.com/u/28302?v=4"},"body":"\"brian m. carlson\" writes:\n\n> The Perl changes are a huge upgrade. 5.8.1, our former supported\n> version, was from 2003. 5.26 has substantially improved Unicode support\n> (including Unicode strings), s///r (to allow returning a modified value\n> instead of modifying it in place), postderef syntax (which also provides\n> better interpolation for complex expressions), and subroutine signatures\n> (although these are experimental until 5.36). These allow us much more\n> readable, modern Perl.\n\nThis sounds compelling, however...\n\n> The final commit introduces a small but useful change that we can now\n> take advantage of with our newly updated Perl dependency as an example\n> of why this is a generally beneficial change. It can be omitted without\n> problem if it is judged to be too noisy.\n\nThe change being made to illustrate the point is not at all compelling\nto me. This appears to be an update for the sake of an update, with\nvery minor benefit at great compatibility cost.\n\nI'm especially opposed to the change in gitweb/gitweb.perl, as that\nscript is the one that is most likely to be used in a web-hosting\nenvironment where the user does not have control over the version of\nperl being used. And yes, those users would be better off hosting on\na newer platform, but that's not a good reason to break them with no\nreal gain for git.\n\n-Alejandro\n"},{"id":"505118","messageId":"CAPig+cS0vkTXeZX7qt6oOq3QpkWovfJnXuH7c3JtyAKOfnq1Ww@mail.gmail.com","threadId":"62308","inReplyTo":"ZwmEDt7ftJabvMUH@tapette.crustytoothpaste.net","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-10-15T06:13:45Z","receivedAt":"2024-10-15T06:13:57Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Oct 11, 2024 at 4:01 PM brian m. carlson\n wrote:\n> On 2024-10-11 at 18:09:14, Eric Sunshine wrote:\n> > I may be in the minority here, but I'm fairly negative on this entire\n> > patch series. As you say, supporting these old versions is effectively\n> > zero-cost, so how does this project benefit from these changes which\n> > potentially \"break\" Git for users on older platforms? I see no upside\n> > here. The cover letter provides no strong justification for\n> > (potentially) inconveniencing people; the argument about being able to\n> > utilize more modern Perl features is weak[1] at best and is not\n> > convincing.\n>\n> It is not effectively zero cost. When I want to write a patch, I must\n> make sure that it works on all the platforms we support, or my patch\n> will get reverted or not picked up. That means I have to expend\n> additional effort when adding features to look through the supported\n> versions of our dependencies and either conditionally check them or skip\n> the feature. Sometimes I have to rewrite that feature in a different\n> way, or ship a compatibility stub for a system that doesn't support it.\n>\n> I have actually spent a decent amount of work getting things to work\n> across older versions of software, both in Git and elsewhere. The more\n> we honour the policy we have already made and agreed upon, the less work\n> Git developers have to do to support adding and maintaining these\n> features.\n\nThis attitude feels backward to me. It says that simplifying life for\nGit developers (\"the few\") is of paramount importance and that Git\ndevelopers shouldn't care about inflicting pain/difficulty upon Git\nusers (\"the many\"). This is especially disturbing considering the size\nof the Git user base.\n\nInstead, for every proposed change to Git, we should be asking\nourselves what possible positive and negative impacts the change will\nhave on *users*, and if the negatives outweigh the positives, then the\nchange should be considered with a very wary eye indeed.\n\n> > Although brian is (quite rightly) concerned about security (or lack\n> > thereof with older installations), it is not this project's\n> > responsibility to \"force\" people to upgrade their insecure\n> > installations. And it is not at all uncommon in the \"Real World\" for\n> > decade-or-more old installations to be running in production\n> > environments, and programmers need to work within those environments,\n> > however, those installations are, for various business reasons (such\n> > as cost-effectiveness and known stability), unlikely to (ever) be\n> > upgraded to more modern versions. I, personally, deal with such\n> > installations on a very regular basis, and in my experience, the only\n> > time upgrades are undertaken (in production settings) is when the\n> > systems break completely and there is no choice but to replace them.\n>\n> It isn't acceptable to run systems that don't have security updates\n> applied that are connected to the Internet, period. In this day and\n> age, it's very easy to have bugs in things like TLS or HTTP libraries\n> that are written in C and have security-sensitive implications and that\n> are exploitable remotely.\n\nI don't disagree with your opinions about security and that, in an\nideal world, businesses should take these concerns seriously and\nshould upgrade. However...\n\n> No matter how stable your systems may be, it's very easy for unpatched\n> systems to quickly become part of a botnet, which is a problem for\n> everyone else. Typically most businesses that sell to other businesses\n> have to be in compliance with certain security policies, especially if\n> they have user or corporate data. My employer simply cannot refuse to\n> upgrade because we risk major legal problems (e.g., GDPR or PIPEDA\n> problems) or loss of most of our corporate customers because they won't\n> or can't (due to regulatory requirements) do business with people who\n> have lax security. So I very much doubt that there is, in the general\n> case, any compelling business reason not to upgrade to a patched OS.\n\nIn my experience, it is very rare for the non-technical people\nresponsible for allocating funds to be convinced that money/time\nshould be spent on upgrading *working* systems. There are always more\nurgent tasks (in their minds) which take priority. So, while there may\nnot be a compelling reason in the ideal world to forego upgrading, the\nreal world works differently.\n\n> Certainly we cannot force people to upgrade, but we also don't have to\n> support those people. Git is an open-source project, and people are\n> welcome to make changes that they want to it without our approval, as\n> long as they comply with the license.\n\nDitto what I said above about this attitude feeling backward.\n\nMoreover, as mentioned previously, it is not *this* project's\nresponsibility to be forcing people to upgrade their insecure systems.\n\n> There's also discussion about adding Rust to Git. Assuming we do that,\n> we're going to have to work with Rust's requirements for OSes, which\n> usually follow major supported distros (for Linux) or upstream's policy\n> (for the BSDs). So we're going to have the same problem in that people\n> are actually going to have to upgrade to a supported OS, except it's\n> really not going to be optional because the code simply won't compile.\n> We might as well get used to doing that now.\n\n\"Assuming we do that\" is the key phrase. There have been proponents\nand opponents, but almost nothing convincing written in favor of\nadopting Rust according to a (mostly) outsider's summary of the\ndiscussion[1]. The only properly compelling point in favor of Rust\ncame from Elijah; all other arguments for Rust had the flavor of\nsomeone evangelizing for his or her latest favorite language. We've\nseen such evangelizing before: numerous times with people insisting\nthat Git needed to be rewritten in C++, and (somewhat) more recently\nwhen Felipe insisted, not only that Ruby be accepted into the project,\nbut that parts of the project should be rewritten in Ruby. But mere\nevangelizing is not convincing. (Elijah's support for Rust was more\ncompelling, not only because he was not evangelizing, but because, as\nusual with him, he backed up his position with solid, well-reasoned\nstatements of experience directly applicable to the Git project.)\n\n[1]: https://lore.kernel.org/git/CAPig+cQtxx=fQM2xHSt8AsxyWgjSiS9Kd5PtjA+jDoK5s9xh4A@mail.gmail.com/\n"},{"id":"505197","messageId":"Zw7AVzBORjvxrvKh@nand.local","threadId":"62308","inReplyTo":"CAPig+cS0vkTXeZX7qt6oOq3QpkWovfJnXuH7c3JtyAKOfnq1Ww@mail.gmail.com","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-10-15T19:19:51Z","receivedAt":"2024-10-15T19:19:54Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Oct 15, 2024 at 02:13:45AM -0400, Eric Sunshine wrote:\n> On Fri, Oct 11, 2024 at 4:01 PM brian m. carlson\n> wrote:\n> > On 2024-10-11 at 18:09:14, Eric Sunshine wrote:\n> > > I may be in the minority here, but I'm fairly negative on this entire\n> > > patch series. As you say, supporting these old versions is effectively\n> > > zero-cost, so how does this project benefit from these changes which\n> > > potentially \"break\" Git for users on older platforms? I see no upside\n> > > here. The cover letter provides no strong justification for\n> > > (potentially) inconveniencing people; the argument about being able to\n> > > utilize more modern Perl features is weak[1] at best and is not\n> > > convincing.\n> >\n> > It is not effectively zero cost. When I want to write a patch, I must\n> > make sure that it works on all the platforms we support, or my patch\n> > will get reverted or not picked up. That means I have to expend\n> > additional effort when adding features to look through the supported\n> > versions of our dependencies and either conditionally check them or skip\n> > the feature. Sometimes I have to rewrite that feature in a different\n> > way, or ship a compatibility stub for a system that doesn't support it.\n> >\n> > I have actually spent a decent amount of work getting things to work\n> > across older versions of software, both in Git and elsewhere. The more\n> > we honour the policy we have already made and agreed upon, the less work\n> > Git developers have to do to support adding and maintaining these\n> > features.\n>\n> This attitude feels backward to me. It says that simplifying life for\n> Git developers (\"the few\") is of paramount importance and that Git\n> developers shouldn't care about inflicting pain/difficulty upon Git\n> users (\"the many\"). This is especially disturbing considering the size\n> of the Git user base.\n>\n> Instead, for every proposed change to Git, we should be asking\n> ourselves what possible positive and negative impacts the change will\n> have on *users*, and if the negatives outweigh the positives, then the\n> change should be considered with a very wary eye indeed.\n\nI agree with Eric that we should first and foremost consider the\nuser-impact of any changes we make to Git.\n\nI think in reality there must be a balance between the two. We should\nmake reasonable decisions when presented a trade-off between supporting\nusers and making the lives of Git developers easier. For instance, if\nthere is some change we could make which would involve a manageable\namount of additional effort, but would somehow benefit the lives of many\nusers (e.g., supporting more versions of a dependency, improving\nperformance, fixing a widespread bug, etc.), then we should do that\nthing.\n\nOn the other hand, if we are bending over backwards as developers to\nsupport a small portion of the user-base (e.g., by maintaining some\nancient version of a dependency that is no longer reasonable because we\ncan assume that 99.99% of users have a newer version), then we should\nconsider our options and investigate. What are the ongoing costs to\nmaintain that minimum version? What features are we missing? How many\nusers would be affected by dropping support for that version, etc.?\n\nI am not entirely sure whether the jump that brian is proposing is\nreasonable or not. The current minimum version of Perl, for example, is\nfrom 2003, but the proposed new minimum is from 2017. While the new\nversion is certainly not new, I am not sure how many users would be\naffected by dragging the minimum version forward by some 14 years.\n\n> > Certainly we cannot force people to upgrade, but we also don't have to\n> > support those people. Git is an open-source project, and people are\n> > welcome to make changes that they want to it without our approval, as\n> > long as they comply with the license.\n>\n> Ditto what I said above about this attitude feeling backward.\n>\n> Moreover, as mentioned previously, it is not *this* project's\n> responsibility to be forcing people to upgrade their insecure systems.\n\nI do not think it is our responsibility to force people to upgrade their\nsystems. But OTOH we should not bend over backwards here either to\nsupport ancient versions of dependencies when there are compelling\nreasons *not* to use those versions.\n\nI agree with your earlier comment that there is a balance between\nthinking about this abstractly and applying it to the real world. But at\nsome point we have to throw our hands up and stop spending effort\nsupporting ancient/insecure versions of dependencies.\n\n> > There's also discussion about adding Rust to Git. Assuming we do that,\n> > we're going to have to work with Rust's requirements for OSes, which\n> > usually follow major supported distros (for Linux) or upstream's policy\n> > (for the BSDs). So we're going to have the same problem in that people\n> > are actually going to have to upgrade to a supported OS, except it's\n> > really not going to be optional because the code simply won't compile.\n> > We might as well get used to doing that now.\n>\n> \"Assuming we do that\" is the key phrase.\n\nIndeed. Let's not worry about it for now.\n\nThanks,\nTaylor\n"},{"id":"505208","messageId":"Zw7xNX1Tk8BbT9k_@tapette.crustytoothpaste.net","threadId":"62308","inReplyTo":"ZwjyHl98xRs9TDQZ@ugly","subject":"Re: [PATCH 12/13] INSTALL: require Perl 5.26.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-15T22:48:21Z","receivedAt":"2024-10-15T22:48:29Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-10-11 at 09:38:38, Oswald Buddenhagen wrote:\n> On Thu, Oct 10, 2024 at 11:56:20PM +0000, brian m. carlson wrote:\n> > Update the INSTALL file to reflect our new dependency requirement.\n> > \n> any particular reason not to squash this into the parent commit?\n> i see how the separation makes sense for the libcurl sub-series, but\n> that doesn't seem applicable here.\n\nSure, I can do that.\n\n> regarding the actual `use` statements, you could make them somewhat more\n> legible by using 'v5.26' as the version number.\n> \n> another aspect to consider is that the statement doesn't just specify\n> the minimal version, but also subtly changes behavior. for example, the\n> `use strict;` statements become redundant.\n> \n> cf. https://perldoc.perl.org/functions/use#use-VERSION\n\nYes, I'll change that to a require v5.26 instead, since my goal isn't to\nchange the behaviour.\n\n> lastly, it would be nice to update the build systems to reflect the\n> version requirements. though the only pre-existing version check i found\n> is the libcurl one in contrib/buildsystems/CMakeLists.txt.\n\nI don't build with cmake, so I can't speak to the requirements for it.\nIt doesn't actually work on Unix as far as I know, and I don't run\nWindows at all.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"505217","messageId":"Zw8BMEYHaH2ImMmY@tapette.crustytoothpaste.net","threadId":"62308","inReplyTo":"Zw7AVzBORjvxrvKh@nand.local","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perlg","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-15T23:56:32Z","receivedAt":"2024-10-15T23:56:35Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-10-15 at 19:19:51, Taylor Blau wrote:\n> I agree with Eric that we should first and foremost consider the\n> user-impact of any changes we make to Git.\n\n> I think in reality there must be a balance between the two. We should\n> make reasonable decisions when presented a trade-off between supporting\n> users and making the lives of Git developers easier. For instance, if\n> there is some change we could make which would involve a manageable\n> amount of additional effort, but would somehow benefit the lives of many\n> users (e.g., supporting more versions of a dependency, improving\n> performance, fixing a widespread bug, etc.), then we should do that\n> thing.\n>\n> On the other hand, if we are bending over backwards as developers to\n> support a small portion of the user-base (e.g., by maintaining some\n> ancient version of a dependency that is no longer reasonable because we\n> can assume that 99.99% of users have a newer version), then we should\n> consider our options and investigate. What are the ongoing costs to\n> maintain that minimum version? What features are we missing? How many\n> users would be affected by dropping support for that version, etc.?\n\nRight now, we have a clearly documented policy about what we support\nwhich was discussed extensively on the list. This is the project's\npolicy, not mine. I agree with it, but I'm not the only person who has\nadvocated for it or thought it was an acceptable policy.\n\nThe policy was going to be even stricter in that we were going to\nrequire people to set up CI in order to be a supported platform. My\nconcern with that, which I mentioned at the time, is that less common\narchitectures don't run in GitHub Actions or most other CI platforms (or\ndon't run fast enough or correctly enough in emulation to be reasonably\ntested), and so we'd essentially be excluding all non-x86 processors,\nwhich I don't believe to be acceptable. That is a position that I think\nis definitely in the interests of users.\n\nHowever, the fact is that nobody is testing the platforms I'm proposing\nto drop support for. Nobody has even bothered to set up a single CI job\nfor any variant of those platforms at all or to request that one be set\nup, nor stepped up to be a maintainer. I should point out that setting\nup tests in a VM in GitHub Actions is very easy and I linked to an\nexample I use in other projects in the thread where we adopted this\npolicy.\n\nNobody, outside of the FreeBSD maintainer, has even bothered to set up\nCI for a platform other than the three major ones. The patches to fix\nSunOS 5.10 also don't include any tests or CI. I don't think it's\nreasonable for us to go out of our way to support these systems if\nnobody using those platforms has bothered to provide even the most\nrudimentary check that they work. How can we expect developers who\ndon't use these systems to even know if they work without some basic\ntests, even if it's for only one architecture, especially given that in\nmany cases it involves adding just three lines to the workflow file?\n\nI think the answer is that we can't. Since we don't have anyone who has\ndemonstrated that there's basic interest in helping the contributors\nsupport their platform by setting up tests or volunteering to be the\nmaintainer, we can't support those platforms specifically and we're\nessentially left with just honouring the policy that we've set, which is\nwhat I'm doing here.\n\n> I am not entirely sure whether the jump that brian is proposing is\n> reasonable or not. The current minimum version of Perl, for example, is\n> from 2003, but the proposed new minimum is from 2017. While the new\n> version is certainly not new, I am not sure how many users would be\n> affected by dragging the minimum version forward by some 14 years.\n\nI don't think we can actually know in the general case. It will exclude\npeople on obsolete systems, but it should not exclude anyone with an OS\nshipped in the past 5 years. The only major OS distributions that I see\nsupporting more than a 5-year regular LTS life span are RHEL and SLES,\nand I've considered them here. Again, I don't think asking people to\nupgrade an OS every five years is in any way unreasonable, and I have\neven considered people farther back.\n\nIt's also reasonably easy to build new versions of Perl with things like\nperlbrew or other toolchain tools, and those are the common suggestion\nthat people use when they have a toolchain that's out of date. I've\nworked at a company which did some very unusual things with Perl\n(specifically compiling it to C for performance) and who I think had at\none point used the oldest Perl I'm aware of being used at a Perl shop\n(at the time, 5.6) for major development, and I know they're now using a\nmodern Perl and wouldn't be affected. In fact, people doing Perl\ndevelopment professionally are overwhelmingly using very modern Perl, so\nthe practical implication is that we only need to consider the distro\nPerl here, since everyone will be using something at least that new (or\nwill have an easy way to build such a version).\n\nI will point out that I specifically dropped it down from Perl 5.30 to\n5.26 in the interests of SLES, even though I don't believe they're a\nmajor Linux distro anymore. I felt that given the fact that it was easy\nto support SLES, it would be better to do so, even if it sees relatively\nlittle use. I'm not aware of any other reasonably common distro\nsupporting an older Perl.\n\n> I do not think it is our responsibility to force people to upgrade their\n> systems. But OTOH we should not bend over backwards here either to\n> support ancient versions of dependencies when there are compelling\n> reasons *not* to use those versions.\n\nAs I said, nobody is supporting these systems. We, as contributors,\ncannot get a suitable (secure and functional, available at no charge)\nsystem to test on. Nobody has stepped up to volunteer to do this work\nand maintain these systems for the project. Our own policy, which we've\ndiscussed and agreed upon, is not to support them.\n\nAbsent somebody volunteering to do the work here, I'm proposing to drop\nsupport for them. I'm willing to do the work to adequately support\nDebian on all its architectures (to the best of my ability), and I'm\nwilling to take into consideration other major platforms for which we\nhave CI or for which I can reasonably be expected to test. I'm not\nwilling to consider other systems where nobody has volunteered to step\nup and be responsible.\n\nIf other people in this thread are volunteering to be maintainers for\nthese systems and add suitable CI jobs so that we can find problems\nbefore they land in `master`, I'll happily adjust my series accordingly.\nPlease also propose a patch for the platform support policy which\nclearly states what our new policy should be so it can be discussed.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"505224","messageId":"CAOO-Oz0t8V28P7VEACAu69_dD47ZuPPazN9vy_c1dLCeAU5N_Q@mail.gmail.com","threadId":"62308","inReplyTo":"Zw8BMEYHaH2ImMmY@tapette.crustytoothpaste.net","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perlg","fromName":"Alejandro R. Sedeño","fromEmail":"asedeno@mit.edu","sentAt":"2024-10-16T02:00:09Z","receivedAt":"2024-10-16T02:00:25Z","isPatch":true,"sender":{"key":"asedeno@mit.edu","avatar":"https://avatars.githubusercontent.com/u/28302?v=4"},"body":"On Tue, Oct 15, 2024 at 7:57 PM brian m. carlson\n wrote:\n> Nobody, outside of the FreeBSD maintainer, has even bothered to set up\n> CI for a platform other than the three major ones. The patches to fix\n> SunOS 5.10 also don't include any tests or CI. I don't think it's\n> reasonable for us to go out of our way to support these systems if\n> nobody using those platforms has bothered to provide even the most\n> rudimentary check that they work. How can we expect developers who\n> don't use these systems to even know if they work without some basic\n> tests, even if it's for only one architecture, especially given that in\n> many cases it involves adding just three lines to the workflow file?\n>\n> I think the answer is that we can't. Since we don't have anyone who has\n> demonstrated that there's basic interest in helping the contributors\n> support their platform by setting up tests or volunteering to be the\n> maintainer, we can't support those platforms specifically and we're\n> essentially left with just honouring the policy that we've set, which is\n> what I'm doing here.\n\nThe machine I use to build for SunOS takes, let's be generous and\nsay an hour to build git from a fresh checkout. If I'm iterating\non trying to fix something, run make, and see that it's building\ndaemon.o, I know I've got another hour or so before I find out if\nmy change worked, and maybe discover what the *next* new issue\nis. There are faster SunOS machines, but not the one I happen to\nhave available. You would not want this machine in any sort of CI\nsystem. That said, until sometime this summer, I was building\nevery release of git on that machine within days, often hours, of\nit being tagged, for *nearly 15 years*. If something broke, I'd\nfix it, test the build (which could take hours if I had to\niterate), and submit a patch. You can find them in the logs. It\nwas, fortunately, not that often, which is a testament to git\nremaining portable. Thank you all for that.\n\nAs I mentioned in my report regarding the SunOS build, I'm\npersonally ready to abandon that particular use of my time,\nthough if it's fixed, it'll go back onto my semi-automated build\nscripts for git releases, and I'll continue to submit patches as\nneeded. It's not a CI, and no, I don't have notifications for and\ndon't build RCs, but it's something.\n\n> It's also reasonably easy to build new versions of Perl with things like\n> perlbrew or other toolchain tools, and those are the common suggestion\n> that people use when they have a toolchain that's out of date. I've\n> worked at a company which did some very unusual things with Perl\n> (specifically compiling it to C for performance) and who I think had at\n> one point used the oldest Perl I'm aware of being used at a Perl shop\n> (at the time, 5.6) for major development, and I know they're now using a\n> modern Perl and wouldn't be affected. In fact, people doing Perl\n> development professionally are overwhelmingly using very modern Perl, so\n> the practical implication is that we only need to consider the distro\n> Perl here, since everyone will be using something at least that new (or\n> will have an easy way to build such a version).\n\nBuilding a new perl is easy. Telling the system-controlled apache\nmod_perl to trust me and use my perl, less easy. (gitweb.perl.)\n\n-Alejandro\n"},{"id":"505351","messageId":"ZxDV8cf8yfzhYk6d@pks.im","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-10-17T09:16:40Z","receivedAt":"2024-10-17T09:16:45Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Oct 10, 2024 at 11:56:08PM +0000, brian m. carlson wrote:\n> For a long time, we ended up with protracted discussions on the mailing\n> list about what versions of software we should support. Oftentimes, we\n> broke long-obsolete operating system versions by using something shipped\n> slightly more recently.\n> \n> Fortunately, we now have a platform support policy to guide us in our\n> approach to dependencies, so we can make updates without worrying about\n> breaking systems that have not received security support in several\n> years.\n> \n> This series updates our requirements for libcurl to 7.61.0 (the version\n> in RHEL 8) and for Perl to 5.26.0 (the version in 15.6). I considered\n> the mainstream LTS versions of RHEL, Debian, Ubuntu, and SLES, but\n> omitted consideration of paid support extended LTS, since we cannot\n> expect Git developers to have to pay a large corporation lots of money\n> just to test functionality. This is in conformance with our policy,\n> which states that versions must be \"in line with the version used by\n> other long-term-support distributions\", which does not include extended\n> LTS distributions.\n\nFor what it's worth, this patch series breaks our GitLab pipeline\nbecause we still exercise Ubuntu 16.04, which uses an old version of\ncurl that's not supported anymore after this patch series lands. We have\njust recently started adopted that job in GitLab because GitHub couldn't\nsupport it anymore, but we wanted to keep around the test coverage for\nsuch oldish platforms.\n\nSo if we want to declare Ubuntu 16.04 as unsupported, this patch series\nwould also have to remove the CI job.\n\nPatrick\n"},{"id":"505798","messageId":"66bb101c-eb9f-4824-8766-750e58cd422e@gentoo.org","threadId":"62308","inReplyTo":"ZwmEDt7ftJabvMUH@tapette.crustytoothpaste.net","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"Eli Schwartz","fromEmail":"eschwartz@gentoo.org","sentAt":"2024-10-22T03:34:25Z","receivedAt":"2024-10-22T03:34:29Z","isPatch":true,"sender":{"key":"eschwartz@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/6551424?v=4"},"body":"On 10/11/24 4:01 PM, brian m. carlson wrote:\n> It is not effectively zero cost. When I want to write a patch, I must\n> make sure that it works on all the platforms we support, or my patch\n> will get reverted or not picked up. That means I have to expend\n> additional effort when adding features to look through the supported\n> versions of our dependencies and either conditionally check them or skip\n> the feature. Sometimes I have to rewrite that feature in a different\n> way, or ship a compatibility stub for a system that doesn't support it.\n> \n> I have actually spent a decent amount of work getting things to work\n> across older versions of software, both in Git and elsewhere. The more\n> we honour the policy we have already made and agreed upon, the less work\n> Git developers have to do to support adding and maintaining these\n> features.\n\n\nOn a personal level I have a mild abhorrence of the general notion of\nbumping a version requirement in order to bump a requirement. I have a\nlot of sympathy for having a policy about what to expend effort on\nsupporting, though!\n\nWithout getting into what the git project \"should expend effort to\nsupport\" (future efforts to be clear, not existing code that simply\nstays in place doing no significant harm)...\n\nThis patch series simplifies the codebase in order to remove workarounds\nfor versions of curl < 7.56.0 -- it then documents the minimum supported\nversion as 7.61.0 and there are even proposals to add a version check\nfor that. Why? Is it currently believed that curl 7.56 through 7.60.x\nare going to break as a result of the modifications to ./INSTALL alone?\n\nInstead I would suggest documenting the minimum version as 7.56 to align\nwith reality.\n\nYour general observation about respecting the platform support policy\nand not making developers expend time working around ancient dependency\nversions no one should be using... is something that I would say is a\nbetter fit for, well, the platform support policy.\n\nYou could instead add a section to the platform support policy detailing\nthe minimum versions of dependencies which the git developers are\nwilling to spend time supporting. A developer working on changes which\nwould be onerous to backfill support for, would then have a simple,\ndocumented, easy to find policy about when it is acceptable to bump the\nversion documented in ./INSTALL. The process would then look like:\n\n- Code a new feature.\n\n- Check the version table to see if maybe it was added basically\n yesterday in curl 8.7, or whether it is available in say, curl 7.75.\n\n- Discover it was added in curl 7.59. Oh shoot! The ./INSTALL says we\n still support versions before that, but it's also super decrepit and\n nobody runs it anyway. But wait -- the platform support says we only\n care about 7.61.\n\n- Shrug and grin. First patch in the series now bumps ./INSTALL to say\n the minimum required curl is 7.59, and if anyone disagrees then it's\n fair game to respond with. \"fite me. The platform support says I don't\n have to care, we are making this change whether you like it or not\".\n\n\nThe important distinction here is that in this model, the install\nrequirements aren't about what you want to spend time on supporting,\nthey are about truthfully communicating what *works* in point of fact.\n\nLikewise, it does actually make sense to have a version check either in\nthe build system or the code, but probably the build system, to ensure\nthat the minimum required version which is necessary in order to\nsuccessfully compile the codebase is available. It doesn't change what\nworks and what fails -- it simply provides a clear error message.\nInstead of inscrutable compiler errors about CURLSSLSET_NO_BACKENDS not\nexisting, you get:\n\n\n\nDependency libcurl found: NO. Found 7.51.0 but need: '>=7.56.0'\n\nmeson.build:642:7: ERROR: Dependency 'libcurl' is required but not found.\n\n\n\n-- \nEli Schwartz\n\n"},{"id":"505871","messageId":"ZxggIfymo78PhXrz@tapette.crustytoothpaste.net","threadId":"62308","inReplyTo":"66bb101c-eb9f-4824-8766-750e58cd422e@gentoo.org","subject":"Re: [PATCH 00/13] Update versions of libcurl and Perl","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-22T21:58:57Z","receivedAt":"2024-10-22T21:58:59Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-10-22 at 03:34:25, Eli Schwartz wrote:\n> Your general observation about respecting the platform support policy\n> and not making developers expend time working around ancient dependency\n> versions no one should be using... is something that I would say is a\n> better fit for, well, the platform support policy.\n> \n> You could instead add a section to the platform support policy detailing\n> the minimum versions of dependencies which the git developers are\n> willing to spend time supporting. A developer working on changes which\n> would be onerous to backfill support for, would then have a simple,\n> documented, easy to find policy about when it is acceptable to bump the\n> version documented in ./INSTALL. The process would then look like:\n\nWe already wrote this out. If it's supported in a major LTS (not\nextended LTS) distribution, then we support it; otherwise, we don't. I\nplan to add some specific CI jobs to cover common supported platforms in\nthe future, so we actually test what we're supporting.\n\n> - Code a new feature.\n> \n> - Check the version table to see if maybe it was added basically\n> yesterday in curl 8.7, or whether it is available in say, curl 7.75.\n> \n> - Discover it was added in curl 7.59. Oh shoot! The ./INSTALL says we\n> still support versions before that, but it's also super decrepit and\n> nobody runs it anyway. But wait -- the platform support says we only\n> care about 7.61.\n> \n> - Shrug and grin. First patch in the series now bumps ./INSTALL to say\n> the minimum required curl is 7.59, and if anyone disagrees then it's\n> fair game to respond with. \"fite me. The platform support says I don't\n> have to care, we are making this change whether you like it or not\".\n\nThis is the approach we used to have, where we'd accept patches to\nsupport older systems if they weren't too invasive. It involved lots of\nheated discussions on the list that were unproductive and never came to\na conclusion, and they'd repeat with some frequency. That's why we have\nthe policy we have now: because it's clearer and more definitive and\narguing extensively about what we were supporting was not in the\ninterests of a healthy community for the project. It is also more\nhonest in that we're clearly communicating to users whether they can\nexpect things to work out of the box or whether they'll need to carry\ncustom patches on their own.\n\nOverall, people don't update the INSTALL documentation and it's\nroutinely out of date. Should they? Yes, but practically they don't,\nand we don't test that, so we don't know if it's accurate.\n\n> The important distinction here is that in this model, the install\n> requirements aren't about what you want to spend time on supporting,\n> they are about truthfully communicating what *works* in point of fact.\n\nWhile this sounds nice in principle, it doesn't work in practice. We\ndon't test things like MIPS or UltraSPARC hardware because we don't have\nCI systems that use that hardware and they're extremely slow in\nemulation, but we do want to support them if they're on an otherwise\nsupported OS. Similarly, we probably do want to support NetBSD, but\nhave no tests for it.\n\nWe also don't have situations where, in general, people are willing to\ncompile their own set of software from scratch. For example, I'm not\ncompiling an arbitrary libcurl version to test a problem on the list.\nWith very few exceptions, the versions people use are tied to their\ndistribution or vendor. If someone asks to support libcurl 7.19, we\neither have to custom compile that to test or try to run CentOS 6, which\nno longer runs in a Docker container on a modern kernel and has no\nsecurity support, so practically the answer is no.\n\nSo we don't know for certain what does and does work, but we do know\nwhat we're willing to fix and support.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"505879","messageId":"20241023004600.1645313-5-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241023004600.1645313-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 04/12] git-curl-compat: remove check for curl 7.39.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-23T00:45:52Z","receivedAt":"2024-10-23T00:46:05Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.39.0 was released in November 2014, which is almost ten years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 9 and Ubuntu 16.04, both of which are out of\nmainstream security support, have supported a newer version, and RHEL 8,\nwhich is still in support, also has a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 9 ---------\n http.c | 11 -----------\n 2 files changed, 20 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex 21306fa88f..b301ef154c 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,15 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURLOPT_PINNEDPUBLICKEY was added in 7.39.0, released in November\n- * 2014. CURLE_SSL_PINNEDPUBKEYNOTMATCH was added in that same version.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x072c00\n-#define GIT_CURL_HAVE_CURLOPT_PINNEDPUBLICKEY 1\n-#define GIT_CURL_HAVE_CURLE_SSL_PINNEDPUBKEYNOTMATCH 1\n-#endif\n-\n /**\n * CURL_HTTP_VERSION_2 was added in 7.43.0, released in June 2015.\n *\ndiff --git a/http.c b/http.c\nindex ac4b98baa0..cdef059090 100644\n--- a/http.c\n+++ b/http.c\n@@ -63,9 +63,7 @@ static char *ssl_key;\n static char *ssl_key_type;\n static char *ssl_capath;\n static char *curl_no_proxy;\n-#ifdef GIT_CURL_HAVE_CURLOPT_PINNEDPUBLICKEY\n static char *ssl_pinnedkey;\n-#endif\n static char *ssl_cainfo;\n static long curl_low_speed_limit = -1;\n static long curl_low_speed_time = -1;\n@@ -509,12 +507,7 @@ static int http_options(const char *var, const char *value,\n \t}\n \n \tif (!strcmp(\"http.pinnedpubkey\", var)) {\n-#ifdef GIT_CURL_HAVE_CURLOPT_PINNEDPUBLICKEY\n \t\treturn git_config_pathname(&ssl_pinnedkey, var, value);\n-#else\n-\t\twarning(_(\"Public key pinning not supported with cURL < 7.39.0\"));\n-\t\treturn 0;\n-#endif\n \t}\n \n \tif (!strcmp(\"http.extraheader\", var)) {\n@@ -1104,10 +1097,8 @@ static CURL *get_curl_handle(void)\n \t\tcurl_easy_setopt(result, CURLOPT_SSLKEYTYPE, ssl_key_type);\n \tif (ssl_capath)\n \t\tcurl_easy_setopt(result, CURLOPT_CAPATH, ssl_capath);\n-#ifdef GIT_CURL_HAVE_CURLOPT_PINNEDPUBLICKEY\n \tif (ssl_pinnedkey)\n \t\tcurl_easy_setopt(result, CURLOPT_PINNEDPUBLICKEY, ssl_pinnedkey);\n-#endif\n \tif (http_ssl_backend && !strcmp(\"schannel\", http_ssl_backend) &&\n \t !http_schannel_use_ssl_cainfo) {\n \t\tcurl_easy_setopt(result, CURLOPT_CAINFO, NULL);\n@@ -1825,10 +1816,8 @@ static int handle_curl_result(struct slot_results *results)\n \t\t */\n \t\tcredential_reject(&cert_auth);\n \t\treturn HTTP_NOAUTH;\n-#ifdef GIT_CURL_HAVE_CURLE_SSL_PINNEDPUBKEYNOTMATCH\n \t} else if (results->curl_result == CURLE_SSL_PINNEDPUBKEYNOTMATCH) {\n \t\treturn HTTP_NOMATCHPUBLICKEY;\n-#endif\n \t} else if (missing_target(results))\n \t\treturn HTTP_MISSING_TARGET;\n \telse if (results->http_code == 401) {\n"},{"id":"505880","messageId":"20241023004600.1645313-4-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241023004600.1645313-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 03/12] git-curl-compat: remove check for curl 7.34.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-23T00:45:51Z","receivedAt":"2024-10-23T00:46:05Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.34.0 was released in December 2013, which is well over ten\nyears ago, and no major operating system vendor is still providing\nsecurity support for it. Debian 8 and Ubuntu 14.04, both of which are\nout of mainstream security support, have supported a newer version, and\nRHEL 8, which is still in support, also has a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 22 ----------------------\n http.c | 2 --\n imap-send.c | 4 ----\n 3 files changed, 28 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex 9100af027f..21306fa88f 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,28 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURLOPT_LOGIN_OPTIONS was added in 7.34.0, released in December\n- * 2013.\n- *\n- * If we start requiring 7.34.0 we might also be able to remove the\n- * code conditional on USE_CURL_FOR_IMAP_SEND in imap-send.c, see\n- * 1e16b255b95 (git-imap-send: use libcurl for implementation,\n- * 2014-11-09) and the check it added for \"072200\" in the Makefile.\n-\n- */\n-#if LIBCURL_VERSION_NUM >= 0x072200\n-#define GIT_CURL_HAVE_CURLOPT_LOGIN_OPTIONS 1\n-#endif\n-\n-/**\n- * CURL_SSLVERSION_TLSv1_[012] was added in 7.34.0, released in\n- * December 2013.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x072200\n-#define GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_0\n-#endif\n-\n /**\n * CURLOPT_PINNEDPUBLICKEY was added in 7.39.0, released in November\n * 2014. CURLE_SSL_PINNEDPUBKEYNOTMATCH was added in that same version.\ndiff --git a/http.c b/http.c\nindex 633bbf74ee..ac4b98baa0 100644\n--- a/http.c\n+++ b/http.c\n@@ -52,11 +52,9 @@ static struct {\n \t{ \"sslv2\", CURL_SSLVERSION_SSLv2 },\n \t{ \"sslv3\", CURL_SSLVERSION_SSLv3 },\n \t{ \"tlsv1\", CURL_SSLVERSION_TLSv1 },\n-#ifdef GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_0\n \t{ \"tlsv1.0\", CURL_SSLVERSION_TLSv1_0 },\n \t{ \"tlsv1.1\", CURL_SSLVERSION_TLSv1_1 },\n \t{ \"tlsv1.2\", CURL_SSLVERSION_TLSv1_2 },\n-#endif\n #ifdef GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_3\n \t{ \"tlsv1.3\", CURL_SSLVERSION_TLSv1_3 },\n #endif\ndiff --git a/imap-send.c b/imap-send.c\nindex ec68a06687..954cc9be65 100644\n--- a/imap-send.c\n+++ b/imap-send.c\n@@ -1417,15 +1417,11 @@ static CURL *setup_curl(struct imap_server_conf *srvc, struct credential *cred)\n \tcurl_easy_setopt(curl, CURLOPT_PORT, srvc->port);\n \n \tif (srvc->auth_method) {\n-#ifndef GIT_CURL_HAVE_CURLOPT_LOGIN_OPTIONS\n-\t\twarning(\"No LOGIN_OPTIONS support in this cURL version\");\n-#else\n \t\tstruct strbuf auth = STRBUF_INIT;\n \t\tstrbuf_addstr(&auth, \"AUTH=\");\n \t\tstrbuf_addstr(&auth, srvc->auth_method);\n \t\tcurl_easy_setopt(curl, CURLOPT_LOGIN_OPTIONS, auth.buf);\n \t\tstrbuf_release(&auth);\n-#endif\n \t}\n \n \tif (!srvc->use_ssl)\n"},{"id":"505881","messageId":"20241023004600.1645313-1-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241010235621.738239-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 00/12] Update versions of libcurl and Perl","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-23T00:45:48Z","receivedAt":"2024-10-23T00:46:05Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"For a long time, we ended up with protracted discussions on the mailing\nlist about what versions of software we should support. Oftentimes, we\nbroke long-obsolete operating system versions by using something shipped\nslightly more recently.\n\nFortunately, we now have a platform support policy to guide us in our\napproach to dependencies, so we can make updates without worrying about\nbreaking systems that have not received security support in several\nyears.\n\nThis series updates our requirements for libcurl to 7.61.0 (the version\nin RHEL 8) and for Perl to 5.26.0 (the version in 15.6). I considered\nthe mainstream LTS versions of RHEL, Debian, Ubuntu, and SLES, but\nomitted consideration of paid support extended LTS, since we cannot\nexpect Git developers to have to pay a large corporation lots of money\njust to test functionality. This is in conformance with our policy,\nwhich states that versions must be \"in line with the version used by\nother long-term-support distributions\", which does not include extended\nLTS distributions.\n\nI plan to send a future series that will add some additional CI jobs in\norder to be sure that we're testing the major supported distros and\navoid regressions.\n\nChanges from v1:\n* Use require instead of use for Perl to avoid enabling features.\n* Use v5.26 instead of 5.026000.\n* Squash the INSTALL documentation into the Perl changes.\n\nbrian m. carlson (12):\n git-curl-compat: remove check for curl 7.21.5\n git-curl-compat: remove check for curl 7.25.0\n git-curl-compat: remove check for curl 7.34.0\n git-curl-compat: remove check for curl 7.39.0\n git-curl-compat: remove check for curl 7.43.0\n git-curl-compat: remove check for curl 7.44.0\n git-curl-compat: remove check for curl 7.52.0\n git-curl-compat: remove check for curl 7.53.0\n git-curl-compat: remove check for curl 7.56.0\n INSTALL: document requirement for libcurl 7.61.0\n Require Perl 5.26.0\n gitweb: make use of s///r\n\n INSTALL | 13 +---\n contrib/diff-highlight/DiffHighlight.pm | 2 +-\n contrib/mw-to-git/Git/Mediawiki.pm | 2 +-\n git-archimport.perl | 2 +-\n git-curl-compat.h | 98 -------------------------\n git-cvsexportcommit.perl | 2 +-\n git-cvsimport.perl | 2 +-\n git-cvsserver.perl | 2 +-\n git-send-email.perl | 2 +-\n git-svn.perl | 2 +-\n gitweb/gitweb.perl | 6 +-\n http.c | 58 ---------------\n imap-send.c | 4 -\n perl/Git.pm | 2 +-\n perl/Git/I18N.pm | 2 +-\n perl/Git/LoadCPAN.pm | 2 +-\n perl/Git/Packet.pm | 2 +-\n t/t0202/test.pl | 2 +-\n t/t5562/invoke-with-content-length.pl | 2 +-\n t/t9700/test.pl | 2 +-\n t/test-terminal.perl | 2 +-\n 21 files changed, 23 insertions(+), 188 deletions(-)\n\n"},{"id":"505882","messageId":"20241023004600.1645313-2-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241023004600.1645313-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 01/12] git-curl-compat: remove check for curl 7.21.5","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-23T00:45:49Z","receivedAt":"2024-10-23T00:46:05Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.21.5 was released in April 2011, which is well over ten years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 7, RHEL 7, and Ubuntu 12.04, all of which are\nout of mainstream security support, have all supported a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 7 -------\n 1 file changed, 7 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex e1d0bdd273..c24ed686c1 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,13 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURL_SOCKOPT_OK was added in 7.21.5, released in April 2011.\n- */\n-#if LIBCURL_VERSION_NUM < 0x071505\n-#define CURL_SOCKOPT_OK 0\n-#endif\n-\n /**\n * CURLOPT_TCP_KEEPALIVE was added in 7.25.0, released in March 2012.\n */\n"},{"id":"505883","messageId":"20241023004600.1645313-3-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241023004600.1645313-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 02/12] git-curl-compat: remove check for curl 7.25.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-23T00:45:50Z","receivedAt":"2024-10-23T00:46:05Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.25.0 was released in March 2012, which is well over ten years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 8, RHEL 7, and Ubuntu 12.10, all of which are\nout of mainstream security support, have all supported a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 8 --------\n http.c | 24 ------------------------\n 2 files changed, 32 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex c24ed686c1..9100af027f 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,14 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURLOPT_TCP_KEEPALIVE was added in 7.25.0, released in March 2012.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x071900\n-#define GITCURL_HAVE_CURLOPT_TCP_KEEPALIVE 1\n-#endif\n-\n-\n /**\n * CURLOPT_LOGIN_OPTIONS was added in 7.34.0, released in December\n * 2013.\ndiff --git a/http.c b/http.c\nindex d59e59f66b..633bbf74ee 100644\n--- a/http.c\n+++ b/http.c\n@@ -716,35 +716,11 @@ static int has_proxy_cert_password(void)\n }\n #endif\n \n-#ifdef GITCURL_HAVE_CURLOPT_TCP_KEEPALIVE\n static void set_curl_keepalive(CURL *c)\n {\n \tcurl_easy_setopt(c, CURLOPT_TCP_KEEPALIVE, 1);\n }\n \n-#else\n-static int sockopt_callback(void *client, curl_socket_t fd, curlsocktype type)\n-{\n-\tint ka = 1;\n-\tint rc;\n-\tsocklen_t len = (socklen_t)sizeof(ka);\n-\n-\tif (type != CURLSOCKTYPE_IPCXN)\n-\t\treturn 0;\n-\n-\trc = setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, (void *)&ka, len);\n-\tif (rc < 0)\n-\t\twarning_errno(\"unable to set SO_KEEPALIVE on socket\");\n-\n-\treturn CURL_SOCKOPT_OK;\n-}\n-\n-static void set_curl_keepalive(CURL *c)\n-{\n-\tcurl_easy_setopt(c, CURLOPT_SOCKOPTFUNCTION, sockopt_callback);\n-}\n-#endif\n-\n /* Return 1 if redactions have been made, 0 otherwise. */\n static int redact_sensitive_header(struct strbuf *header, size_t offset)\n {\n"},{"id":"505884","messageId":"20241023004600.1645313-6-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241023004600.1645313-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 05/12] git-curl-compat: remove check for curl 7.43.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-23T00:45:53Z","receivedAt":"2024-10-23T00:46:07Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.43.0 was released in June 2015, which is over nine years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 9 and Ubuntu 16.04, both of which are out of\nmainstream security support, have supported a newer version, and RHEL 8,\nwhich is still in support, also has a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 11 -----------\n http.c | 5 -----\n 2 files changed, 16 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex b301ef154c..cd970e34d6 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,17 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURL_HTTP_VERSION_2 was added in 7.43.0, released in June 2015.\n- *\n- * The CURL_HTTP_VERSION_2 alias (but not CURL_HTTP_VERSION_2_0) has\n- * always been a macro, not an enum field (checked on curl version\n- * 7.78.0)\n- */\n-#if LIBCURL_VERSION_NUM >= 0x072b00\n-#define GIT_CURL_HAVE_CURL_HTTP_VERSION_2 1\n-#endif\n-\n /**\n * CURLSSLOPT_NO_REVOKE was added in 7.44.0, released in August 2015.\n *\ndiff --git a/http.c b/http.c\nindex cdef059090..945df9a628 100644\n--- a/http.c\n+++ b/http.c\n@@ -980,7 +980,6 @@ static long get_curl_allowed_protocols(int from_user, struct strbuf *list)\n \treturn bits;\n }\n \n-#ifdef GIT_CURL_HAVE_CURL_HTTP_VERSION_2\n static int get_curl_http_version_opt(const char *version_string, long *opt)\n {\n \tint i;\n@@ -1003,8 +1002,6 @@ static int get_curl_http_version_opt(const char *version_string, long *opt)\n \treturn -1; /* not found */\n }\n \n-#endif\n-\n static CURL *get_curl_handle(void)\n {\n \tCURL *result = curl_easy_init();\n@@ -1022,7 +1019,6 @@ static CURL *get_curl_handle(void)\n \t\tcurl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, 2);\n \t}\n \n-#ifdef GIT_CURL_HAVE_CURL_HTTP_VERSION_2\n if (curl_http_version) {\n \t\tlong opt;\n \t\tif (!get_curl_http_version_opt(curl_http_version, &opt)) {\n@@ -1030,7 +1026,6 @@ static CURL *get_curl_handle(void)\n \t\t\tcurl_easy_setopt(result, CURLOPT_HTTP_VERSION, opt);\n \t\t}\n }\n-#endif\n \n \tcurl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);\n \tcurl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);\n"},{"id":"505891","messageId":"20241023004600.1645313-7-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241023004600.1645313-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 06/12] git-curl-compat: remove check for curl 7.44.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-23T00:45:54Z","receivedAt":"2024-10-23T00:46:07Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.44.0 was released in August 2015, which is over nine years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 9 and Ubuntu 16.04, both of which are out of\nmainstream security support, have supported a newer version, and RHEL 8,\nwhich is still in support, also has a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 10 ----------\n http.c | 4 ----\n 2 files changed, 14 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex cd970e34d6..6b05d70d42 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,16 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURLSSLOPT_NO_REVOKE was added in 7.44.0, released in August 2015.\n- *\n- * The CURLSSLOPT_NO_REVOKE is, has always been a macro, not an enum\n- * field (checked on curl version 7.78.0)\n- */\n-#if LIBCURL_VERSION_NUM >= 0x072c00\n-#define GIT_CURL_HAVE_CURLSSLOPT_NO_REVOKE 1\n-#endif\n-\n /**\n * CURLOPT_PROXY_CAINFO was added in 7.52.0, released in August 2017.\n */\ndiff --git a/http.c b/http.c\nindex 945df9a628..bdf8bf7b59 100644\n--- a/http.c\n+++ b/http.c\n@@ -1048,11 +1048,7 @@ static CURL *get_curl_handle(void)\n \n \tif (http_ssl_backend && !strcmp(\"schannel\", http_ssl_backend) &&\n \t !http_schannel_check_revoke) {\n-#ifdef GIT_CURL_HAVE_CURLSSLOPT_NO_REVOKE\n \t\tcurl_easy_setopt(result, CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE);\n-#else\n-\t\twarning(_(\"CURLSSLOPT_NO_REVOKE not supported with cURL < 7.44.0\"));\n-#endif\n \t}\n \n \tif (http_proactive_auth != PROACTIVE_AUTH_NONE)\n"},{"id":"505885","messageId":"20241023004600.1645313-9-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241023004600.1645313-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 08/12] git-curl-compat: remove check for curl 7.53.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-23T00:45:56Z","receivedAt":"2024-10-23T00:46:08Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.53.0 was released in February 2017, which is over seven years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 10 and Ubuntu 18.04, both of which are out of\nmainstream security support, have supported a newer version, and RHEL 8,\nwhich is still in support, also has a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 8 --------\n http.c | 2 --\n 2 files changed, 10 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex edee8f2ba0..65ba1ee0f8 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,14 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURL_SSLVERSION_TLSv1_3 was added in 7.53.0, released in February\n- * 2017.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x073400\n-#define GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_3 1\n-#endif\n-\n /**\n * CURLSSLSET_{NO_BACKENDS,OK,TOO_LATE,UNKNOWN_BACKEND} were added in\n * 7.56.0, released in September 2017.\ndiff --git a/http.c b/http.c\nindex 24764f1272..c5fdf1cd4c 100644\n--- a/http.c\n+++ b/http.c\n@@ -55,9 +55,7 @@ static struct {\n \t{ \"tlsv1.0\", CURL_SSLVERSION_TLSv1_0 },\n \t{ \"tlsv1.1\", CURL_SSLVERSION_TLSv1_1 },\n \t{ \"tlsv1.2\", CURL_SSLVERSION_TLSv1_2 },\n-#ifdef GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_3\n \t{ \"tlsv1.3\", CURL_SSLVERSION_TLSv1_3 },\n-#endif\n };\n static char *ssl_key;\n static char *ssl_key_type;\n"},{"id":"505886","messageId":"20241023004600.1645313-10-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241023004600.1645313-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 09/12] git-curl-compat: remove check for curl 7.56.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-23T00:45:57Z","receivedAt":"2024-10-23T00:46:08Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.56.0 was released in September 2017, which is over seven years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 10, which is out of mainstream security support,\nhas supported a newer version, and Ubuntu 20.04 and RHEL 8, which are\nstill in support, also have a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 8 --------\n http.c | 2 --\n 2 files changed, 10 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex 65ba1ee0f8..703756ba85 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,14 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURLSSLSET_{NO_BACKENDS,OK,TOO_LATE,UNKNOWN_BACKEND} were added in\n- * 7.56.0, released in September 2017.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x073800\n-#define GIT_CURL_HAVE_CURLSSLSET_NO_BACKENDS\n-#endif\n-\n /**\n * Versions before curl 7.66.0 (September 2019) required manually setting the\n * transfer-encoding for a streaming POST; after that this is handled\ndiff --git a/http.c b/http.c\nindex c5fdf1cd4c..4d59f11ad2 100644\n--- a/http.c\n+++ b/http.c\n@@ -1275,7 +1275,6 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)\n \tfree(normalized_url);\n \tstring_list_clear(&config.vars, 1);\n \n-#ifdef GIT_CURL_HAVE_CURLSSLSET_NO_BACKENDS\n \tif (http_ssl_backend) {\n \t\tconst curl_ssl_backend **backends;\n \t\tstruct strbuf buf = STRBUF_INIT;\n@@ -1300,7 +1299,6 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)\n \t\t\tbreak; /* Okay! */\n \t\t}\n \t}\n-#endif\n \n \tif (curl_global_init(CURL_GLOBAL_ALL) != CURLE_OK)\n \t\tdie(\"curl_global_init failed\");\n"},{"id":"505887","messageId":"20241023004600.1645313-13-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241023004600.1645313-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 12/12] gitweb: make use of s///r","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-23T00:46:00Z","receivedAt":"2024-10-23T00:46:08Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"In Perl 5.14, released in May 2011, the r modifier was added to the s///\noperator to allow it to return the modified string instead of modifying\nthe string in place. This allows to write nicer, more succinct code in\nseveral cases, so let's do that here.\n\nSigned-off-by: brian m. carlson \n---\n gitweb/gitweb.perl | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex da1486cab2..c4e0008d59 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -1188,7 +1188,7 @@ sub evaluate_and_validate_params {\n \t\tif ($search_use_regexp) {\n \t\t\t$search_regexp = $searchtext;\n \t\t\tif (!eval { qr/$search_regexp/; 1; }) {\n-\t\t\t\t(my $error = $@) =~ s/ at \\S+ line \\d+.*\\n?//;\n+\t\t\t\tmy $error = $@ =~ s/ at \\S+ line \\d+.*\\n?//r;\n \t\t\t\tdie_error(400, \"Invalid search regexp '$search_regexp'\",\n \t\t\t\t esc_html($error));\n \t\t\t}\n@@ -2700,7 +2700,7 @@ sub git_cmd {\n # Try to avoid using this function wherever possible.\n sub quote_command {\n \treturn join(' ',\n-\t\tmap { my $a = $_; $a =~ s/(['!])/'\\\\$1'/g; \"'$a'\" } @_ );\n+\t\tmap { my $a = $_ =~ s/(['!])/'\\\\$1'/gr; \"'$a'\" } @_ );\n }\n \n # get HEAD ref of given project as hash\n"},{"id":"505888","messageId":"20241023004600.1645313-11-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241023004600.1645313-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 10/12] INSTALL: document requirement for libcurl 7.61.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-23T00:45:58Z","receivedAt":"2024-10-23T00:46:08Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Our platform support policy states that we require \"versions of\ndependencies which are generally accepted as stable and supportable,\ne.g., in line with the version used by other long-term-support\ndistributions\". Of Debian, Ubuntu, and RHEL, the three most common\ndistributions that provide LTS versions, the version with mainstream\nlong-term security support with the oldest libcurl is 7.61.0 in RHEL 8.\n\nUpdate the documentation to state that this is the new base version for\nlibcurl. Remove text that is no longer applicable to older versions.\n\nSigned-off-by: brian m. carlson \n---\n INSTALL | 11 +++--------\n 1 file changed, 3 insertions(+), 8 deletions(-)\n\ndiff --git a/INSTALL b/INSTALL\nindex 2a46d04592..6e0321ff0e 100644\n--- a/INSTALL\n+++ b/INSTALL\n@@ -129,17 +129,12 @@ Issues of note:\n \t itself, e.g. Digest::MD5, File::Spec, File::Temp, Net::Domain,\n \t Net::SMTP, and Time::HiRes.\n \n-\t- git-imap-send needs the OpenSSL library to talk IMAP over SSL if\n-\t you are using libcurl older than 7.34.0. Otherwise you can use\n-\t NO_OPENSSL without losing git-imap-send.\n-\n \t- \"libcurl\" library is used for fetching and pushing\n \t repositories over http:// or https://, as well as by\n-\t git-imap-send if the curl version is >= 7.34.0. If you do\n-\t not need that functionality, use NO_CURL to build without\n-\t it.\n+\t git-imap-send. If you do not need that functionality,\n+\t use NO_CURL to build without it.\n \n-\t Git requires version \"7.21.3\" or later of \"libcurl\" to build\n+\t Git requires version \"7.61.0\" or later of \"libcurl\" to build\n \t without NO_CURL. This version requirement may be bumped in\n \t the future.\n \n"},{"id":"505889","messageId":"20241023004600.1645313-12-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241023004600.1645313-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 11/12] Require Perl 5.26.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-23T00:45:59Z","receivedAt":"2024-10-23T00:46:08Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Our platform support policy states that we require \"versions of\ndependencies which are generally accepted as stable and supportable,\ne.g., in line with the version used by other long-term-support\ndistributions\". Of Debian, Ubuntu, RHEL, and SLES, the four most common\ndistributions that provide LTS versions, the version with mainstream\nlong-term security support with the oldest Perl is 5.26.0 in SLES 15.6.\n\nThis is a major upgrade, since Perl 5.8.1, according to the Perl\ndocumentation, was released in September of 2003. It brings a lot of\nnew features that we can choose to use, such as s///r to return the\nmodified string, the postderef functionality, and subroutine signatures,\nalthough the latter was still considered experimental until 5.36.\n\nThis change was made with the following one-liner, which intentionally\nexcludes modifying the vendored modules we include to avoid conflicts:\n\n git grep -l 'use 5.008001' | grep -v 'LoadCPAN/' | xargs perl -pi -e 's/use 5.008001/require v5.26/'\n\nUse require instead of use to avoid changing the behavior as the latter\nenables features and the former does not.\n\nSigned-off-by: brian m. carlson \n---\n INSTALL | 2 +-\n contrib/diff-highlight/DiffHighlight.pm | 2 +-\n contrib/mw-to-git/Git/Mediawiki.pm | 2 +-\n git-archimport.perl | 2 +-\n git-cvsexportcommit.perl | 2 +-\n git-cvsimport.perl | 2 +-\n git-cvsserver.perl | 2 +-\n git-send-email.perl | 2 +-\n git-svn.perl | 2 +-\n gitweb/gitweb.perl | 2 +-\n perl/Git.pm | 2 +-\n perl/Git/I18N.pm | 2 +-\n perl/Git/LoadCPAN.pm | 2 +-\n perl/Git/Packet.pm | 2 +-\n t/t0202/test.pl | 2 +-\n t/t5562/invoke-with-content-length.pl | 2 +-\n t/t9700/test.pl | 2 +-\n t/test-terminal.perl | 2 +-\n 18 files changed, 18 insertions(+), 18 deletions(-)\n\ndiff --git a/INSTALL b/INSTALL\nindex 6e0321ff0e..54d7528f9e 100644\n--- a/INSTALL\n+++ b/INSTALL\n@@ -119,7 +119,7 @@ Issues of note:\n \t- A POSIX-compliant shell is required to run some scripts needed\n \t for everyday use (e.g. \"bisect\", \"request-pull\").\n \n-\t- \"Perl\" version 5.8.1 or later is needed to use some of the\n+\t- \"Perl\" version 5.26.0 or later is needed to use some of the\n \t features (e.g. sending patches using \"git send-email\",\n \t interacting with svn repositories with \"git svn\"). If you can\n \t live without these, use NO_PERL. Note that recent releases of\ndiff --git a/contrib/diff-highlight/DiffHighlight.pm b/contrib/diff-highlight/DiffHighlight.pm\nindex 636add6968..3d061bc0b7 100644\n--- a/contrib/diff-highlight/DiffHighlight.pm\n+++ b/contrib/diff-highlight/DiffHighlight.pm\n@@ -1,6 +1,6 @@\n package DiffHighlight;\n \n-use 5.008001;\n+require v5.26;\n use warnings FATAL => 'all';\n use strict;\n \ndiff --git a/contrib/mw-to-git/Git/Mediawiki.pm b/contrib/mw-to-git/Git/Mediawiki.pm\nindex ff7811225e..629c0cea44 100644\n--- a/contrib/mw-to-git/Git/Mediawiki.pm\n+++ b/contrib/mw-to-git/Git/Mediawiki.pm\n@@ -1,6 +1,6 @@\n package Git::Mediawiki;\n \n-use 5.008001;\n+require v5.26;\n use strict;\n use POSIX;\n use Git;\ndiff --git a/git-archimport.perl b/git-archimport.perl\nindex f5a317b899..6d0169cb6a 100755\n--- a/git-archimport.perl\n+++ b/git-archimport.perl\n@@ -54,7 +54,7 @@ =head1 Devel Notes\n \n =cut\n \n-use 5.008001;\n+require v5.26;\n use strict;\n use warnings;\n use Getopt::Std;\ndiff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl\nindex 1e03ba94d1..edf02f9964 100755\n--- a/git-cvsexportcommit.perl\n+++ b/git-cvsexportcommit.perl\n@@ -1,6 +1,6 @@\n #!/usr/bin/perl\n \n-use 5.008001;\n+require v5.26;\n use strict;\n use warnings;\n use Getopt::Std;\ndiff --git a/git-cvsimport.perl b/git-cvsimport.perl\nindex 211ec8459a..e10ad5334e 100755\n--- a/git-cvsimport.perl\n+++ b/git-cvsimport.perl\n@@ -13,7 +13,7 @@\n # The head revision is on branch \"origin\" by default.\n # You can change that with the '-o' option.\n \n-use 5.008001;\n+require v5.26;\n use strict;\n use warnings;\n use Getopt::Long;\ndiff --git a/git-cvsserver.perl b/git-cvsserver.perl\nindex 124f598bdc..a4ad9a5d2d 100755\n--- a/git-cvsserver.perl\n+++ b/git-cvsserver.perl\n@@ -15,7 +15,7 @@\n ####\n ####\n \n-use 5.008001;\n+require v5.26;\n use strict;\n use warnings;\n use bytes;\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex c835d4c11a..c4d12bebc8 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -16,7 +16,7 @@\n # and second line is the subject of the message.\n #\n \n-use 5.008001;\n+require v5.26;\n use strict;\n use warnings $ENV{GIT_PERL_FATAL_WARNINGS} ? qw(FATAL all) : ();\n use Getopt::Long;\ndiff --git a/git-svn.perl b/git-svn.perl\nindex 01e7a70de1..9c7c629932 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -1,7 +1,7 @@\n #!/usr/bin/perl\n # Copyright (C) 2006, Eric Wong \n # License: GPL v2 or later\n-use 5.008001;\n+require v5.26;\n use warnings $ENV{GIT_PERL_FATAL_WARNINGS} ? qw(FATAL all) : ();\n use strict;\n use vars qw/\t$AUTHOR $VERSION\ndiff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl\nindex b09a8d0523..da1486cab2 100755\n--- a/gitweb/gitweb.perl\n+++ b/gitweb/gitweb.perl\n@@ -7,7 +7,7 @@\n #\n # This program is licensed under the GPLv2\n \n-use 5.008001;\n+require v5.26;\n use strict;\n use warnings;\n # handle ACL in file access tests\ndiff --git a/perl/Git.pm b/perl/Git.pm\nindex 667152c6c6..6f47d653ab 100644\n--- a/perl/Git.pm\n+++ b/perl/Git.pm\n@@ -7,7 +7,7 @@ =head1 NAME\n \n package Git;\n \n-use 5.008001;\n+require v5.26;\n use strict;\n use warnings $ENV{GIT_PERL_FATAL_WARNINGS} ? qw(FATAL all) : ();\n \ndiff --git a/perl/Git/I18N.pm b/perl/Git/I18N.pm\nindex 475e90a6df..ab46edb608 100644\n--- a/perl/Git/I18N.pm\n+++ b/perl/Git/I18N.pm\n@@ -1,5 +1,5 @@\n package Git::I18N;\n-use 5.008001;\n+require v5.26;\n use strict;\n use warnings $ENV{GIT_PERL_FATAL_WARNINGS} ? qw(FATAL all) : ();\n BEGIN {\ndiff --git a/perl/Git/LoadCPAN.pm b/perl/Git/LoadCPAN.pm\nindex 8c7fa805f9..61254fddbb 100644\n--- a/perl/Git/LoadCPAN.pm\n+++ b/perl/Git/LoadCPAN.pm\n@@ -1,5 +1,5 @@\n package Git::LoadCPAN;\n-use 5.008001;\n+require v5.26;\n use strict;\n use warnings $ENV{GIT_PERL_FATAL_WARNINGS} ? qw(FATAL all) : ();\n \ndiff --git a/perl/Git/Packet.pm b/perl/Git/Packet.pm\nindex d896e69523..00fd9c484a 100644\n--- a/perl/Git/Packet.pm\n+++ b/perl/Git/Packet.pm\n@@ -1,5 +1,5 @@\n package Git::Packet;\n-use 5.008001;\n+require v5.26;\n use strict;\n use warnings $ENV{GIT_PERL_FATAL_WARNINGS} ? qw(FATAL all) : ();\n BEGIN {\ndiff --git a/t/t0202/test.pl b/t/t0202/test.pl\nindex 47d96a2a13..5085a0eda5 100755\n--- a/t/t0202/test.pl\n+++ b/t/t0202/test.pl\n@@ -1,5 +1,5 @@\n #!/usr/bin/perl\n-use 5.008001;\n+require v5.26;\n use lib (split(/:/, $ENV{GITPERLLIB}));\n use strict;\n use warnings;\ndiff --git a/t/t5562/invoke-with-content-length.pl b/t/t5562/invoke-with-content-length.pl\nindex 9babb9a375..211e29fade 100644\n--- a/t/t5562/invoke-with-content-length.pl\n+++ b/t/t5562/invoke-with-content-length.pl\n@@ -1,4 +1,4 @@\n-use 5.008001;\n+require v5.26;\n use strict;\n use warnings;\n \ndiff --git a/t/t9700/test.pl b/t/t9700/test.pl\nindex 2e1d50d4d1..58a9b328d5 100755\n--- a/t/t9700/test.pl\n+++ b/t/t9700/test.pl\n@@ -1,7 +1,7 @@\n #!/usr/bin/perl\n use lib (split(/:/, $ENV{GITPERLLIB}));\n \n-use 5.008001;\n+require v5.26;\n use warnings;\n use strict;\n \ndiff --git a/t/test-terminal.perl b/t/test-terminal.perl\nindex b8fd6a4f13..862bb8f395 100755\n--- a/t/test-terminal.perl\n+++ b/t/test-terminal.perl\n@@ -1,5 +1,5 @@\n #!/usr/bin/perl\n-use 5.008001;\n+require v5.26;\n use strict;\n use warnings;\n use IO::Pty;\n"},{"id":"505890","messageId":"20241023004600.1645313-8-sandals@crustytoothpaste.net","threadId":"62308","inReplyTo":"20241023004600.1645313-1-sandals@crustytoothpaste.net","subject":"[PATCH v2 07/12] git-curl-compat: remove check for curl 7.52.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-23T00:45:55Z","receivedAt":"2024-10-23T00:46:08Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"libcurl 7.52.0 was released in August 2017, which is over seven years\nago, and no major operating system vendor is still providing security\nsupport for it. Debian 9 and Ubuntu 18.04, both of which are out of\nmainstream security support, have supported a newer version, and RHEL 8,\nwhich is still in support, also has a newer version.\n\nRemove the check for this version and use this functionality\nunconditionally.\n\nSigned-off-by: brian m. carlson \n---\n git-curl-compat.h | 15 ---------------\n http.c | 8 --------\n 2 files changed, 23 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex 6b05d70d42..edee8f2ba0 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,21 +28,6 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n-/**\n- * CURLOPT_PROXY_CAINFO was added in 7.52.0, released in August 2017.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x073400\n-#define GIT_CURL_HAVE_CURLOPT_PROXY_CAINFO 1\n-#endif\n-\n-/**\n- * CURLOPT_PROXY_{KEYPASSWD,SSLCERT,SSLKEY} was added in 7.52.0,\n- * released in August 2017.\n- */\n-#if LIBCURL_VERSION_NUM >= 0x073400\n-#define GIT_CURL_HAVE_CURLOPT_PROXY_KEYPASSWD 1\n-#endif\n-\n /**\n * CURL_SSLVERSION_TLSv1_3 was added in 7.53.0, released in February\n * 2017.\ndiff --git a/http.c b/http.c\nindex bdf8bf7b59..24764f1272 100644\n--- a/http.c\n+++ b/http.c\n@@ -691,7 +691,6 @@ static int has_cert_password(void)\n \treturn 1;\n }\n \n-#ifdef GIT_CURL_HAVE_CURLOPT_PROXY_KEYPASSWD\n static int has_proxy_cert_password(void)\n {\n \tif (http_proxy_ssl_cert == NULL || proxy_ssl_cert_password_required != 1)\n@@ -705,7 +704,6 @@ static int has_proxy_cert_password(void)\n \t}\n \treturn 1;\n }\n-#endif\n \n static void set_curl_keepalive(CURL *c)\n {\n@@ -1093,16 +1091,12 @@ static CURL *get_curl_handle(void)\n \tif (http_ssl_backend && !strcmp(\"schannel\", http_ssl_backend) &&\n \t !http_schannel_use_ssl_cainfo) {\n \t\tcurl_easy_setopt(result, CURLOPT_CAINFO, NULL);\n-#ifdef GIT_CURL_HAVE_CURLOPT_PROXY_CAINFO\n \t\tcurl_easy_setopt(result, CURLOPT_PROXY_CAINFO, NULL);\n-#endif\n \t} else if (ssl_cainfo != NULL || http_proxy_ssl_ca_info != NULL) {\n \t\tif (ssl_cainfo)\n \t\t\tcurl_easy_setopt(result, CURLOPT_CAINFO, ssl_cainfo);\n-#ifdef GIT_CURL_HAVE_CURLOPT_PROXY_CAINFO\n \t\tif (http_proxy_ssl_ca_info)\n \t\t\tcurl_easy_setopt(result, CURLOPT_PROXY_CAINFO, http_proxy_ssl_ca_info);\n-#endif\n \t}\n \n \tif (curl_low_speed_limit > 0 && curl_low_speed_time > 0) {\n@@ -1198,7 +1192,6 @@ static CURL *get_curl_handle(void)\n \t\telse if (starts_with(curl_http_proxy, \"socks\"))\n \t\t\tcurl_easy_setopt(result,\n \t\t\t\tCURLOPT_PROXYTYPE, CURLPROXY_SOCKS4);\n-#ifdef GIT_CURL_HAVE_CURLOPT_PROXY_KEYPASSWD\n \t\telse if (starts_with(curl_http_proxy, \"https\")) {\n \t\t\tcurl_easy_setopt(result, CURLOPT_PROXYTYPE, CURLPROXY_HTTPS);\n \n@@ -1211,7 +1204,6 @@ static CURL *get_curl_handle(void)\n \t\t\tif (has_proxy_cert_password())\n \t\t\t\tcurl_easy_setopt(result, CURLOPT_PROXY_KEYPASSWD, proxy_cert_auth.password);\n \t\t}\n-#endif\n \t\tif (strstr(curl_http_proxy, \"://\"))\n \t\t\tcredential_from_url(&proxy_auth, curl_http_proxy);\n \t\telse {\n"},{"id":"505892","messageId":"010f01db24e9$00250e50$006f2af0$@nexbridge.com","threadId":"62308","inReplyTo":"20241023004600.1645313-12-sandals@crustytoothpaste.net","subject":"RE: [PATCH v2 11/12] Require Perl 5.26.0","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-10-23T01:15:02Z","receivedAt":"2024-10-23T01:20:31Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 22, 2024 8:46 PM, brian m. carlson wrote:\n>Our platform support policy states that we require \"versions of\ndependencies which\n>are generally accepted as stable and supportable, e.g., in line with the\nversion used\n>by other long-term-support distributions\". Of Debian, Ubuntu, RHEL, and\nSLES, the\n>four most common distributions that provide LTS versions, the version with\n>mainstream long-term security support with the oldest Perl is 5.26.0 in\nSLES 15.6.\n>\n>This is a major upgrade, since Perl 5.8.1, according to the Perl\ndocumentation, was\n>released in September of 2003. It brings a lot of new features that we can\nchoose\n>to use, such as s///r to return the modified string, the postderef\nfunctionality, and\n>subroutine signatures, although the latter was still considered\nexperimental until\n>5.36.\n>\n>This change was made with the following one-liner, which intentionally\nexcludes\n>modifying the vendored modules we include to avoid conflicts:\n>\n> git grep -l 'use 5.008001' | grep -v 'LoadCPAN/' | xargs perl -pi -e\n's/use\n>5.008001/require v5.26/'\n>\n>Use require instead of use to avoid changing the behavior as the latter\nenables\n>features and the former does not.\n>\n>Signed-off-by: brian m. carlson \n\nPlease be aware that the most recent version of Perl available on NonStop is\ncurrently\n5.26.3. On the ia64 variant, we will not see a newer version *ever*. The x86\nplatform\nSupports 5.30.3 and may evolve. By the end of 2025, the ia64 platform goes\naway, so\nas long as we can keep 5.26.x as a minimum, that would be acceptable.\n\nThanks,\nRandall\n\n"},{"id":"505926","messageId":"ZxjtRXf8IUrvn1tK@ugly","threadId":"62308","inReplyTo":"20241023004600.1645313-13-sandals@crustytoothpaste.net","subject":"Re: [PATCH v2 12/12] gitweb: make use of s///r","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2024-10-23T12:34:13Z","receivedAt":"2024-10-23T12:34:23Z","isPatch":true,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Wed, Oct 23, 2024 at 12:46:00AM +0000, brian m. carlson wrote:\n>In Perl 5.14, released in May 2011, the r modifier was added to the s///\n>operator to allow it to return the modified string instead of modifying\n>the string in place.\n\n>This allows to write nicer, more succinct code in\n>several cases, so let's do that here.\n>\n\"several\" is a bit of an overstatement.\n\n>+++ b/gitweb/gitweb.perl\n>@@ -1188,7 +1188,7 @@ sub evaluate_and_validate_params {\n>-\t\t\t\t(my $error = $@) =~ s/ at \\S+ line \\d+.*\\n?//;\n>+\t\t\t\tmy $error = $@ =~ s/ at \\S+ line \\d+.*\\n?//r;\n>\ni'm a fan of \"excess\" parentheses where the syntax relies heavily on\nthe binding and priority of operators:\n\n my $error = ($@ =~ s/ at \\S+ line \\d+.*\\n?//r);\n\nwhich is arguably semantically clearer than the old idiom, but not shorter.\n\n>@@ -2700,7 +2700,7 @@ sub git_cmd {\n>-\t\tmap { my $a = $_; $a =~ s/(['!])/'\\\\$1'/g; \"'$a'\" } @_ );\n>+\t\tmap { my $a = $_ =~ s/(['!])/'\\\\$1'/gr; \"'$a'\" } @_ );\n>\ni think\n\n map { \"'\".(s/(['!])/'\\\\$1'/gr).\"'\" } @_ );\n\nshould work, and is an actually significant improvement.\n"},{"id":"505972","messageId":"ZxlZuxllqjAZfAZm@nand.local","threadId":"62308","inReplyTo":"20241023004600.1645313-1-sandals@crustytoothpaste.net","subject":"Re: [PATCH v2 00/12] Update versions of libcurl and Perl","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-10-23T20:16:59Z","receivedAt":"2024-10-23T20:17:01Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Oct 23, 2024 at 12:45:48AM +0000, brian m. carlson wrote:\n> brian m. carlson (12):\n> git-curl-compat: remove check for curl 7.21.5\n> git-curl-compat: remove check for curl 7.25.0\n> git-curl-compat: remove check for curl 7.34.0\n> git-curl-compat: remove check for curl 7.39.0\n> git-curl-compat: remove check for curl 7.43.0\n> git-curl-compat: remove check for curl 7.44.0\n> git-curl-compat: remove check for curl 7.52.0\n> git-curl-compat: remove check for curl 7.53.0\n> git-curl-compat: remove check for curl 7.56.0\n> INSTALL: document requirement for libcurl 7.61.0\n> Require Perl 5.26.0\n> gitweb: make use of s///r\n\nThanks, queued.\n\nThanks,\nTaylor\n"},{"id":"505999","messageId":"Zxnjt2QVwVTsYwvW@pks.im","threadId":"62308","inReplyTo":"ZxlZuxllqjAZfAZm@nand.local","subject":"Re: [PATCH v2 00/12] Update versions of libcurl and Perl","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-10-24T06:05:49Z","receivedAt":"2024-10-24T06:05:56Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Oct 23, 2024 at 04:16:59PM -0400, Taylor Blau wrote:\n> On Wed, Oct 23, 2024 at 12:45:48AM +0000, brian m. carlson wrote:\n> > brian m. carlson (12):\n> > git-curl-compat: remove check for curl 7.21.5\n> > git-curl-compat: remove check for curl 7.25.0\n> > git-curl-compat: remove check for curl 7.34.0\n> > git-curl-compat: remove check for curl 7.39.0\n> > git-curl-compat: remove check for curl 7.43.0\n> > git-curl-compat: remove check for curl 7.44.0\n> > git-curl-compat: remove check for curl 7.52.0\n> > git-curl-compat: remove check for curl 7.53.0\n> > git-curl-compat: remove check for curl 7.56.0\n> > INSTALL: document requirement for libcurl 7.61.0\n> > Require Perl 5.26.0\n> > gitweb: make use of s///r\n> \n> Thanks, queued.\n\nNote that this still breaks GitLab CI, as we exercise Ubuntu 16.04 there\nwhich doesn't have recent-enough versions of curl. This version has\nrecently moved into Extended Security Maintenance mode, so the next LTS\nrelease would be Ubuntu 20.04.\n\nSo if this gets merged we should add something like the below patch on\ntop.\n\nPatrick\n\ndiff --git a/.gitlab-ci.yml b/.gitlab-ci.yml\nindex 4abfbc3e208..64f7ec5a2dd 100644\n--- a/.gitlab-ci.yml\n+++ b/.gitlab-ci.yml\n@@ -28,7 +28,7 @@ test:linux:\n parallel:\n matrix:\n - jobname: linux-old\n- image: ubuntu:16.04\n+ image: ubuntu:20.04\n CC: gcc\n - jobname: linux-sha256\n image: ubuntu:latest\n"},{"id":"506074","messageId":"ZxrBidBicBcipo5R@tapette.crustytoothpaste.net","threadId":"62308","inReplyTo":"ZxjtRXf8IUrvn1tK@ugly","subject":"Re: [PATCH v2 12/12] gitweb: make use of s///r","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-24T21:52:09Z","receivedAt":"2024-10-24T21:52:16Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-10-23 at 12:34:13, Oswald Buddenhagen wrote:\n> On Wed, Oct 23, 2024 at 12:46:00AM +0000, brian m. carlson wrote:\n> > In Perl 5.14, released in May 2011, the r modifier was added to the s///\n> > operator to allow it to return the modified string instead of modifying\n> > the string in place.\n> \n> > This allows to write nicer, more succinct code in\n> > several cases, so let's do that here.\n> > \n> \"several\" is a bit of an overstatement.\n\nI can rephrase if a v3 is necessary.\n\n> > +++ b/gitweb/gitweb.perl\n> > @@ -1188,7 +1188,7 @@ sub evaluate_and_validate_params {\n> > -\t\t\t\t(my $error = $@) =~ s/ at \\S+ line \\d+.*\\n?//;\n> > +\t\t\t\tmy $error = $@ =~ s/ at \\S+ line \\d+.*\\n?//r;\n> > \n> i'm a fan of \"excess\" parentheses where the syntax relies heavily on\n> the binding and priority of operators:\n> \n> my $error = ($@ =~ s/ at \\S+ line \\d+.*\\n?//r);\n> \n> which is arguably semantically clearer than the old idiom, but not shorter.\n\nI don't think those are necessary. It's obvious to people who use the\ns///r idiom what's meant here, and in my experience most Perl code using\nthat idiom doesn't use them.\n\n> > @@ -2700,7 +2700,7 @@ sub git_cmd {\n> > -\t\tmap { my $a = $_; $a =~ s/(['!])/'\\\\$1'/g; \"'$a'\" } @_ );\n> > +\t\tmap { my $a = $_ =~ s/(['!])/'\\\\$1'/gr; \"'$a'\" } @_ );\n> > \n> i think\n> \n> map { \"'\".(s/(['!])/'\\\\$1'/gr).\"'\" } @_ );\n> \n> should work, and is an actually significant improvement.\n\nI'm sorry, I don't necessarily like that much better than what we have\nnow. It's not that I think it's awful, just that I don't think it's a\nsignificant improvement. If I do a v3, I can omit the `$_ =~`, though.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"506075","messageId":"ZxrBzT6lE47m_3Ia@tapette.crustytoothpaste.net","threadId":"62308","inReplyTo":"Zxnjt2QVwVTsYwvW@pks.im","subject":"Re: [PATCH v2 00/12] Update versions of libcurl and Perl","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-10-24T21:53:17Z","receivedAt":"2024-10-24T21:53:19Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-10-24 at 06:05:49, Patrick Steinhardt wrote:\n> Note that this still breaks GitLab CI, as we exercise Ubuntu 16.04 there\n> which doesn't have recent-enough versions of curl. This version has\n> recently moved into Extended Security Maintenance mode, so the next LTS\n> release would be Ubuntu 20.04.\n\nYes, I think we should add that on top. I don't believe we should be\ntesting or supporting Ubuntu 16.04, so 20.04 would be the right version\nto choose.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"}]}