Do not set CURLOPT_SSLENGINEDEFAULT automatically #1042
I realize this has been a big source of pain for you but there is not enough here to justify removing this. You haven't explained why the code is incorrect for engines, though I can see in the bug why it is a problem for yours. My understanding of this is that the default engine is supposed to be used for all crypto protocols when we call
Yes, but there are very few reasons to care about that. You're right — If you have an external engine that has some kind of crypto acceleration for software keys, like Intel AES-NI instruction support, you can load that engine and it will be used for all such operations, overriding the internal OpenSSL functionality. And at https://www.openssl.org/blog/blog/2015/11/23/engine-building-lesson-2-an-example-md5-engine/ there's a lovely example of how to write your own engine to override the MD5 methods in OpenSSL.
In general, though, this isn't stunningly useful. And if it was, then OpenSSL would be configured to load that engine by default.... like it did the AESNI engine, without applications needing to ask for it.
So no, the interesting use case for the engine is not that. It's for loading certificates and private keys. The documentation for
Actually it can be used for loading certificates too, but only with engine_pkcs11 AFAIK, because the
And remember, I haven't removed the
referenced this pull request
Sep 29, 2016
Citing from OpenSC/libp11#110 (comment) where one of the core OpenSSL developers says:
He's absolutely right. The problem is that things are calling
Note that I have not changed the
In this patch I've disabled it by default, and I haven't added a command-line option to let you turn it back on again. I briefly pondered doing so but decided it wasn't worth it, because I cannot think of a single valid use case where you'd actually want to load an engine and use
Even if you live in Russia and you want to use GOST everywhere, you'll have configured OpenSSL system-wide to load that engine automatically (via
@jay: If I'm missing something, I'd be very interested to hear what you think we'd be breaking by removing it.
But what I'm saying to you is I think in our case it was intentional, it was really meant. And that option has been the same in curl for 15 years with nary a report about this.
Specifically I was referring to
Let's look at this a different way. Instead of what could break, what engines are we fixing? Is it exclusive to just pkcs, and for any engine using that name (if such things are allowed); and in that case could we make a workaround for just that? I'm still trying to wrap my head around why you wouldn't want to default any methods at all, why if your token doesn't have xxx methods OpenSSL would be using them.
I cannot think of any case where you actually want to use
I don't think this is just the PKCS#11 engine; OpenSSL currently doesn't have a way for engines to support hardware keys, without curl inappropriately marking them as the default.... even for keys which they can't handle. It's a problem for any software which calls
However, my primary motivation for turning this unnecessary behaviour off is to make it work nicely with the PKCS#11 engine... and in fact I have another way to cope with that. Because quite frankly, if I pass you the string
So I need to know that curl is built with OpenSSL, and that I need to set this silly ENGINE option to point to the PKCS#11 engine anyway... which sucks.
I plan to fix that, to make it work consistently regardless of which crypto library curl is built with. Which means that I'll implicitly set the PKCS#11 engine if we're passed a PKCS#11 URI as our certificate/key. And I suippose in that case we can avoid using
So I don't need to care about the case where anyone explicitly specifies the ENGINE at all. I can let that continue to do the silly pointless default thing that achieves nothing but to break stuff, if you really insist.