[PATCH 0/2] Restore support for older libcurl and fix some typos

[PATCH 0/2] Restore support for older libcurl and fix some typos

[Alejandro R. Sedeño]

Hi,

This is the small patchset I've mentioned on a couple of threads
in the past few days [1, 2].

The first patch adds a version check for CURLOPT_PROXYHEADER in
git-curl-compat.h and uses it to wrap the one use of
CURLOPT_PROXYHEADER, replacing it with a translatable warning if it's
used on an older version of libcurl.

The second patch adjusts some typos I noticed in
git-curl-compat.h. These should be easily verifiable against curl's
docs/libcurl/symbols-in-version, which is the source of truth for
git-curl-compat.h.

This is presented as an alternative to the patch series from
brian m. carlson that bumps the minimum version of libcurl
to 7.61.0 [3].

-Alejandro

[1] https://lore.kernel.org/git/CAOO-Oz1KhFcyErVx1Qb142PtPJS=UpgSD-FacckqNS4_okAtFQ@mail.gmail.com/
[2] https://lore.kernel.org/git/20241011190812.2654837-1-asedeno@mit.edu/
[3] https://lore.kernel.org/git/20241010235621.738239-1-sandals@crustytoothpaste.net/


Alejandro R. Sedeño (2):
  Conditional use of CURLOPT_PROXYHEADER based on libcurl version
  Fix inconsistencies in git-curl-compat.h

 git-curl-compat.h | 11 +++++++++--
 http.c            |  4 ++++
 2 files changed, 13 insertions(+), 2 deletions(-)

-- 
2.39.5

[PATCH 1/2] Conditional use of CURLOPT_PROXYHEADER based on libcurl version

[Alejandro R. Sedeño]

Signed-off-by: Alejandro R. Sedeño <asedeno@mit.edu>
Signed-off-by: Alejandro R. Sedeño <asedeno@google.com>
---
 git-curl-compat.h | 7 +++++++
 http.c            | 4 ++++
 2 files changed, 11 insertions(+)

diff --git a/git-curl-compat.h b/git-curl-compat.h
index e1d0bdd273..08ae73e0f1 100644
--- a/git-curl-compat.h
+++ b/git-curl-compat.h
@@ -65,6 +65,13 @@
 #define GIT_CURL_HAVE_CURL_SSLVERSION_TLSv1_0
 #endif
 
+/**
+ * CURLOPT_PROXYHEADER was added in 7.37.0, released in May 2014.
+ */
+#if LIBCURL_VERSION_NUM >= 0x072500
+#define GIT_CURL_HAVE_CURLOPT_PROXYHEADER
+#endif
+
 /**
  * CURLOPT_PINNEDPUBLICKEY was added in 7.39.0, released in November
  * 2014. CURLE_SSL_PINNEDPUBKEYNOTMATCH was added in that same version.
diff --git a/http.c b/http.c
index d59e59f66b..30d5e4c67b 100644
--- a/http.c
+++ b/http.c
@@ -652,8 +652,12 @@ static void set_proxyauth_name_password(CURL *result)
 		curl_easy_setopt(result, CURLOPT_PROXYPASSWORD,
 			proxy_auth.password);
 	} else if (proxy_auth.authtype && proxy_auth.credential) {
+#ifdef GIT_CURL_HAVE_CURLOPT_PROXYHEADER
 		curl_easy_setopt(result, CURLOPT_PROXYHEADER,
 				 http_append_auth_header(&proxy_auth, NULL));
+#else
+		warning(_("CURLOPT_PROXYHEADER not supported with cURL < 7.37.0"));
+#endif
 	}
 }
 
-- 
2.39.5

[PATCH 2/2] Fix inconsistencies in git-curl-compat.h

[Alejandro R. Sedeño]

Signed-off-by: Alejandro R. Sedeño <asedeno@mit.edu>
Signed-off-by: Alejandro R. Sedeño <asedeno@google.com>
---
 git-curl-compat.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/git-curl-compat.h b/git-curl-compat.h
index 08ae73e0f1..f9aebf93ae 100644
--- a/git-curl-compat.h
+++ b/git-curl-compat.h
@@ -76,7 +76,7 @@
  * CURLOPT_PINNEDPUBLICKEY was added in 7.39.0, released in November
  * 2014. CURLE_SSL_PINNEDPUBKEYNOTMATCH was added in that same version.
  */
-#if LIBCURL_VERSION_NUM >= 0x072c00
+#if LIBCURL_VERSION_NUM >= 0x072700
 #define GIT_CURL_HAVE_CURLOPT_PINNEDPUBLICKEY 1
 #define GIT_CURL_HAVE_CURLE_SSL_PINNEDPUBKEYNOTMATCH 1
 #endif
