Revert "Update curl/curl from curl-8_6_0 to curl-8_7_1"

What does this MR do?

Revert "Update curl/curl from curl-8_6_0 to curl-8_7_1"

This reverts commit 7c0841da.

Related issues

2024-04-13: Some push (remote) mirrors failing ... (gitlab-com/gl-infra/production#17828 - closed) • Stan Hu

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

• MR title and description are up to date, accurate, and descriptive.
• MR targeting the appropriate branch.
• Latest Merge Result pipeline is green.
• When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow.

For GitLab team members

If you don't have access to this, the reviewer should trigger these jobs for you during the review process.

• The manual Trigger:ee-package jobs have a green pipeline running against latest commit.
• If config/software or config/patches directories are changed, make sure the build-package-on-all-os job within the Trigger:ee-package downstream pipeline succeeded.
• If you are changing anything SSL related, then the Trigger:package:fips manual job within the Trigger:ee-package downstream pipeline must succeed.
• If CI configuration is changed, the branch must be pushed to dev.gitlab.org to confirm regular branch builds aren't broken.

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes.
• Documentation created/updated.
• Tests added.
• Integration tests added to GitLab QA.
• Equivalent MR/issue for the GitLab Chart opened.
• Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.

changed milestone to %16.11

added Broken Pipeline devopssystems group::distributionbuild groupdistribution master:broken priority1 sectioncore platform severity1 labels

assigned to @deriamis

requested review from @rmarshall

	3 Warnings
	You've made some changes to the software definitions. Any change in software definition requires: package rebuild to verify that builds across the supported platforms are successful. manual verification to confirm the package is installable uses an approved license If the change does not affect existing functionality, for example when resolving rubocop warnings, adding comments, or fixing typos, add one of the following labels: maintenancepipelines maintenanceworkflow
	Please add a merge request subtype to this merge request.
	Please add a merge request type to this merge request.

	2 Messages
	CHANGELOG missing: If you want to create a changelog entry for GitLab FOSS, add the Changelog trailer to the commit message you want to add to the changelog. If you want to create a changelog entry for GitLab EE, also add the EE: true trailer to your commit message. If this merge request doesn't need a CHANGELOG entry, feel free to ignore this message.
	Once your MR is ready for review you can comment @gitlab-bot ready <@user> to request the first review to someone. It's recommended that you pick the one suggested by the reviewer roulette. But you can ignore it and assign it to someone else if you see fit. Merge requests are handled according to the workflow documented in our handbook and should receive a response within the limit documented in our Service-level objective (SLO). If you don't receive a response from the reviewer within the SLO, please mention @gitlab-org/distribution, or one of our Project Maintainers

Reviewer roulette

Changes that require review have been detected! A merge request is normally reviewed by both a reviewer and a maintainer in its primary category and by a maintainer in all other categories.

To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.

To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.

Once you've decided who will review this merge request, mention them as you normally would! Danger does not automatically notify them for you.

Reviewer	Maintainer
@pursultani (UTC+10, 17 hours ahead of @deriamis)	@balasankarc (UTC+5.5, 12.5 hours ahead of @deriamis)

If needed, you can retry the danger-review job that generated this comment.

Generated by Danger

changed the description

Proper labels assigned to this merge request. Please ignore me.

@deriamis - please see the following guidance and update this merge request.

	1 Error
	Please add typebug typefeature, or typemaintenance label to this merge request.

added maintenancepipelines label

added typemaintenance label

marked the checklist item MR title and description are up to date, accurate, and descriptive. as completed

marked the checklist item MR targeting the appropriate branch. as completed

resolved all threads

marked the checklist item Latest Merge Result pipeline is green. as completed

approved this merge request

marked this merge request as ready

added workflowin review label

marked the checklist item When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow. as completed

We believe this fixes the problem that looks like what got reported upstream in https://github.com/curl/curl/issues/13229

The upstream fix at https://github.com/curl/curl/commit/721941aadf4adf4f6aeb3f4c0ab489bb89610c36 is not yet in a release.

approved this merge request

enabled an automatic merge when the pipeline for 0f4e6e65 succeeds