From: Darren Reed <[EMAIL PROTECTED]>
darrenr> > darrenr> support debugging. For example, I was trying out the pkcs12 -chain
darrenr> > darrenr> option, only to find it was insisting on using a certificate from
darrenr> > darrenr> /usr/local/ssl/certs/cert.pem as well as another file which I did
darrenr> > darrenr> not recognise. It turns out that this filename is actually a hash.
darrenr>
darrenr> openssl pkcs12 -export -chain -in newcert.pem -inkey newreq.pem
darrenr> -out new.p12
OK, I see what you mean. What is happening is that get_cert_chain()
in apps/pkcs12.c does a "verification" of the cert against an empty
certificate store. However, it does call X509_STORE_set_default_paths(),
which fills in the defaults you see. From what I can see, this is
unconditional.
Personally, I've no problem with those defaults as they are, and the
X509_get_default_*() functions are designed to give the library-
specific defaults. What I do have a problem with is the way
get_cert_chain() in pkcs12.c is designed, as it takes no external
input whatsoever except for the cert to be exported.
Steve, since you've made this thingy, perhaps you can tell us the
reason for the current design, if there is any?
darrenr> There are *many* instances of libraries using environment
darrenr> variables for direction. For example, under X windows, the
darrenr> first which comes to mind is XAPPLRESDIR, or in libc, TMPDIR,
darrenr> LD_PRELOAD, LD_LIBRARY_PATH, etc. The BIND resolver library
darrenr> also has environment variables to control things.
Hmm, OK, you have a point. However, I'm still don't like it. For
example, LD_LIBRARY_PATH has been a problem since it allowed evil
crackers to change the behavior of suid-root programs (IIRC)...
--
Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]