This is a multipart message in MIME format.
--=_alternative 003B475D4A257052_=
Content-Type: text/plain; charset="US-ASCII"

You are correct it is a problem in enterprise applications.
The good news is that it can be resolved, the bad news is that we did that
outside the OpenSSL codebase itself.

We created new startup/shutdown functions in another library, added
reference counting and load OpenSSL via that.
It might be possible to do something simillar within the existing API's,
but brute force did work.

Peter

Peter Waltenberg




"Steven Reddie"
Sent by: owner-openssl-dev@openssl.org
03/08/2005 06:42 PM
Please respond to
openssl-dev


To

cc

Subject
Safety of using OpenSSL from multiple components in the one process






Hi All,

This is something that I think I've raised before but don't remember
getting resolution on.

OpenSSL maintains various global variables and structures, and there are
cleanup functions that must be used to properly release the resources when
finished. One example is the OID database managed by the
"add_all_algorithms" function and it's associated release function,
EVP_cleanup. All is good when the use of OpenSSL is fairly simple, such
as a single component using it for the lifetime of the process.

Where things get difficult/dangerous is when multiple seperate components
in the one process, with no real knowledge of each other, make use of
OpenSSL, and it's even worse if they dynamically load and unload OpenSSL
using dlopen/LoadLibrary. With large enterprise applications this is a
common situation since different teams develop components that the large
product makes us of, and with the increasing use of "plug-in"
architectures the dynamic loading/unloading is not uncommon.

There seems to be no way offered by the OpenSSL API for these components
to behave well. If they each do a dlopen -> dlsym -> ... -> EVP_cleanup
-> dlclose sequence then it seems that they will trample on each other. If
they take the extreme opposite and don't call EVP_cleanup then the process
will leak until it falls over.

This is a serious issue that I believe impacts the stability and therefore
limits the usefulness of OpenSSL in large enterprise applications. Does
anyone else have any thoughts on this?

Regards,

Steven


--=_alternative 003B475D4A257052_=
Content-Type: text/html; charset="US-ASCII"



You are correct it is a problem in enterprise
applications.  


The good news is that it can be resolved,
the bad news is that we did that outside the OpenSSL codebase itself.




We created new startup/shutdown functions
in another library, added reference counting and load OpenSSL via that.


It might be possible to do something
simillar within the existing API's, but brute force did work.




Peter



Peter Waltenberg










"Steven Reddie"
<smr@essemer.com.au>


Sent by: owner-openssl-dev@openssl.org

03/08/2005 06:42 PM




Please respond to

openssl-dev









To

<openssl-dev@openssl.org>

cc



Subject

Safety of using OpenSSL from
multiple components in the one process














Hi All,

 

This is something that I think I've raised
before but don't remember getting resolution on.


 

OpenSSL maintains various global variables
and structures, and there are cleanup functions that must be used to properly
release the resources when finished.  One example is the OID database
managed by the "add_all_algorithms" function and it's associated
release function, EVP_cleanup.  All is good when the use of OpenSSL
is fairly simple, such as a single component using it for the lifetime
of the process.


 

Where things get difficult/dangerous is when
multiple seperate components in the one process, with no real knowledge
of each other, make use of OpenSSL, and it's even worse if they dynamically
load and unload OpenSSL using dlopen/LoadLibrary.  With large enterprise
applications this is a common situation since different teams develop components
that the large product makes us of, and with the increasing use of "plug-in"
architectures the dynamic loading/unloading is not uncommon.


 

There seems to be no way offered by the OpenSSL
API for these components to behave well.  If they each do a dlopen
-> dlsym -> ... -> EVP_cleanup -> dlclose sequence then it
seems that they will trample on each other.  If they take the extreme
opposite and don't call EVP_cleanup then the process will leak until it
falls over.


 

This is a serious issue that I believe impacts
the stability and therefore limits the usefulness of OpenSSL in large enterprise
applications.  Does anyone else have any thoughts on this?


 

Regards,

 

Steven

 


--=_alternative 003B475D4A257052_=--
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org