One method:
*openssl x509 -in "cert-name.pem" -noout -text -purpose | more
*substitute the name of your certificate for "cert-name.pem".
http://www.debian-administration.org/articles/284
On Fri, Apr 18, 2008 at 4:35 PM, Chuck Aaron <[EMAIL PROTECTED]>
wrote:
> What is the command please to view
> 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
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
> runtime.
> 2) Use the p
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
runtime.
2) Use the package manager available on the system to identify what
the b
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. Considering our user base, a
trojan is more likely to target our us
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
