[curl] ngtcp2 http3 curl features

[talregev]

Add ngtcp2 http3 curl features

These features is not experimental in http3 curl:
https://curl.se/docs/http3.html

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

• Depends on [c-ares] Update to 1.33.0, fix uwp #40224

[bradh352]

c-ares should be fixed in c-ares/c-ares@3fd5925

[talregev]

@bradh352 Thank you for your fix!

[dg0yt]

@bradh352 Thanks for the quick action. I did the vcpkg PR in #40224.

[talregev]

@dg0yt I am trying to debug on my local windows why cmake fail.

[527/528] C:\Windows\system32\cmd.exe /C "cd /D D:\b\cmake\x64-windows-dbg && D:\b\cmake\x64-windows-dbg\bin\cmake.exe -P cmake_install.cmake"
FAILED: CMakeFiles/install.util 
C:\Windows\system32\cmd.exe /C "cd /D D:\b\cmake\x64-windows-dbg && D:\b\cmake\x64-windows-dbg\bin\cmake.exe -P cmake_install.cmake"
ninja: build stopped: subcommand failed.

[talregev]

@dg0yt I cannot reproduce the error in my local machine. Maybe is a CI thing? Maybe permissions?

[dg0yt]

@dg0yt I cannot reproduce the error in my local machine. Maybe is a CI thing? Maybe permissions?

It is unclear because there is no error message. It might help to inspect the file.
(Sorry, I don't have MSVC. I would have to do this check with vcpkg CI.)

[JonLiu1993]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[talregev]

@JonLiu1993 Can you stop the ci for this PR?
We reproduce the error on #40224

[talregev]

This PR depends on #40224

[talregev]

@JonLiu1993 This PR is ready for review.

[dg0yt]

We don't want to link m with the absolute path. You can use find_library to check for it, but just link m.

[talregev]

ok. I already submit this patch to upstream and they merge it.
So next version of curl, you will need to patch it again.

[dg0yt]

And the other issue is that fix belongs to the wolfssl cmake package.
curl/curl#14343 (comment)

[talregev]

I think it better to create a PR and fix the way you think it is, instead just tell them a comment on a closed PR.

[dg0yt]

Adding a note close to the issue is just the quick start. Creating good PRs is done separately.

[dg0yt]

So these features implement alternatives.

Basically curl wouldn't need two http3 features because the choice of ssl backend has already been made with other features. But you want to have a dependency on ngtcp2 with the right ssl feature enabled.

[talregev]

@JonLiu1993 I answered all the points for @dg0yt .
Please review my PR

[talregev]

@JonLiu1993
PR is ready for review.

[vicroms]

We'll be discussing this one in the next meeting.

[BillyONeal]

Related / new information from last we looked: https://samueloph.dev/blog/debian-curl-now-supports-http3/

[dg0yt]

Related / new information from last we looked: https://samueloph.dev/blog/debian-curl-now-supports-http3/

Unfortuately, the Debian situation can't be easily serve as a guide for vcpkg. (Binary packages, alternative packages, GPL, schannel.)

[BillyONeal]

Related / new information from last we looked: https://samueloph.dev/blog/debian-curl-now-supports-http3/

Unfortuately, the Debian situation can't be easily serve as a guide for vcpkg. (Binary packages, alternative packages, GPL, schannel.)

I agree, we certainly wouldn't be able to do this for Windows. But we at least aren't going to be trailblazers on doing this.

I'm still mildly pessimistic about being able to ship this as is but I haven't truly looked into the details. In particular, I'm worried about vcpkg customers out there who might be talking to OpenSSL in their process with the expectation of that affecting libcurl, that would break if we changed the default backend.

Crucially, the system's configured TLS root certificates need to be respected at a bare minimum; this is what forces SChannel on Windows.

[BillyONeal]

Unfortuately, the Debian situation can't be easily serve as a guide for vcpkg. (Binary packages, alternative packages, GPL, schannel.)

Yeah, this looks to be the case. The thing that changed in Debian is what curl the command line utility uses -- it now uses libcurl-gnutls.so as its backend. libcurl.so remains the OpenSSL flavor. As vcpkg models the library one rather than the command line utility I still think people would be angry if we changed this, sadly.

I'm going to ask other maintainers for more thoughts given this information.

[talregev]

@BillyONeal
Can I know the result of the vcpkg team review?

Thank you in advance! 🙏🏻

[BillyONeal]

I explained the above and @AugP @vicroms @JavierMatosD @data-queue and @ras0219-msft seem convinced that Debian unfortunately can't serve as a blueprint for us here, given that we model libcurl.so Debian did not change, not /bin/curl which Debian changed.

We would still be extremely happy with instructions in the port describing how to make an overlay-port that has these effects, but we don't think changing the default TLS implementation from OpenSSL on the POSIX platforms is a change we can safely make at this time. :(

[talregev]

Thank you for the details answer.
How my change here change the default ssl?.

[BillyONeal]

Thank you for the details answer. How my change here change the default ssl?.

It breaks multi-TLS meaning we would have to make requesting one of the other TLS backends require making an overlay-port under https://learn.microsoft.com/en-us/vcpkg/contributing/maintainer-guide#do-not-use-features-to-implement-alternatives

(I'm not closing the PR though because this area is still kind of in a state of flux)

[BillyONeal]

Is this replaced by #46459 ?

[talregev]

Yes.