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: Feature proposal: Command line option support for OpenSSL providers
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Michael Baentsch via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 13 Oct 2021 09:41:09 +0200
Am 12.10.21 um 18:01 schrieb Daniel Stenberg:
>
> That's pretty much what I meant. Why not repurpose curl's --engine
> option for "providers" when using OpenSSL 3?
>
Sorry I didn't get it before. That might be a viable approach -- with
question marks:
Let me expand whether I got it right: Is your suggestion to "overload"
the -engine option, i.e., load engines for OSSL111-based curl and
providers for OSSL3-based curl build? Thinking this through, these might
be issues:
1) Looking at the curl code for engines, I'm not sure it maps well to
providers: Correct me if I'm wrong, but it looks like there can only be
one engine active at any one time whereas there can be arbitrarily many
providers for different aspects of TLS (X509, signing, digesting, KEM, etc).
2) engines still exist in OSSL3, so simply calling provider APIs in an
OSSL3 build of curl (and engine APIs for OSSL111) would exclude engines
completely in curl/OSSL3.
3) curl users may be confused: A provider is conceptually different from
an engine so users may simply not "see" this new curl functionality
(provider support) by looking at the option name (-engine).
2) Might be addressed by logic allowing curl to check whether the shared
lib is an engine or a provider --probably straightforward testing for
the presence of the symbol "OSSL_provider_init". However, that in turn
could confuse the OpenSSL config logic which keeps the two concepts/APIs
clearly separate. 3) Is a question of documentation--that we hope people
read. 1) Seems to be the toughest: For example ossl_set_engine_default
cannot be replicated; the notion of multiple providers, i.e., adding the
option -engine multiple times on the command line (or once with a new
parameter syntax allowing for multiple providers) has me scratching my
head how to align with the logic here for example:
https://github.com/curl/curl/blob/3aead057a1fd5cb95e9fadec44b2c4c6f25d3644/lib/vtls/openssl.c#L1327-L1331
Date: Wed, 13 Oct 2021 09:41:09 +0200
Am 12.10.21 um 18:01 schrieb Daniel Stenberg:
>
> That's pretty much what I meant. Why not repurpose curl's --engine
> option for "providers" when using OpenSSL 3?
>
Sorry I didn't get it before. That might be a viable approach -- with
question marks:
Let me expand whether I got it right: Is your suggestion to "overload"
the -engine option, i.e., load engines for OSSL111-based curl and
providers for OSSL3-based curl build? Thinking this through, these might
be issues:
1) Looking at the curl code for engines, I'm not sure it maps well to
providers: Correct me if I'm wrong, but it looks like there can only be
one engine active at any one time whereas there can be arbitrarily many
providers for different aspects of TLS (X509, signing, digesting, KEM, etc).
2) engines still exist in OSSL3, so simply calling provider APIs in an
OSSL3 build of curl (and engine APIs for OSSL111) would exclude engines
completely in curl/OSSL3.
3) curl users may be confused: A provider is conceptually different from
an engine so users may simply not "see" this new curl functionality
(provider support) by looking at the option name (-engine).
2) Might be addressed by logic allowing curl to check whether the shared
lib is an engine or a provider --probably straightforward testing for
the presence of the symbol "OSSL_provider_init". However, that in turn
could confuse the OpenSSL config logic which keeps the two concepts/APIs
clearly separate. 3) Is a question of documentation--that we hope people
read. 1) Seems to be the toughest: For example ossl_set_engine_default
cannot be replicated; the notion of multiple providers, i.e., adding the
option -engine multiple times on the command line (or once with a new
parameter syntax allowing for multiple providers) has me scratching my
head how to align with the logic here for example:
https://github.com/curl/curl/blob/3aead057a1fd5cb95e9fadec44b2c4c6f25d3644/lib/vtls/openssl.c#L1327-L1331
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-10-13