Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Warning: you build with a TLS library without TLS 1.3 support
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Aleksandar Lazic via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 8 Feb 2024 22:25:32 +0100
Hi.
On 2024-02-08 (Do.) 22:07, Daniel Stenberg via curl-library wrote:
> 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.
I'm not a Apple Fan but to be honest the "Secure Transport" is deprecated since
2019 as shown on the apple site.
https://developer.apple.com/documentation/technotes/tn3151-choosing-the-right-networking-api#TLS-best-practices
```
Don’t use Secure Transport for your TLS implementation. It’s been deprecated
since 2019 (see Versions) and doesn’t support TLS 1.3. If you have existing code
that uses Secure Transport, make a plan to migrate off it.
```
Looks like nobody have picked the task to implement the "Network framework" in
the open source curl project.
I like the pull as it reminds the People that there could be a improvement and
maybe somebody pick the task to port curl to the "Network framework" from Apple.
>> 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.
Regards
Alex
Date: Thu, 8 Feb 2024 22:25:32 +0100
Hi.
On 2024-02-08 (Do.) 22:07, Daniel Stenberg via curl-library wrote:
> 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.
I'm not a Apple Fan but to be honest the "Secure Transport" is deprecated since
2019 as shown on the apple site.
https://developer.apple.com/documentation/technotes/tn3151-choosing-the-right-networking-api#TLS-best-practices
```
Don’t use Secure Transport for your TLS implementation. It’s been deprecated
since 2019 (see Versions) and doesn’t support TLS 1.3. If you have existing code
that uses Secure Transport, make a plan to migrate off it.
```
Looks like nobody have picked the task to implement the "Network framework" in
the open source curl project.
I like the pull as it reminds the People that there could be a improvement and
maybe somebody pick the task to port curl to the "Network framework" from Apple.
>> 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.
Regards
Alex
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-02-08