Daniel Stenberg wrote:

> On Mon, 10 Dec 2001, Götz Babin-Ebell wrote:
>
> > > > 1. curl_global_init() got an additional parameter: const char *param:
> >
> > > Ugha. We don't want to change this. It would blow compatibility with
> > > almost every curl-using program out there.
> >
> > ENGINE_set_default() should be called early in the program.
>
> "early" as in how early? Isn't it enough if done before we create the SSL
> "context"? (Which we do in lib/ssluse.c:Curl_SSLConnect)

Best is:
Bevore you start any cryptographic operation, or access any key
Could be done with curl_easy_setopt(), but must be done
bevore you set or access the key.

> > Perhaps some additional curl_easy_setopt() options:
> >
> > 1. CURL_SSL_ENGINE_NAME:
> > parameter: engine name
> > load an ENGINE and set it to the data structures...
> > calls ENGINE_set_default()
> > 2. CURL_SSL_ENGINE_NAME2:
> > like 1. but don't call ENGINE_set_default()
> > (for second session...)
> > 3. CURL_SSL_SET_ENGINE
> > parameter: pointer to an ENGINE
> > sets this as ENGINE
> > 4. CURL_SSL_GET_ENGINE
> > parameter: pointer to a memory area that will get the actual
> > ENGINE pointer
>
> Ok, here's a whole range of questions coming up. I'm just so clueless here.

As I said:
I'm not part of the OpenSSL core team either...

> What exactly is an "ENGINE" in the (Open)SSL sense?

It is a construct to let OpenSSL do cryptographic operations with
external modules.
These modules (normally) do the cryptographic operations in hardware
modules
that store the private key.

> What's the difference between CURL_SSL_ENGINE_NAME2 and CURL_SSL_SET_ENGINE
> in your suggestion above? Why do we need two "ENGINE_NAME*" options?
> Shouldn't curl itself keep track of which engines it has loaded and keep the
> user unknowing and uncaring only to decide which one to actually use? So

CURL *sess1 = curl_easy_init();
curl_easy_setopt(sess1,CURL_SSL_ENGINE_NAME,"chil");

[...]
CURL *sess2 = curl_easy_init();
curl_easy_setopt(sess2,CURL_SSL_ENGINE_NAME2,"chil");
[...]

ENGINE_set_default() is not called in _setopt() for sess2.
It might be possible another ENGINE_set_default() causes trouble
(I don't know, but I want to be on the save side...)

> Why would anyone like to get to know the "actual ENGINE pointer"
> (CURL_SSL_GET_ENGINE)?

To store it internal (for own use) or to set it for another CURL...

> > > > 2. curl_global_init(): additional flag CURL_GLOBAL_SSL_XTRN:
> > > > signaling the ssl submodule that OpenSSL is initialized external
> > > > and no init is needed.
> > >
> > > Which then would be the complete opposite of the CURL_GLOBAL_SSL option
> > > and I can't see why CURL_GLOBAL_SSL_XTRN is needed then. Can't you just
> > > not use CURL_GLOBAL_SSL instead?
> >
> > From a glance in the code I belived you have to call Curl_SSL_init() to use
> > the SSL functionality. But now I don't find the reference...
>
> The libcurl user calls curl_global_init() with the appropriate flags. If done
> correctly, and the library is build with SSL support, libcurl will itself
> call its internal function Curl_SSL_init(). That's correct.
>
> But it also means that you can set the flags to *NOT* init OpenSSL by
> specifying only flags that aren't related to SSL (in a manner similar to:
> curl_global_init(~CURL_GLOBAL_SSL);). That'll give the same effect your
> suggested CURL_GLOBAL_SSL_XTRN flag has. If I'm not misunderstanding you
> here.

Somehow I thought if you use the SSL functionally without a
Curl_SSL_init(),
a Curl_SSL_init() is automagically done.
I wanted to prevent that.

Sometimes I am a master of shooting myself in the foot.
So it is better to be save than sorry...

Bye

Goetz

-- 
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0,  Fax: +49-(0)40 80 80 26 -126