curl-users
Re: 7.9.2 solaris 2.5.1 compile (was Re: I am amazed...)
Date: Mon, 10 Dec 2001 09:07:44 +0100 (MET)
On Thu, 6 Dec 2001, Götz Babin-Ebell wrote:
(I'm CC'ing this to the libcurl list and follow-ups should probably go there,
as we're now talking libcurl API changes/improvements etc.)
> > No. The client code should not use the library's config.h file, it has its
> > own in src/config.h. Besides, the client code should not need socklen_t and
> > in_addr_t. Why do your compiler require them?
>
> if you configure with --enable-debug, src/main.c and src/urlglob.c
> include lib/memdebug.h. And in lib/memdebug.h you need at least
> socklen_t. If you set the #define socklen_t int from config.h in the
> src/config.h, you don't need need the config.h...
Well, the --enable-debug is a developers-only option and the include of
lib/memdebug.h from the client code (that it activates) is a kludge in
itself. We should make sure that it includes the proper includes within that
file, we should not pollute the client source codes for other conditions.
> My changes in the interface of the library:
> 1. curl_global_init() got an additional parameter: const char *param:
> a comma seperated list of name=value-pairs,
> for engine support I have added "CRYPTO_ENGINE=<engine>"
Ugha. We don't want to change this. It would blow compatibility with almost
every curl-using program out there. Why do we need to specify that already in
the curl_global_init()? And why do we need a global variable for the
'crypto_engine' stuff? Why can't we set that option like we set other options
with curl_easy_setopt()?
I'm sorry, but I'm not very familiar with this OpenSSL engine stuff so if my
questions seem silly, please bear with me.
> 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?
> 3. SSLCERTPASSWD is an alias for (new) SSLKEYPASSWD:
> The certificate is public information, you need the pass phrase to
> decrypt
> the private key.
> 4. new SSLCERTTYPE: (string) "DER","PEM","ENG":
> allow to read DER coded cert from file and read cert from engine
> (not supported jet)
> 5. new SSLKEY: (string):
> set (file) name for private key
> 6. new SSLKEYTYPE: (see SSLCERTTYPE)
> support to load key from engine (no support for passphrase callback)
I like these.
> 2. Since curl_global_init() is called bevore the parameter list is
> parsed,
> I added an environmental variable (CURL_INIT_PARAMS).
> Not good but a fast solution ;-)
Eeeeh. That's just too icky. I don't like that.
> 3. Additional parameter to set passphrase:
> Since now we have a parameter to set the private key, we shouldn't
> set the passphrase with the certificate and I didn't want to stick it
> to the file name...
Very valid change.
Taken all together, I haven't applied your patch yet. There's a few items
that need to be sorted out first.
-- Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/Received on 2001-12-10