{"thread":{"id":"58096","subject":"[PATCH] http: support building on RHEL6","startedAt":"2022-07-01T16:24:16Z","lastAt":"2022-07-05T17:46:54Z","messageCount":6,"participants":["Johannes Schindelin via GitGitGadget","brian m. carlson","Junio C Hamano","Ævar Arnfjörð Bjarmason"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"458390","messageId":"pull.1277.git.1656692646303.gitgitgadget@gmail.com","threadId":"58096","inReplyTo":null,"subject":"[PATCH] http: support building on RHEL6","fromName":"Johannes Schindelin via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-07-01T16:24:06Z","receivedAt":"2022-07-01T16:24:16Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"From: Johannes Schindelin \n\nThere was a bug report attached to the copy of 511cfd3bffa (http: add\ncustom hostname to IP address resolutions, 2022-05-16) in the `git/git`\nrepository on GitHub, claiming that that commit broke the build on\nRedHat Enterprise Linux 6. The most likely explanation is that the\navailable cURL version does not support the `CURLOPT_RESOLVE` feature.\n\nLet's work around this by warning the user if they configure\n`http.curloptResolve` if compiled against a too-old cURL version.\n\nSigned-off-by: Johannes Schindelin \n---\n http: support building on RHEL6\n \n This came in via the awkward venue of a commit comment at\n https://github.com/git/git/commit/511cfd3bffa685fda0e7c25bfa08082aa0de3a30#commitcomment-77360864.\n \n I looked here [https://curl.se/libcurl/c/CURLOPT_RESOLVE.html] to find\n out since when cURL supports CURLOPT_RESOLVE.\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-1277%2Fdscho%2Fcurlopt_resolve-in-rhel6-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1277/dscho/curlopt_resolve-in-rhel6-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/1277\n\n git-curl-compat.h | 7 +++++++\n http.c | 5 +++++\n 2 files changed, 12 insertions(+)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex 56a83b6bbd8..80315e731d7 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -28,6 +28,13 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n+/**\n+ ** CURLOPT_RESOLVE was added in 7.21.3, released in December 2010.\n+ */\n+#if LIBCURL_VERSION_NUM >= 0x071503\n+#define GIT_CURL_HAVE_CURLOPT_RESOLVE 1\n+#endif\n+\n /**\n * CURL_SOCKOPT_OK was added in 7.21.5, released in April 2011.\n */\ndiff --git a/http.c b/http.c\nindex 168ca30c558..4c7a2311ec8 100644\n--- a/http.c\n+++ b/http.c\n@@ -1228,7 +1228,12 @@ struct active_request_slot *get_active_slot(void)\n \tif (curl_save_cookies)\n \t\tcurl_easy_setopt(slot->curl, CURLOPT_COOKIEJAR, curl_cookie_file);\n \tcurl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, pragma_header);\n+#ifdef GIT_CURL_HAVE_CURLOPT_RESOLVE\n \tcurl_easy_setopt(slot->curl, CURLOPT_RESOLVE, host_resolutions);\n+#else\n+\tif (host_resolutions)\n+\t\twarning(_(\"lacking support for `http.curloptResolve`\"));\n+#endif\n \tcurl_easy_setopt(slot->curl, CURLOPT_ERRORBUFFER, curl_errorstr);\n \tcurl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, NULL);\n \tcurl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, NULL);\n\nbase-commit: e4a4b31577c7419497ac30cebe30d755b97752c5\n-- \ngitgitgadget\n"},{"id":"458392","messageId":"Yr8kfCqKHwO1QqS6@tapette.crustytoothpaste.net","threadId":"58096","inReplyTo":"pull.1277.git.1656692646303.gitgitgadget@gmail.com","subject":"Re: [PATCH] http: support building on RHEL6","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-07-01T16:44:44Z","receivedAt":"2022-07-01T16:44:50Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-07-01 at 16:24:06, Johannes Schindelin via GitGitGadget wrote:\n> From: Johannes Schindelin \n> \n> There was a bug report attached to the copy of 511cfd3bffa (http: add\n> custom hostname to IP address resolutions, 2022-05-16) in the `git/git`\n> repository on GitHub, claiming that that commit broke the build on\n> RedHat Enterprise Linux 6. The most likely explanation is that the\n> available cURL version does not support the `CURLOPT_RESOLVE` feature.\n> \n> Let's work around this by warning the user if they configure\n> `http.curloptResolve` if compiled against a too-old cURL version.\n\nI don't think it's a good idea to continue to support RHEL 6. It lost\nregular security support in 2020 and I think it's fine and even\npreferable to force people to upgrade their OS once every decade. 10\nyears is, in my view, well beyond the reasonable life span of an OS.\n\nThere's no possible way that any Git developer can be expected to\nsupport RHEL 6 because it has no publicly available security support[0] and\nwe can't expect developers to run or use insecure OSes at all. It's\nalso irresponsible of us to enable people to use such an OS considering\nthe likelihood of compromise is substantial and the risk compromised\nsystems pose to the Internet, so I think we should drop this patch.\n\n[0] Yes, there is _extended_ security support until 2024, but that's not\navailable to people who aren't already RHEL 6 users and it doesn't cover\ndependencies such as libcurl or Perl that are required to effectively\nuse Git.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"458420","messageId":"xmqqpmio7c3m.fsf@gitster.g","threadId":"58096","inReplyTo":"Yr8kfCqKHwO1QqS6@tapette.crustytoothpaste.net","subject":"Re: [PATCH] http: support building on RHEL6","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-01T21:32:45Z","receivedAt":"2022-07-01T21:32:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> On 2022-07-01 at 16:24:06, Johannes Schindelin via GitGitGadget wrote:\n>> From: Johannes Schindelin \n>> \n>> There was a bug report attached to the copy of 511cfd3bffa (http: add\n>> custom hostname to IP address resolutions, 2022-05-16) in the `git/git`\n>> repository on GitHub, claiming that that commit broke the build on\n>> RedHat Enterprise Linux 6. The most likely explanation is that the\n>> available cURL version does not support the `CURLOPT_RESOLVE` feature.\n>> \n>> Let's work around this by warning the user if they configure\n>> `http.curloptResolve` if compiled against a too-old cURL version.\n>\n> I don't think it's a good idea to continue to support RHEL 6. It lost\n> regular security support in 2020 and I think it's fine and even\n> preferable to force people to upgrade their OS once every decade. 10\n> years is, in my view, well beyond the reasonable life span of an OS.\n>\n> There's no possible way that any Git developer can be expected to\n> support RHEL 6 because it has no publicly available security support[0] and\n> we can't expect developers to run or use insecure OSes at all. It's\n> also irresponsible of us to enable people to use such an OS considering\n> the likelihood of compromise is substantial and the risk compromised\n> systems pose to the Internet, so I think we should drop this patch.\n\nI agree with you that justifying the change to support RHEL6 is a\nbad idea, because it is a bad idea to encourage the continued use of\nplatform that is unsupported by the publisher.\n\nBut I do not think the patch text, what the patch does, is that bad.\nWe advertise in INSTALL that you need 7.19.4 to build without NO_CURL;\nIOW, you should be able to build Git with 7.21.3 or later.\n\n> [0] Yes, there is _extended_ security support until 2024, but that's not\n> available to people who aren't already RHEL 6 users and it doesn't cover\n> dependencies such as libcurl or Perl that are required to effectively\n> use Git.\n\nIt is a different problem if RHEL6 has cURL 7.19.4 or later. I do\nnot know the answer to that question.\n\nTaking all of the above into account, I would say that the patch\ntext is OK and we should mention that the original complaint came\nfrom a user who tried to build Git with RHEL6, but we should make\nthis change not because we want to keep Git working on that\nplatform. Instead, justify the change because we should follow the\npromise we made in INSTALL to support libCURL version 7.19.4 or\nlater\n\nBy the way, I do not see anything to notice an attempt to use\nlibCURL that is too old. I wonder if the attached patch is worth\nconsidering.\n\nThanks.\n\n----- >8 --------- >8 --------- >8 --------- >8 --------- >8 -----\nSubject: libcurl: document and enforce the lowest supported version\n\nIn INSTALL, we promise that certain version of libCURL is usable to\nbuild git with, but there was nothing that ensures we are not built\nwith a version that is too old. We may be lucky and the compiler\nmay choke on a missing function, global variable, or preprocessor\nconstant in such a case, but it may be more helpful to the users to\ngive an explicit error message that says the lowest version we\nsupport.\n\nSigned-off-by: Junio C Hamano \n---\n INSTALL | 2 +-\n git-curl-compat.h | 11 ++++++++---\n 2 files changed, 9 insertions(+), 4 deletions(-)\n\ndiff --git c/INSTALL w/INSTALL\nindex 4140a3f5c8..d9c83f30c5 100644\n--- c/INSTALL\n+++ w/INSTALL\n@@ -146,7 +146,7 @@ Issues of note:\n \n \t Git requires version \"7.19.4\" or later of \"libcurl\" to build\n \t without NO_CURL. This version requirement may be bumped in\n-\t the future.\n+\t the future in the file.\n \n \t- \"expat\" library; git-http-push uses it for remote lock\n \t management over DAV. Similar to \"curl\" above, this is optional\ndiff --git c/git-curl-compat.h w/git-curl-compat.h\nindex 56a83b6bbd..6eda37ea5a 100644\n--- c/git-curl-compat.h\n+++ w/git-curl-compat.h\n@@ -8,9 +8,6 @@\n * inform decisions about removing support for older libcurl in the\n * future.\n *\n- * The oldest supported version of curl is documented in the \"INSTALL\"\n- * document.\n- *\n * The source of truth for what versions have which symbols is\n * https://github.com/curl/curl/blob/master/docs/libcurl/symbols-in-versions;\n * the release dates are taken from curl.git (at\n@@ -28,6 +25,14 @@\n * introduced, oldest first, in the official version of cURL library.\n */\n \n+/*\n+ * The oldest supported version of curl is documented in the \"INSTALL\"\n+ * document.\n+ */\n+#if LIBCURL_VERSION_NUM < 0x071304\n+#error \"libCURL older than 7.19.4 is not supported\"\n+#endif\n+\n /**\n * CURL_SOCKOPT_OK was added in 7.21.5, released in April 2011.\n */\n"},{"id":"458423","messageId":"xmqq7d4w7bcw.fsf@gitster.g","threadId":"58096","inReplyTo":"xmqqpmio7c3m.fsf@gitster.g","subject":"Re: [PATCH] http: support building on RHEL6","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-01T21:48:47Z","receivedAt":"2022-07-01T21:48:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> But I do not think the patch text, what the patch does, is that bad.\n> We advertise in INSTALL that you need 7.19.4 to build without NO_CURL;\n\n> IOW, you should be able to build Git with 7.21.3 or later.\n\nThat conclusion is nonsense. \"with a version before 7.21.3 as long\nas it is newer than 7.19.4\" is what I should have said.\n\n"},{"id":"458434","messageId":"220704.867d4tb8oo.gmgdl@evledraar.gmail.com","threadId":"58096","inReplyTo":"xmqq7d4w7bcw.fsf@gitster.g","subject":"Re: [PATCH] http: support building on RHEL6","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-07-04T07:38:06Z","receivedAt":"2022-07-04T08:09:56Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Jul 01 2022, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n>\n>> But I do not think the patch text, what the patch does, is that bad.\n>> We advertise in INSTALL that you need 7.19.4 to build without NO_CURL;\n>\n>> IOW, you should be able to build Git with 7.21.3 or later.\n>\n> That conclusion is nonsense. \"with a version before 7.21.3 as long\n> as it is newer than 7.19.4\" is what I should have said.\n\nI find this line of argument to be circular legalese without a\ndistinction.\n\nAs 644de29e220 (http: drop support for curl < 7.19.4, 2021-07-30) notes\n(which I submitted as part of the git-curl-compat.h series) the reason\nwe have 7.19.4 as a cut-off is entirely due to RHEL.\n\nSo, if you do agree with brian that supporting RHEL6 is a bad idea\nsupporting RHEL6 v.s. supporting libcurl 7.19.4 is a distinction without\na difference.\n\nThere's also a 7.19.3, and a 7.19.5, we didn't pick specifically 7.19.4\nby accident.\n\nYes you *could* run Linux-From-Scratch and just so happen to have that\nversion, but in reality practice almost everyone who cares about 7.19.4\ndoes so because the cut-off is synonymous with RHEL6 and its\nderivatives. The same goes for other \"magic versions\" shipped by later\nmajor OS versions from various vendors.\n\nBrian & I have disagreed on the larger point in the past, not to re-hash\nthe entire thing here (which can be found in some libcurl threads in\nparticular, and other \"older OS\" threads), but somewhat briefly:\n\n * I think we should be more aggressive in bumping required dependency\n versions, but not as a stick to force users on older systems to\n upgrade out of some enforcement of the Greater Good.\n\n But simply because we should weigh our time & effort in supporting\n and testing older versions, v.s. the relatively small effort for\n packager to build a newer git *and* its updated dependencies[1].\n\n * Having said that I entirely disagree with the premise that we should\n view the consumers of our software on free software platforms as\n helpless users who can't make an informed decision about whether they\n should run on older OS with newer software.\n\n Whether something is supported by upstream is only one factor in\n evaluating the security of a given installation, and whether security\n even really matters in that case (some older RHEL installs are\n firewalled off, or one some private network etc.).\n\n It's one thing to demand that we do their work for them (which per\n the above, I think it's fair to ask them to do more work). But\n arguing from the *principle* that we use non-support for older\n systems as a wedge quickly leads to justifying actively breaking\n older OS's, or not taking portability patches where the maintenance\n burden is trivial.\n\n * I really don't care that much about older libcurl in particular\n (using NO_CURL=Y or compiling it yourself is easy).\n\n But the reason some of us use or test on older OS's is not because we\n think exposing Solaris 10 (released in 2005, see [2]) or whatever to\n the wider internet would be a good idea, but because those older OS's\n tend to find edge cases is our portability assumptions, which\n sometimes even helps portability on newer or future OSs.\n\nThe reason I wrote the above now is because I'd really not like\ne.g. future C portability patches or whatever that are easy to carry but\nhappen to cater to some \"EOL\" OS to be rejected out of hand because\n\"there's no possible way that any Git developer can be expected to\nsupport [it]\", and to have this thread cited as justification without\nthere being a dissenting argument to be found.\n\nEven if I agreed with the goals I think the argument is still\nfundamentally flawed. Some vendors of older OS's don't publish the same\nsort of deprecation and support time tables that Red Hat does, even\nthough their older (and sometimes newer) OS's are probably more insecure\nin practice.\n\nTherefore if our criteria for shunning an OS is that its vendor deems it\ninsecure, we're not only using our clout to encourage them to upgrade,\nbut also encouraging the use of OS's whose vendors aren't themselves as\nstrict about encouraging users to upgrade.\n\n1. https://lore.kernel.org/git/CACBZZX78oKU5HuBEqb9qLy7--wcwhC_mW6x7Q+tB4suxohSCsQ@mail.gmail.com/\n2. https://cfarm.tetaneutral.net/machines/list/\n"},{"id":"458486","messageId":"xmqq8rp7laez.fsf@gitster.g","threadId":"58096","inReplyTo":"220704.867d4tb8oo.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH] http: support building on RHEL6","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-07-05T17:46:44Z","receivedAt":"2022-07-05T17:46:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n>>> But I do not think the patch text, what the patch does, is that bad.\n>>> We advertise in INSTALL that you need 7.19.4 to build without NO_CURL;\n>>\n>>> IOW, you should be able to build Git with 7.21.3 or later.\n>>\n>> That conclusion is nonsense. \"with a version before 7.21.3 as long\n>> as it is newer than 7.19.4\" is what I should have said.\n>\n> I find this line of argument to be circular legalese without a\n> distinction.\n>\n> As 644de29e220 (http: drop support for curl < 7.19.4, 2021-07-30) notes\n> (which I submitted as part of the git-curl-compat.h series) the reason\n> we have 7.19.4 as a cut-off is entirely due to RHEL.\n\nAh, I didn't dig deep enough.\n\nOn that backdrop, it becomes a reasonable alternative change to bump\nthe minimum required version to 7.21.3 with something like the \"I\nwonder if the attached patch is worth considering\" patch I sent in\nthe upthread, without adding the conditional based on\nGIT_CURL_HAVE_CURLOPT_RESOLVE cpp macro.\n\nWe could pick an even later cut-off point, but that requires a\nseparate discussion.\n\nThanks.\n"}]}