# minimum curl version effectively changed 4 messages from 2024-10-10 to 2024-10-10. Participants: Alejandro R. Sedeño, brian m. carlson. Thread: https://gitlist.dev/t/62305 ## Alejandro R. Sedeño, 2024-10-10 18:24 Subject: minimum curl version effectively changed Message-ID: URL: https://gitlist.dev/e/CAOO-Oz0NUA-YeyFT1MJ%3DXKyLWJvQoFH1b-F0EFOzvy8iWka3KA%40mail.gmail.com ``` As of ad9bb6dfe6e598d87ffe6e2285b4b86dac3bc726, http.c depends on symbols introduced curl 7.37.0, which is newer than the documented minimum version of 7.21.3 in INSTALL. ˋˋˋ In file included from /usr/include/curl/curl.h:2238:0, from git-curl-compat.h:3, from http.c:4: http.c: In function ‘set_proxyauth_name_password’: http.c:655:28: error: ‘CURLOPT_PROXYHEADER’ undeclared (first use in this function) curl_easy_setopt(result, CURLOPT_PROXYHEADER, ^ http.c:655:28: note: each undeclared identifier is reported only once for each function it appears in make: *** [http.o] Error 1 ˋˋˋ -Alejandro ``` ## brian m. carlson, 2024-10-10 21:23 Subject: Re: minimum curl version effectively changed Message-ID: URL: https://gitlist.dev/e/ZwhF0OZ2gpLWUfHD%40tapette.crustytoothpaste.net In-Reply-To: ``` On 2024-10-10 at 18:24:52, Alejandro R. Sedeño wrote: > As of ad9bb6dfe6e598d87ffe6e2285b4b86dac3bc726, http.c depends on > symbols introduced curl 7.37.0, which is newer than the documented > minimum version of 7.21.3 in INSTALL. > > ˋˋˋ > In file included from /usr/include/curl/curl.h:2238:0, > from git-curl-compat.h:3, > from http.c:4: > http.c: In function ‘set_proxyauth_name_password’: > http.c:655:28: error: ‘CURLOPT_PROXYHEADER’ undeclared (first use in > this function) > curl_easy_setopt(result, CURLOPT_PROXYHEADER, > ^ > http.c:655:28: note: each undeclared identifier is reported only once > for each function it appears in > make: *** [http.o] Error 1 > ˋˋˋ From the curl changelog, I do agree that that feature was added in 7.37.0. I think that's okay, since that was released in May 2014, over a decade ago, so we probably need to update INSTALL appropriately. I don't think any major Linux distros are still offering complementary security support for such an old version of libcurl, so I don't see us restoring support for older libcurl. It will probably also involve ripping out appropriate parts of `git-curl-compat.h` and the option flags. If nobody else gets to it over the next couple of days, I'll try to, but of course anyone is free to send in a patch. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA ``` ## Alejandro R. Sedeño, 2024-10-10 21:30 Subject: Re: minimum curl version effectively changed Message-ID: URL: https://gitlist.dev/e/CAOO-Oz1KhFcyErVx1Qb142PtPJS%3DUpgSD-FacckqNS4_okAtFQ%40mail.gmail.com In-Reply-To: ``` I have a patch I plan to send in tomorrow that will properly conditionalize using the symbol on versions of curl that have it, and emitting a warning otherwise. It will also follow up with some corrections to errors in git-curl-compat.h. I don't think a new feature should unilaterally change the minimum requirements of git without some announcement and forethought. -Alejandro On Thu, Oct 10, 2024 at 5:23 PM brian m. carlson wrote: > > On 2024-10-10 at 18:24:52, Alejandro R. Sedeño wrote: > > As of ad9bb6dfe6e598d87ffe6e2285b4b86dac3bc726, http.c depends on > > symbols introduced curl 7.37.0, which is newer than the documented > > minimum version of 7.21.3 in INSTALL. > > > > ˋˋˋ > > In file included from /usr/include/curl/curl.h:2238:0, > > from git-curl-compat.h:3, > > from http.c:4: > > http.c: In function ‘set_proxyauth_name_password’: > > http.c:655:28: error: ‘CURLOPT_PROXYHEADER’ undeclared (first use in > > this function) > > curl_easy_setopt(result, CURLOPT_PROXYHEADER, > > ^ > > http.c:655:28: note: each undeclared identifier is reported only once > > for each function it appears in > > make: *** [http.o] Error 1 > > ˋˋˋ > > From the curl changelog, I do agree that that feature was added in > 7.37.0. I think that's okay, since that was released in May 2014, over > a decade ago, so we probably need to update INSTALL appropriately. I > don't think any major Linux distros are still offering complementary > security support for such an old version of libcurl, so I don't see us > restoring support for older libcurl. > > It will probably also involve ripping out appropriate parts of > `git-curl-compat.h` and the option flags. If nobody else gets to it over > the next couple of days, I'll try to, but of course anyone is free to > send in a patch. > -- > brian m. carlson (they/them or he/him) > Toronto, Ontario, CA ``` ## brian m. carlson, 2024-10-10 21:52 Subject: Re: minimum curl version effectively changed Message-ID: URL: https://gitlist.dev/e/ZwhMmGt0kZvaSzSL%40tapette.crustytoothpaste.net In-Reply-To: ``` On 2024-10-10 at 21:30:04, Alejandro R. Sedeño wrote: > I have a patch I plan to send in tomorrow that will properly > conditionalize using the symbol on versions of curl that have it, and > emitting a warning otherwise. It will also follow up with some > corrections to errors in git-curl-compat.h. > > I don't think a new feature should unilaterally change the minimum > requirements of git without some announcement and forethought. We already have a platform support policy, which guides our behaviour here, and it was discussed very recently. It says this: Uses versions of dependencies which are generally accepted as stable and supportable, e.g., in line with the version used by other long-term-support distributions No major Linux distributions are still using such an old version of libcurl. CentOS 7 is dead, and we don't typically support extended long-term support because it comes at a cost, and it's not fair to Git developers to require them to pay for a secure system to test against. I don't know of any other major OS which is providing support for such an old version of curl either. Usually the BSDs have a much shorter life span for versions, for example. So I think the oldest supported version we're going to be willing to accept is in a clone of RHEL 8, which would be curl 7.61. It's certainly a mistake on our part that we neglected to update INSTALL accordingly, but it's not a mistake that we unconditionally added support for a feature from over a decade ago. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA ```