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
* 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. C
> 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
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
> >> ldo
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
o protect them.
> >
> > What do the majority applications do on Unix if static linking with
> > openssl isn't suitable?
> >
> >
> > Thanks.
> >
> > Yvonne
> >
> >
> > -Original Message-
> > From: [EMAIL PROTE
ajority applications do on Unix if static linking with
> openssl isn't suitable?
>
>
> Thanks.
>
> Yvonne
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
>
> Sent: Friday, April 18, 200
nssl-users@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
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
> 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
.
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 w
> 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
I have an application that is dynamically linked with openssl. I'd like
to load system installed openssl at runtime.
My application can only be as secure as the openssl loaded into the
process. What steps should I take to ensure my application doesn't load
a compromised openssl library that happe
13 matches
Mail list logo
