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: Wed, 13 Oct 2021 09:15:34 +0200
> On 12 Oct 2021, at 18:01, Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se> wrote:
> On Tue, 12 Oct 2021, Info via curl-library wrote:
>> Even clearer: https://www.openssl.org/docs/man3.0/man1/openssl-engine.html: "This command has been deprecated. Providers should be used instead of engines."
This is to me a good reason not to make --provider. We already now have a
soon-to-be-dead parameter in --engine that we have to maintain for most of
eternity, and there are no guarantees that OpenSSL 4 won't deprecate providers
in favor of a new name (with some level of devils advocate involved). Tying
curl parameters to backend specific constructs risks building up an unwieldy
set of parameters where only small disjoint sets apply to non-EOL'd specific
versions.
> That's pretty much what I meant. Why not repurpose curl's --engine option for "providers" when using OpenSSL 3?
There is the risk that a rogue actor could subvert an application by adding an
OpenSSL provider during an upgrade with the same name as a previous engine.
Now, attackers with access to doing that are of course probably able to do
worse things due to system privileges, but this could be a passive hard-to-
detect vector.
That being said, I'm not sure I have too many better ideas at the moment.
Date: Wed, 13 Oct 2021 09:15:34 +0200
> On 12 Oct 2021, at 18:01, Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se> wrote:
> On Tue, 12 Oct 2021, Info via curl-library wrote:
>> Even clearer: https://www.openssl.org/docs/man3.0/man1/openssl-engine.html: "This command has been deprecated. Providers should be used instead of engines."
This is to me a good reason not to make --provider. We already now have a
soon-to-be-dead parameter in --engine that we have to maintain for most of
eternity, and there are no guarantees that OpenSSL 4 won't deprecate providers
in favor of a new name (with some level of devils advocate involved). Tying
curl parameters to backend specific constructs risks building up an unwieldy
set of parameters where only small disjoint sets apply to non-EOL'd specific
versions.
> That's pretty much what I meant. Why not repurpose curl's --engine option for "providers" when using OpenSSL 3?
There is the risk that a rogue actor could subvert an application by adding an
OpenSSL provider during an upgrade with the same name as a previous engine.
Now, attackers with access to doing that are of course probably able to do
worse things due to system privileges, but this could be a passive hard-to-
detect vector.
That being said, I'm not sure I have too many better ideas at the moment.
-- Daniel Gustafsson https://vmware.com/ -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-10-13