* Li, Yvonne wrote on Fri, Apr 18, 2008 at 23:46 -0400:
You have lots of good points. Thank you again.
I work for AOL, developing cross platform SDK for instant messaging that
supports plugins. Plugins can be malicious. And AOL is responsible for
protecting users' identity and privacy.
Thank you all for your valuable inputs. I really appreciate your sharing
your thoughts with me and am digesting them.
Right now it looks the easiest for me is static linking + baking my
trusted root CAs into a single cert file + validating the file before
using it. I also need to figure out a way
The only thing I would state is that setuid programs, on most UNIXes,
ignore the LD_LIBRARY_PATH.
I would also note that LD_LIBRARY_PATH is NOT universal. On OSX,
DYLD_LIBRARY_PATH is the equivalent, but there's also other
environment variables which can do the same thing.
And this doesn't even
@openssl.org
Subject: RE: Openssl loading
Thanks for your response. Shipping my own version of openssl is ruled
out. So I have to trust the system installed one. Think at least on
some Unix systems, LD_LIBRARY_PATH is searched first.
Right, this is beause:
1) A library cannot do any harm
.
Yvonne
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: Friday, April 18, 2008 6:29 PM
To: openssl-users@openssl.org
Subject: RE: Openssl loading
Thanks for your response. Shipping my own version of openssl is ruled
@openssl.org
Subject: RE: Openssl loading
Thanks for your response. Shipping my own version of openssl is ruled
out. So I have to trust the system installed one. Think at least on
some Unix systems, LD_LIBRARY_PATH is searched first.
Right, this is beause:
1) A library cannot do
Michael S. Zick wrote:
On Sat April 19 2008 05:02, Kyle Hamilton wrote:
Ah. This is a bit of a quandary. But, there are a couple of
options for you.
1) Do not use ld to link to libcrypto or libssl. Instead, use the
ldopen() family of functions to open and bind those files yourself
at
On Sat April 19 2008 07:28, Steve Marquess wrote:
Michael S. Zick wrote:
On Sat April 19 2008 05:02, Kyle Hamilton wrote:
Ah. This is a bit of a quandary. But, there are a couple of
options for you.
1) Do not use ld to link to libcrypto or libssl. Instead, use the
ldopen() family of
You have lots of good points. Thank you again.
You're welcome.
I work for AOL, developing cross platform SDK for instant messaging that
supports plugins. Plugins can be malicious. And AOL is responsible for
protecting users' identity and privacy. Considering our user base, a
trojan is more
I have an application that is dynamically linked with openssl.
I'd like to load system installed openssl at runtime.
1) I'd like to use the system installed openssl rather than one I know is
secure.
My application can only be as secure as the openssl loaded into
the process. What steps
.
What else I can do?
Thanks.
Yvonne
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: Friday, April 18, 2008 4:53 PM
To: openssl-users@openssl.org
Subject: RE: Openssl loading
I have an application that is dynamically linked
Thanks for your response. Shipping my own version of openssl is ruled
out. So I have to trust the system installed one. Think at least on some
Unix systems, LD_LIBRARY_PATH is searched first.
Right, this is beause:
1) A library cannot do any harm the user could not do directly. So there's
no
12 matches
Mail list logo