On 17-03-13 01:32, cnm marketing wrote:
> Service layer - a daemon/service, it also contains many libraries (i.e.
> *.so on Linux), this layer use bsafe ssl, as well as openssl, this layer
> has its own bsafe and openssl libraries come with this layer.

Mental note #1:
Ok, you have openssl and bsafe here...

> AAA Layer - plugin libraries (i.e. *.so), is loaded by Service Layer.
> This layer load libcurl via dlopen()/dlclose() and use libcurl routines
> to communicate to remote server to retrieve data. This layer do not do
> any openssl by itself (except libcurl invoke openssl). I believe libcurl
> will use the openssl in the local system ??!!

Mental note #2:
You load libcurl dynamically at run-time here. I'll take a wild educated
guess here and state that the above loaded OpenSSL will be used to
satisfy the libcurl library loading dependencies.

> API layers - many libraries, these libraries are linked into AAA Layer
> via compile link time. This layer uses openssl to communicate to the
> other remote server (not the same remote server in AAA Layer), it has
> its own openssl library come with this layer

Mental note #3:
This layer has its own OpenSSL too... and if I understand it, you now
have at least two OpenSSL libraries mapped in the same memory space. If
I'm not mistaken the last loaded library functions will be used, unless
you directly use a dlsym() calls to call one particular flavor of a
function. But... internally in the OpenSSL you should be getting
cross-overs between the loaded OpenSSL function pointers.

I've seen these kind of situations happen before accidentally where two
different versions of OpenSSL were loaded in the same memory space.

I'd refer to such situations as Russian Roulette Memory Bingo. This
could actually work. But you're walking on a very thin line of success.

> When the service layer starts, AAA Layer gets loaded into the service
> layer. Before libcurl in AAA Layer is called, the API Layers are getting
> loaded by AAA Layer, in the meantime, the openssl in API layers is
> getting call first. Then the libcurl in AAA Layer gets call and produce
> the error ""*error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key
> size too small" in libcurl output file via option CURLOPT_STDERR.
>
> However, on the same Linux system, I create a small program and uses the
> EXACT libcurl routines with dlopen()/dlclose(), this program retrieves
> the data from the same remote server just fine with
> CURLOPT_SSL_VERIFYPEER to 1 or 0, i.e. with cert.pem or without cert.pem.
>
> Hopefully this is clear enough.

Yes. I believe I have gathered sufficient statistics to determine with a
high degree of certainty that the origin of the problem is NOT with
libcurl at all.

The only advise that I can give you is to normalize on one flavor of
OpenSSL per process. If normalization is not an option, I'd recommend to
run the plug-ins in a separate process space. A hack could be to use
libcurl without SSL use and setup stunnel as a last resort to avoid
using SSL on your many layers.

        Oscar

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html