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: Daniel Gustafsson via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 14 Oct 2021 12:05:57 +0200
> On 13 Oct 2021, at 09:41, Michael Baentsch via curl-library <curl-library_at_lists.haxx.se> wrote:
> 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).
That part would be fixable with a matter of programming. If we know what type
X is in --engine=X we can handle it correctly, the current code for engines not
being applicable makes sense as handling providers would require net new
functionality.
> 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.
This makes it a showstopper though IMO. From a brief skim it seems like
engines and providers can have the same name, making it hard to know which one
the user wanted.
> 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).
Thats a matter of documentation.
Date: Thu, 14 Oct 2021 12:05:57 +0200
> On 13 Oct 2021, at 09:41, Michael Baentsch via curl-library <curl-library_at_lists.haxx.se> wrote:
> 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).
That part would be fixable with a matter of programming. If we know what type
X is in --engine=X we can handle it correctly, the current code for engines not
being applicable makes sense as handling providers would require net new
functionality.
> 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.
This makes it a showstopper though IMO. From a brief skim it seems like
engines and providers can have the same name, making it hard to know which one
the user wanted.
> 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).
Thats a matter of documentation.
-- Daniel Gustafsson https://vmware.com/ -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-10-14