curl: upgrade to 8.7.1 to address CVEs

[blair (Blair Zajac)]

curl 8.7.1 addresses a number of CVEs: ​https://daniel.haxx.se/blog/2024/03/27/curl-8-7-0/

Can we get an upgrade?

BTW, is curl an important port that it doesn't have openmaintainer?

[ryandesign (Ryan Carsten Schmidt)]

Right, I'll do that.

Indeed, I had not set this port to openmaintainer because it felt important enough to me to want to control it more closely. Should I change that?

[blair (Blair Zajac)]

Not having done upgrades to curl for minor or patch level upgrades, I cannot say the likelihood of running into an issue. If it were openmaintainer, I would be happy to do upgrades.

One could let openmaintainer only for patch level upgrades, e.g. 8.7.1 to 8.7.2 say, but for minor version upgrades, leave that to you, e.g. 8.7.2 -> 8.8.0?

[ryandesign (Ryan Carsten Schmidt)]

We do already have a security policy that anyone can commit an update to a port, even if not openmaintainer, if it resolves a security issue. This justification has been used in previous curl updates such as [47e2121c484a5a5192ac9ffd593d04da2a11d31b/macports-ports] and would apply to the 8.7.1 update and indeed to most new curl versions since most of them resolve some minor CVE. But I am working on the update now so just give me a minute.

One reason why I keep a tighter reign on projects like curl and gettext and libpng is that they provide fundamental functionality where breaking them would affect a large number of ports. When I update these ports I keep a close eye on the buildbot and make sure it builds on all OS versions, and if it doesn't, I try to quickly remedy the situation (for example [65b98a2a23939a4f6c4366c5a128a9357c0909fc/macports-ports]). If others update the port under the openmaintainer umbrella they might not do that which could result in a large number of subsequently updated ports failing to build on the buildbot which would require significant work to reschedule the failed builds after the problem is resolved. Not to mention the inconvenience to users of the systems on which it failed. I'd rather avoid that by, well, maintaining these ports.

The other reason with curl is that it is one of the few ports I maintain that I am more involved with. With most ports I just update them and barely know what the software does, but with curl I am subscribed to their mailing lists, I file bug reports and pull requests, I've participated in a recent curl meeting, and I do use curl myself. I may be deliberately holding back an update because a problem with that release is currently being discussed on the mailing list.

Also curl updates are a little more complicated than normal updates. Updating curl requires revbumping p5-www-curl as well. It says so in the port but drive-by contributors might overlook that. And by the time that a curl update is available, probably an update of curl-ca-bundle is available, so I do that first, and that's a little more complicated than a normal update, and also documented, but possibly more complicated than someone else really wants to tackle.

There may be changes other than updates that I was planning to include with the next port update, which would be a bit silly to revbump the port for all on their own.

So many reasons!

You are certainly always welcome to submit a pull request for any port. Then a maintainer can easily approve it or request changes or make other comments.

[ryandesign (Ryan Carsten Schmidt)]

In 73bbfd3f99a3b448707301cce5b926f98e42a3d7/macports-ports (master):

curl: Update to 8.7.1; build & run tests in parallel

Closes: #69605

[ryandesign (Ryan Carsten Schmidt)]

In 72f7e3a05b1eb44ad36da7e9087691fd2677f166/macports-ports (master):

p5-www-curl: Revbump for curl 8.7.1

See: #69605