This is a multi-part message in MIME format.

------=_NextPart_000_00A5_01C5987A.718D12B0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Peter,

There is a requirement in my case for the OpenSSL API to be accessible to
several components. In your case was your higher level component the only
direct user of OpenSSL? If not, how did you make the API available to other
components? Were the new functions accessed from one DLL with the OpenSSL
functions accessed directly from the other DLL, or did you have redirecting
stubs in your new DLL?

Steven

_____

From: owner-openssl-dev@openssl.org [mailtowner-openssl-dev@openssl.org]
On Behalf Of Peter Waltenberg
Sent: Wednesday, 3 August 2005 8:48 PM
To: openssl-dev@openssl.org
Cc: smr@essemer.com.au
Subject: Re: Safety of using OpenSSL from multiple components in the one
process



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



------=_NextPart_000_00A5_01C5987A.718D12B0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



charset=3Dus-ascii">


face=3DArial=20
color=3D#0000ff size=3D2>Hi Peter,

face=3DArial=20
color=3D#0000ff size=3D2>
 

face=3DArial=20
color=3D#0000ff size=3D2>There is a requirement in my case for the =
OpenSSL API to be=20
accessible to several components.  In your case was your higher =
level=20
component the only direct user of OpenSSL?  If not, how did you =
make the=20
API available to other components?  Were the new functions accessed =
from=20
one DLL with the OpenSSL functions accessed directly from the other DLL, =
or did=20
you have redirecting stubs in your new DLL?

face=3DArial=20
color=3D#0000ff size=3D2>
 

face=3DArial=20
color=3D#0000ff size=3D2>Steven





From: owner-openssl-dev@openssl.org=20
[mailtowner-openssl-dev@openssl.org] On Behalf Of Peter=20
Waltenberg
Sent: Wednesday, 3 August 2005 8:48 =
PM
To:=20
openssl-dev@openssl.org
Cc: =
smr@essemer.com.au
Subject: Re:=20
Safety of using OpenSSL from multiple components in the one=20
process



You are correct it is a =
problem in=20
enterprise applications.  

size=3D2>The good=20
news is that it can be resolved, the bad news is that we did that =
outside the=20
OpenSSL codebase itself.


size=3D2>We created=20
new startup/shutdown functions in another library, added reference =
counting and=20
load OpenSSL via that.

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


Peter =


face=3Dsans-serif size=3D2>Peter Waltenberg







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

size=3D1>Sent by: owner-openssl-dev@openssl.org=20

03/08/2005 06:42 PM=20





Please =
respond=20
to
openssl-dev









size=3D1>To

size=3D1><openssl-dev@openssl.org>=20

size=3D1>cc



size=3D1>Subject

Safety of =
using OpenSSL=20
from multiple components in the one=20
process






=




face=3DArial=20
size=3D2>Hi All,

 
face=3DArial=20
size=3D2>This is something that I think I've raised before but don't =
remember=20
getting resolution on.

 

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

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

 

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

size=3D3> =20

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

size=3D3> 
Regards, =

size=3D3> 
Steven =

size=3D3> 


------=_NextPart_000_00A5_01C5987A.718D12B0--

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