{"thread":{"id":"62331","subject":"[PATCH 0/2] Restore support for older libcurl and fix some typos","startedAt":"2024-10-14T13:14:08Z","lastAt":"2024-10-17T09:30:49Z","messageCount":10,"participants":["Alejandro R. Sedeño","Taylor Blau","Eric Sunshine","Torsten Bögershausen","Oswald Buddenhagen"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"505014","messageId":"20241014131346.3556163-1-asedeno@mit.edu","threadId":"62331","inReplyTo":null,"subject":"[PATCH 0/2] Restore support for older libcurl and fix some typos","fromName":"Alejandro R. Sedeño","fromEmail":"asedeno@mit.edu","sentAt":"2024-10-14T13:13:44Z","receivedAt":"2024-10-14T13:14:08Z","isPatch":true,"sender":{"key":"asedeno@mit.edu","avatar":"https://avatars.githubusercontent.com/u/28302?v=4"},"body":"Hi,\n\nThis is the small patchset I've mentioned on a couple of threads\nin the past few days [1, 2].\n\nThe first patch adds a version check for CURLOPT_PROXYHEADER in\ngit-curl-compat.h and uses it to wrap the one use of\nCURLOPT_PROXYHEADER, replacing it with a translatable warning if it's\nused on an older version of libcurl.\n\nThe second patch adjusts some typos I noticed in\ngit-curl-compat.h. These should be easily verifiable against curl's\ndocs/libcurl/symbols-in-version, which is the source of truth for\ngit-curl-compat.h.\n\nThis is presented as an alternative to the patch series from\nbrian m. carlson that bumps the minimum version of libcurl\nto 7.61.0 [3].\n\n-Alejandro\n\n[1] https://lore.kernel.org/git/CAOO-Oz1KhFcyErVx1Qb142PtPJS=UpgSD-FacckqNS4_okAtFQ@mail.gmail.com/\n[2] https://lore.kernel.org/git/20241011190812.2654837-1-asedeno@mit.edu/\n[3] https://lore.kernel.org/git/20241010235621.738239-1-sandals@crustytoothpaste.net/\n\n\nAlejandro R. Sedeño (2):\n Conditional use of CURLOPT_PROXYHEADER based on libcurl version\n Fix inconsistencies in git-curl-compat.h\n\n git-curl-compat.h | 11 +++++++++--\n http.c | 4 ++++\n 2 files changed, 13 insertions(+), 2 deletions(-)\n\n-- \n2.39.5\n\n"},{"id":"505015","messageId":"20241014131346.3556163-2-asedeno@mit.edu","threadId":"62331","inReplyTo":"20241014131346.3556163-1-asedeno@mit.edu","subject":"[PATCH 1/2] Conditional use of CURLOPT_PROXYHEADER based on libcurl version","fromName":"Alejandro R. Sedeño","fromEmail":"asedeno@mit.edu","sentAt":"2024-10-14T13:13:45Z","receivedAt":"2024-10-14T13:14:09Z","isPatch":true,"sender":{"key":"asedeno@mit.edu","avatar":"https://avatars.githubusercontent.com/u/28302?v=4"},"body":"Signed-off-by: Alejandro R. Sedeño \nSigned-off-by: Alejandro R. Sedeño \n---\n git-curl-compat.h | 7 +++++++\n http.c | 4 ++++\n 2 files changed, 11 insertions(+)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex e1d0bdd273..08ae73e0f1 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -65,6 +65,13 @@\n #define GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_0\n #endif\n \n+/**\n+ * CURLOPT_PROXYHEADER was added in 7.37.0, released in May 2014.\n+ */\n+#if LIBCURL_VERSION_NUM >= 0x072500\n+#define GIT_CURL_HAVE_CURLOPT_PROXYHEADER\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 d59e59f66b..30d5e4c67b 100644\n--- a/http.c\n+++ b/http.c\n@@ -652,8 +652,12 @@ static void set_proxyauth_name_password(CURL *result)\n \t\tcurl_easy_setopt(result, CURLOPT_PROXYPASSWORD,\n \t\t\tproxy_auth.password);\n \t} else if (proxy_auth.authtype && proxy_auth.credential) {\n+#ifdef GIT_CURL_HAVE_CURLOPT_PROXYHEADER\n \t\tcurl_easy_setopt(result, CURLOPT_PROXYHEADER,\n \t\t\t\t http_append_auth_header(&proxy_auth, NULL));\n+#else\n+\t\twarning(_(\"CURLOPT_PROXYHEADER not supported with cURL < 7.37.0\"));\n+#endif\n \t}\n }\n \n-- \n2.39.5\n\n"},{"id":"505016","messageId":"20241014131346.3556163-3-asedeno@mit.edu","threadId":"62331","inReplyTo":"20241014131346.3556163-1-asedeno@mit.edu","subject":"[PATCH 2/2] Fix inconsistencies in git-curl-compat.h","fromName":"Alejandro R. Sedeño","fromEmail":"asedeno@mit.edu","sentAt":"2024-10-14T13:13:46Z","receivedAt":"2024-10-14T13:14:10Z","isPatch":true,"sender":{"key":"asedeno@mit.edu","avatar":"https://avatars.githubusercontent.com/u/28302?v=4"},"body":"Signed-off-by: Alejandro R. Sedeño \nSigned-off-by: Alejandro R. Sedeño \n---\n git-curl-compat.h | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-curl-compat.h b/git-curl-compat.h\nindex 08ae73e0f1..f9aebf93ae 100644\n--- a/git-curl-compat.h\n+++ b/git-curl-compat.h\n@@ -76,7 +76,7 @@\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+#if LIBCURL_VERSION_NUM >= 0x072700\n #define GIT_CURL_HAVE_CURLOPT_PINNEDPUBLICKEY 1\n #define GIT_CURL_HAVE_CURLE_SSL_PINNEDPUBKEYNOTMATCH 1\n #endif\n@@ -118,7 +118,7 @@\n #endif\n \n /**\n- * CURL_SSLVERSION_TLSv1_3 was added in 7.53.0, released in February\n+ * CURL_SSLVERSION_TLSv1_3 was added in 7.52.0, released in August\n * 2017.\n */\n #if LIBCURL_VERSION_NUM >= 0x073400\n-- \n2.39.5\n\n"},{"id":"505100","messageId":"Zw23K4zPN9e+JyNA@nand.local","threadId":"62331","inReplyTo":"20241014131346.3556163-1-asedeno@mit.edu","subject":"Re: [PATCH 0/2] Restore support for older libcurl and fix some typos","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-10-15T00:28:27Z","receivedAt":"2024-10-15T00:28:30Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Mon, Oct 14, 2024 at 09:13:44AM -0400, Alejandro R. Sedeño wrote:\n> This is presented as an alternative to the patch series from\n> brian m. carlson that bumps the minimum version of libcurl\n> to 7.61.0 [3].\n\nThis conflicts with brian's series as you mention, so I haven't picked\nthis one up in 'seen' yet.\n\nCould you summarize why you think this series is a better approach than\nwhat brian has posted? On its own, I do not understand the motivation.\n\nThanks,\nTaylor\n"},{"id":"505108","messageId":"CAOO-Oz3eQ+fpWU3qLHtF5oCxj2ieoc6P4R+iKJTG3DoWrb6W3g@mail.gmail.com","threadId":"62331","inReplyTo":"Zw23K4zPN9e+JyNA@nand.local","subject":"Re: [PATCH 0/2] Restore support for older libcurl and fix some typos","fromName":"Alejandro R. Sedeño","fromEmail":"asedeno@mit.edu","sentAt":"2024-10-15T00:51:19Z","receivedAt":"2024-10-15T00:51:36Z","isPatch":true,"sender":{"key":"asedeno@mit.edu","avatar":"https://avatars.githubusercontent.com/u/28302?v=4"},"body":"On Mon, Oct 14, 2024 at 8:28 PM Taylor Blau wrote:\n> On Mon, Oct 14, 2024 at 09:13:44AM -0400, Alejandro R. Sedeño wrote:\n> > This is presented as an alternative to the patch series from\n> > brian m. carlson that bumps the minimum version of libcurl\n> > to 7.61.0 [3].\n>\n> This conflicts with brian's series as you mention, so I haven't picked\n> this one up in 'seen' yet.\n>\n> Could you summarize why you think this series is a better approach than\n> what brian has posted? On its own, I do not understand the motivation.\n\nIt's a question of preserving compatibility vs ratcheting up minimum\nrequirements. Both have their merits. I sent in this patch set after\nseeing some mild pushback to brian's series, just to present an\nalternative. Maintaining compatibility with older versions can be a\nburden to the project, though I think given this patch series, it's\nnot a very big one. Ratcheting up the minimum requirements can be a\nburden to users stuck on (or choosing to try and support) older\nplatforms. At some point the burden on the project outweighs the\ndesire to support those older platforms. Where that tipping point is\nis for the community to decide.\n\nFor my own personal purposes, I've worked around the issue by building\na newer libcurl to link git against, though brian's updates to the\nperl minimum requirements will pose a more substantial problem for me\nin the future.\n\n-Alejandro\n"},{"id":"505119","messageId":"CAPig+cRENnd9cV5yFfVVwbuux84k10_vcht-TTtKGJmRNYEttA@mail.gmail.com","threadId":"62331","inReplyTo":"CAOO-Oz3eQ+fpWU3qLHtF5oCxj2ieoc6P4R+iKJTG3DoWrb6W3g@mail.gmail.com","subject":"Re: [PATCH 0/2] Restore support for older libcurl and fix some typos","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-10-15T06:29:33Z","receivedAt":"2024-10-15T06:29:44Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Oct 14, 2024 at 8:51 PM Alejandro R. Sedeño wrote:\n> On Mon, Oct 14, 2024 at 8:28 PM Taylor Blau wrote:\n> > On Mon, Oct 14, 2024 at 09:13:44AM -0400, Alejandro R. Sedeño wrote:\n> > > This is presented as an alternative to the patch series from\n> > > brian m. carlson that bumps the minimum version of libcurl\n> > > to 7.61.0 [3].\n> >\n> > This conflicts with brian's series as you mention, so I haven't picked\n> > this one up in 'seen' yet.\n> >\n> > Could you summarize why you think this series is a better approach than\n> > what brian has posted? On its own, I do not understand the motivation.\n>\n> It's a question of preserving compatibility vs ratcheting up minimum\n> requirements. Both have their merits. I sent in this patch set after\n> seeing some mild pushback to brian's series, just to present an\n> alternative. Maintaining compatibility with older versions can be a\n> burden to the project, though I think given this patch series, it's\n> not a very big one. Ratcheting up the minimum requirements can be a\n> burden to users stuck on (or choosing to try and support) older\n> platforms. At some point the burden on the project outweighs the\n> desire to support those older platforms. Where that tipping point is\n> is for the community to decide.\n\nFor reference, I'm the one who pushed back on brian's series. The\n\"push-back\" subthread starts at [1].\n\n[1]: https://lore.kernel.org/git/20241014132856.3558224-1-asedeno@mit.edu/T/#mc1180f00cf52de4e9bae334c2cd5abd9a160dbbe\n"},{"id":"505198","messageId":"Zw7A/UASAFNsfmPF@nand.local","threadId":"62331","inReplyTo":"CAPig+cRENnd9cV5yFfVVwbuux84k10_vcht-TTtKGJmRNYEttA@mail.gmail.com","subject":"Re: [PATCH 0/2] Restore support for older libcurl and fix some typos","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-10-15T19:22:37Z","receivedAt":"2024-10-15T19:22:40Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Oct 15, 2024 at 02:29:33AM -0400, Eric Sunshine wrote:\n> On Mon, Oct 14, 2024 at 8:51 PM Alejandro R. Sedeño wrote:\n> > On Mon, Oct 14, 2024 at 8:28 PM Taylor Blau wrote:\n> > > On Mon, Oct 14, 2024 at 09:13:44AM -0400, Alejandro R. Sedeño wrote:\n> > > > This is presented as an alternative to the patch series from\n> > > > brian m. carlson that bumps the minimum version of libcurl\n> > > > to 7.61.0 [3].\n> > >\n> > > This conflicts with brian's series as you mention, so I haven't picked\n> > > this one up in 'seen' yet.\n> > >\n> > > Could you summarize why you think this series is a better approach than\n> > > what brian has posted? On its own, I do not understand the motivation.\n> >\n> > It's a question of preserving compatibility vs ratcheting up minimum\n> > requirements. Both have their merits. I sent in this patch set after\n> > seeing some mild pushback to brian's series, just to present an\n> > alternative. Maintaining compatibility with older versions can be a\n> > burden to the project, though I think given this patch series, it's\n> > not a very big one. Ratcheting up the minimum requirements can be a\n> > burden to users stuck on (or choosing to try and support) older\n> > platforms. At some point the burden on the project outweighs the\n> > desire to support those older platforms. Where that tipping point is\n> > is for the community to decide.\n>\n> For reference, I'm the one who pushed back on brian's series. The\n> \"push-back\" subthread starts at [1].\n>\n> [1]: https://lore.kernel.org/git/20241014132856.3558224-1-asedeno@mit.edu/T/#mc1180f00cf52de4e9bae334c2cd5abd9a160dbbe\n\nOK. Junio had brian's series in 'seen' when I picked up the integration\nbranches on Friday evening. Let's keep it that way for now while we wait\nto see what approach between the two is preferred.\n\nThanks,\nTaylor\n"},{"id":"505345","messageId":"20241017065936.GA16141@tb-raspi4","threadId":"62331","inReplyTo":"CAPig+cRENnd9cV5yFfVVwbuux84k10_vcht-TTtKGJmRNYEttA@mail.gmail.com","subject":"Re: [PATCH 0/2] Restore support for older libcurl and fix some typos","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2024-10-17T06:59:37Z","receivedAt":"2024-10-17T06:59:54Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Tue, Oct 15, 2024 at 02:29:33AM -0400, Eric Sunshine wrote:\n> On Mon, Oct 14, 2024 at 8:51 PM Alejandro R. Sedeño wrote:\n> > On Mon, Oct 14, 2024 at 8:28 PM Taylor Blau wrote:\n> > > On Mon, Oct 14, 2024 at 09:13:44AM -0400, Alejandro R. Sedeño wrote:\n> > > > This is presented as an alternative to the patch series from\n> > > > brian m. carlson that bumps the minimum version of libcurl\n> > > > to 7.61.0 [3].\n> > >\n> > > This conflicts with brian's series as you mention, so I haven't picked\n> > > this one up in 'seen' yet.\n> > >\n> > > Could you summarize why you think this series is a better approach than\n> > > what brian has posted? On its own, I do not understand the motivation.\n> >\n> > It's a question of preserving compatibility vs ratcheting up minimum\n> > requirements. Both have their merits. I sent in this patch set after\n> > seeing some mild pushback to brian's series, just to present an\n> > alternative. Maintaining compatibility with older versions can be a\n> > burden to the project, though I think given this patch series, it's\n> > not a very big one. Ratcheting up the minimum requirements can be a\n> > burden to users stuck on (or choosing to try and support) older\n> > platforms. At some point the burden on the project outweighs the\n> > desire to support those older platforms. Where that tipping point is\n> > is for the community to decide.\n>\n> For reference, I'm the one who pushed back on brian's series. The\n> \"push-back\" subthread starts at [1].\n>\n> [1]: https://lore.kernel.org/git/20241014132856.3558224-1-asedeno@mit.edu/T/#mc1180f00cf52de4e9bae334c2cd5abd9a160dbbe\n>\n\n\nBeing one of the people who has to work with older distributions,\nI think that I would support the pushback.\n\nThere are many machines out there,\nwhich are still running in production with old installations.\nIn my case it is a Centos 7 machine, coming with Git 1.8.3.1\n\nOut of my head, git submodules didn't work (as good as today),\nand even things like git -P didn't exist then.\n\nI may be worth to mention that this machines are protected by double\nor triple firewalls, routing tables, and whatever is needed to protect\nthem.\nMaintaining production software and hardware, systems using specialized hardware\nwith Linux drivers dependend on the Linux kernel is daily work.\n\nAnd here tools like Git are needed (and appreciated).\n\nMy view is that the new developments can focus on the \"latest\" distributions,\nand if some comes along and has a patch that make Git\ncompile and work under an older system, and that patch does not break\nnewer systems, it would be a good thing to accept.\n\nThe seen branch from October 11 does not compile (any more) under Centos 7.\nOne problem is the curl stuff.\nAnd then some warning, missing a prototype for lstat() in clar.c/fs_copy().\nAnd warnings about missing braces around initializers, nothing\nto worry about.\n\nLets try a summarize:\nI can volunteer to compile Git from seen on this Centos box,\nlets say once a week, and report breakages.\n\nOther toughts ?\n"},{"id":"505350","messageId":"ZxDVnGigNP4UUG3a@ugly","threadId":"62331","inReplyTo":"20241017065936.GA16141@tb-raspi4","subject":"Re: [PATCH 0/2] Restore support for older libcurl and fix some typos","fromName":"Oswald Buddenhagen","fromEmail":"oswald.buddenhagen@gmx.de","sentAt":"2024-10-17T09:15:08Z","receivedAt":"2024-10-17T09:15:38Z","isPatch":true,"sender":{"key":"oswald.buddenhagen@gmx.de","avatar":"https://avatars.githubusercontent.com/u/812380?v=4"},"body":"On Thu, Oct 17, 2024 at 08:59:37AM +0200, Torsten Bögershausen wrote:\n>Maintaining production software and hardware, systems using specialized\n>hardware with Linux drivers dependend on the Linux kernel is daily\n>work.\n>\nyes.\n\n>And here tools like Git are needed (and appreciated).\n>\nbut why?\nwhy do you need bleeding edge git on these special-purpose systems from\nthe stone age? wouldn't any sane developer (cross-)build on a modern\nsystem (which usually has about an order of magnitude more computing\npower, aside from the newer tools) and then deploy and extract only\nwhat's needed via some mostly automated process? it would only matter if\ngit was part of the production software (what for?), but then we're back\nto square one.\n\n"},{"id":"505352","messageId":"20241017093027.GA19306@tb-raspi4","threadId":"62331","inReplyTo":"20241017065936.GA16141@tb-raspi4","subject":"Re: [PATCH 0/2] Restore support for older libcurl and fix some typos","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2024-10-17T09:30:27Z","receivedAt":"2024-10-17T09:30:49Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"\nJust a short update:\nThis make git compile (again) on the mentioned centos system.\n\n"}]}