Buy commercial curl support. 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 Daniel himself.
Re: System certificate store support in macOS
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Demi Marie Obenour <demiobenour_at_gmail.com>
Date: Mon, 25 Aug 2025 15:49:57 -0400
On 8/22/25 17:04, Daniel Stenberg wrote:
> On Fri, 22 Aug 2025, Demi Marie Obenour via curl-library wrote:
>
>> I think the best option would be to add support for Network.framework. The
>> preferred way to use Network.framework is with a user-mode network stack
>> included in macOS and iOS, but it is also possible to use it with sockets
>> via a custom framer. Sockets have lower performance compared to the
>> user-mode network stack included in Network.framework, though.
>
> I don't think that's possible. I used to, but after having seen attempts to go
> that route I'm no longer convinced.
>
> I'm not an expert on anything macOS so I might be wrong here, but based on the
> past PR for exactly that (https://github.com/curl/curl/pull/17509) it turned
> out that we would have to make quite enourmous sacrifices to make curl work
> with the Network.framework. Too big for us to accept really. We can't have a
> TLS backend that basically takes over and replaces half of everything curl
> does (and done in a slightly different, unique, way), because it's going to be
> a pain to maintain, to document, to test and it would end up a frankencurl no
> one would like.
>
> Adding support for the native CA store seems like teeny tiny job in
> comparison.
VPN On Demand requires using a connect-by-name API. Is this the problem with
that PR, or is it that curl needs an actual socket file descriptor?
Received on 2025-08-25
Date: Mon, 25 Aug 2025 15:49:57 -0400
On 8/22/25 17:04, Daniel Stenberg wrote:
> On Fri, 22 Aug 2025, Demi Marie Obenour via curl-library wrote:
>
>> I think the best option would be to add support for Network.framework. The
>> preferred way to use Network.framework is with a user-mode network stack
>> included in macOS and iOS, but it is also possible to use it with sockets
>> via a custom framer. Sockets have lower performance compared to the
>> user-mode network stack included in Network.framework, though.
>
> I don't think that's possible. I used to, but after having seen attempts to go
> that route I'm no longer convinced.
>
> I'm not an expert on anything macOS so I might be wrong here, but based on the
> past PR for exactly that (https://github.com/curl/curl/pull/17509) it turned
> out that we would have to make quite enourmous sacrifices to make curl work
> with the Network.framework. Too big for us to accept really. We can't have a
> TLS backend that basically takes over and replaces half of everything curl
> does (and done in a slightly different, unique, way), because it's going to be
> a pain to maintain, to document, to test and it would end up a frankencurl no
> one would like.
>
> Adding support for the native CA store seems like teeny tiny job in
> comparison.
VPN On Demand requires using a connect-by-name API. Is this the problem with
that PR, or is it that curl needs an actual socket file descriptor?
-- Sincerely, Demi Marie Obenour (she/her/hers)
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-keys attachment: OpenPGP public key
- application/pgp-signature attachment: OpenPGP digital signature