On Thu, 8 Feb 2024, Ryan Schmidt wrote:
Good idea! However I would not necessarily position it as a library that
"has not bothered" to implement this. I don't know the situation with
BearSSL or mbedTLS, but my understanding with Secure Transport is that Apple
has deprecated it and will therefore not add new features like TLS 1.3 or
QUIC to it, and would like you to adopt Network framework instead in which
they have implemented support for TLS 1.3 and QUIC.
Apple did not bother to add TLS 1.3 to Secure Transport. And then they did not
bother to add support to curl for what they think we should use instead of
Secure Transport. And nobody else has bothered either.
I presume because the alternatives are good enough.
One might conceivably say that it is curl that "has not bothered" to adopt
Apple's new networking interface.
Clearly nobody cares enough to make curl work with "the Network framework".
(Is that really what they call it?)
The point here is not the word "bother" that I used in my email (but not in
the PR). The point is to alert users about selecting to build curl with a
solution that seems to not be getting a lot of attention and support.
It does not matter from whom they do not get support. The point is that those
solutions don't support the latest version more than five years since the spec
for it shipped.
This has come up before. Last year, on the topic of adding Network framework
support to curl, you wrote:
I don't see this happening anytime soon.
Has anything changed about that since then? Is support for Network framework
something you imagine getting around to eventually or would you prefer that
someone else work on it and contribute it?
I don't see myself work on this anytime soon, no.
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
