libcurl: bump libcurl to c-ares/1.28.1

[hoyhoy]

Specify library name and version: libcurl/*

Bump to c-ares/1.28.1.

---

• [X] I've read the contributing guidelines.
• [X] I've used a recent Conan client version close to the currently deployed.
• [X] I've tried at least one configuration locally with the conan-center hook activated.

[github-actions[bot]]

:robot: Beep Boop! This pull request is making changes to 'recipes/libcurl//'.

:wave: @Hopobcn you might be interested. :wink:

[ghost]

I detected other pull requests that are modifying libcurl/all recipe:

• #23376
• #21746
• #21558

This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there.

[conan-center-bot]

:vertical_traffic_light: Thank for your Bump dependencies PR. The build service will be triggered soon by a Conan team member.

[conan-center-bot]

:vertical_traffic_light: Thank for your Bump dependencies PR. The build service will be triggered soon by a Conan team member.

[conan-center-bot]

:vertical_traffic_light: Thank for your Bump dependencies PR. The build service will be triggered soon by a Conan team member.

[jcar87]

Hi @hoyhoy, thanks for your contribution. - Please note that we no longer consider or prioritize PRs to bump versions of dependencies unless a reason is provided in the PR description. Reasons could be (list not exhaustive)

• to solve a version conflict - in which clase, please provide a conanfile that results in a version conflict (or a link to a CI run where this is happening) - this helps us see if there are other places where this needs to be solved, and the team will prioritize this.
• because the old version is impacted by a CVE, and the new one isn't
• because the new version has features (or something new) that is useful, in which case please specify exactly what

We may hold a version bump if the only reason is "because it's the latest" version - in which case we will prioritise not having conflicts (and security!), rather than "everything on the latest".

[hoyhoy]

@jcar87 so no ongoing bugfixes? What if you don't build with the new dependencies, and something breaks and then you have a CVE, but then you haven't updated for six months because there wasn't a CVE? Now you have to spend time refactoring your code to be compatible with the dependency instead of merging the fix...

We already had to fork conan-center locally because PRs we submitted take up to four months to get merged here. We're trying to avoid having literally every recipe forked.

* CMake: don't overwrite global required libraries/definitions/includes which could cause build errors for projects chain * building c-ares. [Issue #729](https://github.com/c-ares/c-ares/issues/729)
* On some platforms, netinet6/in6.h is not included by netinet/in.h and needs to be included separately. [PR #728](https://github.com/c-ares/c-ares/pull/728)
* Fix a potential memory leak in ares_init(). [Issue #724](https://github.com/c-ares/c-ares/issues/724)
* Some platforms don't have the isascii() function. Implement as a macro. [PR #721](https://github.com/c-ares/c-ares/pull/721)
* CMake: Fix Chain building if CMAKE runtime paths not set
* NDots configuration should allow a value of zero. [PR #735](https://github.com/c-ares/c-ares/pull/735)

[conan-center-bot]

:vertical_traffic_light: Thank for your Bump dependencies PR. The build service will be triggered soon by a Conan team member.

[jcar87]

@jcar87 so no ongoing bugfixes?

I have not said that at all - if the libcurl recipe benefits from bugfixes in the c-ares dependency, please express that in the PR and this will be prioritised accordingly.

What if you don't build with the new dependencies, and something breaks and then you have a CVE, but then you haven't updated for six months because there wasn't a CVE? Now you have to spend time refactoring your code to be compatible with the dependency instead of merging the fix...

libcurl is compatible with c-ares from versions 1.6.0 onwards, and c-ares is a C library with known long-term backwards compatibility, soo unless new versions of c-ares remove something that libcurl depends on, OR new versions of libcurl start requiring a newer version of c-ares - in this particular instance the scenario you are describing seems very unlikely to happen.

Now you have to spend time refactoring your code to be compatible with the dependency instead of merging the fix... Looking at the history of this recipe I cannot find a single instance where updating the c-ares dependency to a newer version also required changes in the code or made older versions incompatible.

We're trying to avoid having literally every recipe forked.

When expressing your dependencies, you can specify an override, as detailed in the documentation: https://docs.conan.io/1/reference/conanfile/methods.html#requirements - precisely to avoid having to touch all the recipes in your dependency graph - so you don't have to fork the recipes to achieve a build of libcurl with c-ares/1.28.1

* CMake: don't overwrite global required libraries/definitions/includes which could cause build errors for projects chain * building c-ares. [Issue #729](https://github.com/c-ares/c-ares/issues/729)
* On some platforms, netinet6/in6.h is not included by netinet/in.h and needs to be included separately. [PR #728](https://github.com/c-ares/c-ares/pull/728)
* Fix a potential memory leak in ares_init(). [Issue #724](https://github.com/c-ares/c-ares/issues/724)
* Some platforms don't have the isascii() function. Implement as a macro. [PR #721](https://github.com/c-ares/c-ares/pull/721)
* CMake: Fix Chain building if CMAKE runtime paths not set
* NDots configuration should allow a value of zero. [PR #735](https://github.com/c-ares/c-ares/pull/735)

Does the libcurl codebase benefit from any of these changes?

[jcar87]

Fixes the following bugs with c-ares 1.27, as I'm sure @jcar87 will appreciate... Compiles for us on MacOS (ARM, x86_64), Linux (ARM, PowerPC, x86_64, S/390), Windows 11 (x86_64)

We currently have 610 pull requests to review and merge. The reason they take a long time to merge is because this simply exceeds the capacity of the team, and we are trying to ensure we can prioritise pull requests that benefits users.

A high number of pull requests, while useful and correct, but do not provide any immediate benefits to the users - but they do take both CI and reviewers time, to the point where this can divert time from more immediate needs. A lot of pull request also provide zero context or description - which makes it harder to prioritise.

Undue insistence on using the latest because is the latest, was a factor in the recent xz backdoor: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708 - we do have a responsibility in vetting the changes that are merged into Conan Center, and it's not unreasonable to expect contributors to articulate their needs that justify the proposed changes.

Ubuntu 24.04 which was released two weeks ago uses the version of c-ares that is currently in the recipe, 1.27.0 - and throughout the entire lifetime of the LTS, it will continue to be 1.27.0 - with bugfixes and security issues backported where appropriate. I'm not saying we will never update the recipe to use a newer version, or that we are ONLY going to update it once an actual need arises - what we are saying is that we are no longer automatically accepting unjustified version bumps. We are planning to deprecate support for Conan 1.x in conan center recipes later this year, and increase the use of version ranges so that the solver can pick the most recent version for recipes where it is appropriate or convenient to do so - so this will stop being a problem for a lot of dependencies altogether. The Conan client does offer multiple ways of overriding version requirements in a graph, without touching any recipe - which should lessen the urgency to upstream or merge things into Conan Center given that users have full control without having to fork the repository.

[jcar87]

superseded by https://github.com/conan-io/conan-center-index/pull/23918