@@ -118,7 +118,7 @@
 #endif
 
 /**
- * CURL_SSLVERSION_TLSv1_3 was added in 7.53.0, released in February
+ * CURL_SSLVERSION_TLSv1_3 was added in 7.52.0, released in August
  * 2017.
  */
 #if LIBCURL_VERSION_NUM >= 0x073400
-- 
2.39.5

Re: [PATCH 0/2] Restore support for older libcurl and fix some typos

[Taylor Blau]

On Mon, Oct 14, 2024 at 09:13:44AM -0400, Alejandro R. Sedeño wrote:
> This is presented as an alternative to the patch series from
> brian m. carlson that bumps the minimum version of libcurl
> to 7.61.0 [3].

This conflicts with brian's series as you mention, so I haven't picked
this one up in 'seen' yet.

Could you summarize why you think this series is a better approach than
what brian has posted? On its own, I do not understand the motivation.

Thanks,
Taylor

Re: [PATCH 0/2] Restore support for older libcurl and fix some typos

[Alejandro R. Sedeño]

On Mon, Oct 14, 2024 at 8:28 PM Taylor Blau <me@ttaylorr.com> wrote:
> On Mon, Oct 14, 2024 at 09:13:44AM -0400, Alejandro R. Sedeño wrote:
> > This is presented as an alternative to the patch series from
> > brian m. carlson that bumps the minimum version of libcurl
> > to 7.61.0 [3].
>
> This conflicts with brian's series as you mention, so I haven't picked
> this one up in 'seen' yet.
>
> Could you summarize why you think this series is a better approach than
> what brian has posted? On its own, I do not understand the motivation.

It's a question of preserving compatibility vs ratcheting up minimum
requirements. Both have their merits. I sent in this patch set after
seeing some mild pushback to brian's series, just to present an
alternative. Maintaining compatibility with older versions can be a
burden to the project, though I think given this patch series, it's
not a very big one. Ratcheting up the minimum requirements can be a
burden to users stuck on (or choosing to try and support) older
platforms. At some point the burden on the project outweighs the
desire to support those older platforms. Where that tipping point is
is for the community to decide.

For my own personal purposes, I've worked around the issue by building
a newer libcurl to link git against, though brian's updates to the
perl minimum requirements will pose a more substantial problem for me
in the future.

-Alejandro

Re: [PATCH 0/2] Restore support for older libcurl and fix some typos

[Eric Sunshine]

On Mon, Oct 14, 2024 at 8:51 PM Alejandro R. Sedeño <asedeno@mit.edu> wrote:
> On Mon, Oct 14, 2024 at 8:28 PM Taylor Blau <me@ttaylorr.com> wrote:
> > On Mon, Oct 14, 2024 at 09:13:44AM -0400, Alejandro R. Sedeño wrote:
> > > This is presented as an alternative to the patch series from
> > > brian m. carlson that bumps the minimum version of libcurl
> > > to 7.61.0 [3].
> >
> > This conflicts with brian's series as you mention, so I haven't picked
> > this one up in 'seen' yet.
> >
> > Could you summarize why you think this series is a better approach than
> > what brian has posted? On its own, I do not understand the motivation.
>
> It's a question of preserving compatibility vs ratcheting up minimum
> requirements. Both have their merits. I sent in this patch set after
> seeing some mild pushback to brian's series, just to present an
> alternative. Maintaining compatibility with older versions can be a
> burden to the project, though I think given this patch series, it's
> not a very big one. Ratcheting up the minimum requirements can be a
> burden to users stuck on (or choosing to try and support) older
> platforms. At some point the burden on the project outweighs the
> desire to support those older platforms. Where that tipping point is
> is for the community to decide.

For reference, I'm the one who pushed back on brian's series. The
"push-back" subthread starts at [1].

[1]: https://lore.kernel.org/git/20241014132856.3558224-1-asedeno@mit.edu/T/#mc1180f00cf52de4e9bae334c2cd5abd9a160dbbe

Re: [PATCH 0/2] Restore support for older libcurl and fix some typos

[Taylor Blau]

On Tue, Oct 15, 2024 at 02:29:33AM -0400, Eric Sunshine wrote:
> On Mon, Oct 14, 2024 at 8:51 PM Alejandro R. Sedeño <asedeno@mit.edu> wrote:
> > On Mon, Oct 14, 2024 at 8:28 PM Taylor Blau <me@ttaylorr.com> wrote:
> > > On Mon, Oct 14, 2024 at 09:13:44AM -0400, Alejandro R. Sedeño wrote:
> > > > This is presented as an alternative to the patch series from
> > > > brian m. carlson that bumps the minimum version of libcurl
> > > > to 7.61.0 [3].
> > >
> > > This conflicts with brian's series as you mention, so I haven't picked
> > > this one up in 'seen' yet.
> > >
> > > Could you summarize why you think this series is a better approach than
> > > what brian has posted? On its own, I do not understand the motivation.
> >
> > It's a question of preserving compatibility vs ratcheting up minimum
> > requirements. Both have their merits. I sent in this patch set after
> > seeing some mild pushback to brian's series, just to present an
> > alternative. Maintaining compatibility with older versions can be a
> > burden to the project, though I think given this patch series, it's
> > not a very big one. Ratcheting up the minimum requirements can be a
> > burden to users stuck on (or choosing to try and support) older
> > platforms. At some point the burden on the project outweighs the
> > desire to support those older platforms. Where that tipping point is
> > is for the community to decide.
>
> For reference, I'm the one who pushed back on brian's series. The
> "push-back" subthread starts at [1].
>
> [1]: https://lore.kernel.org/git/20241014132856.3558224-1-asedeno@mit.edu/T/#mc1180f00cf52de4e9bae334c2cd5abd9a160dbbe

OK. Junio had brian's series in 'seen' when I picked up the integration
branches on Friday evening. Let's keep it that way for now while we wait
to see what approach between the two is preferred.

Thanks,
Taylor

Re: [PATCH 0/2] Restore support for older libcurl and fix some typos

[Torsten Bögershausen]

On Tue, Oct 15, 2024 at 02:29:33AM -0400, Eric Sunshine wrote:
> On Mon, Oct 14, 2024 at 8:51 PM Alejandro R. Sedeño <asedeno@mit.edu> wrote:
> > On Mon, Oct 14, 2024 at 8:28 PM Taylor Blau <me@ttaylorr.com> wrote:
> > > On Mon, Oct 14, 2024 at 09:13:44AM -0400, Alejandro R. Sedeño wrote:
> > > > This is presented as an alternative to the patch series from
> > > > brian m. carlson that bumps the minimum version of libcurl
> > > > to 7.61.0 [3].
> > >
> > > This conflicts with brian's series as you mention, so I haven't picked
> > > this one up in 'seen' yet.
> > >
> > > Could you summarize why you think this series is a better approach than
> > > what brian has posted? On its own, I do not understand the motivation.
> >
> > It's a question of preserving compatibility vs ratcheting up minimum
> > requirements. Both have their merits. I sent in this patch set after
> > seeing some mild pushback to brian's series, just to present an
> > alternative. Maintaining compatibility with older versions can be a
> > burden to the project, though I think given this patch series, it's
> > not a very big one. Ratcheting up the minimum requirements can be a
> > burden to users stuck on (or choosing to try and support) older
> > platforms. At some point the burden on the project outweighs the
> > desire to support those older platforms. Where that tipping point is
> > is for the community to decide.
>
> For reference, I'm the one who pushed back on brian's series. The
> "push-back" subthread starts at [1].
>
> [1]: https://lore.kernel.org/git/20241014132856.3558224-1-asedeno@mit.edu/T/#mc1180f00cf52de4e9bae334c2cd5abd9a160dbbe
>


Being one of the people who has to work with older distributions,
I think that I would support the pushback.

There are many machines out there,
which are still running in production with old installations.
In my case it is a Centos 7 machine, coming with Git 1.8.3.1

Out of my head, git submodules didn't work (as good as today),
and even things like git -P didn't exist then.

I may be worth to mention that this machines are protected by double
or triple firewalls, routing tables, and whatever is needed to protect
them.
Maintaining production software and hardware, systems using specialized hardware
with Linux drivers dependend on the Linux kernel is daily work.

And here tools like Git are needed (and appreciated).

My view is that the new developments can focus on the "latest" distributions,
and if some comes along and has a patch that make Git
compile and work under an older system, and that patch does not break
newer systems, it would be a good thing to accept.

The seen branch from October 11 does not compile (any more) under Centos 7.
One problem is the curl stuff.
And then some warning, missing a prototype for lstat() in  clar.c/fs_copy().
And warnings about missing braces around initializers, nothing
to worry about.

Lets try a summarize:
I can volunteer to compile Git from seen on this Centos box,
lets say once a week, and report breakages.

Other toughts ?

Re: [PATCH 0/2] Restore support for older libcurl and fix some typos

[Oswald Buddenhagen]

On Thu, Oct 17, 2024 at 08:59:37AM +0200, Torsten Bögershausen wrote:
>Maintaining production software and hardware, systems using specialized
>hardware with Linux drivers dependend on the Linux kernel is daily
>work.
>
yes.

>And here tools like Git are needed (and appreciated).
>
but why?
why do you need bleeding edge git on these special-purpose systems from
the stone age? wouldn't any sane developer (cross-)build on a modern
system (which usually has about an order of magnitude more computing
power, aside from the newer tools) and then deploy and extract only
what's needed via some mostly automated process? it would only matter if
git was part of the production software (what for?), but then we're back
to square one.

Re: [PATCH 0/2] Restore support for older libcurl and fix some typos

[Torsten Bögershausen]

Just a short update:
This make git compile (again) on the mentioned centos system.