> 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 point in preventing him from replacing system libraries. 2) The user may need to replace a system library for a given application for various reasons, including if the system library has a bug that other programs rely on. > I worry Trojan horses > hidden there. I am advised to zeroing-out this env variable before > loading openssl. I would not advise this. At least as likely as a trojan is that the system-installed one has a problem and the user has installed a fixed OpenSSL build. The trojan can just as easily intercept your programs file operations to redirect the attempt to link to the system-installed OpenSSL to be to a user-provided one. > What else I can do? Consider very carefully whether protecting the user from himself is worth preventing him from protecting himself. It's very hard to give you advice without having any understanding of what your threat model is. For example, if your program is designed to protect banking transactions, that's a very different threat model from if your program is designed to protect its own licensing. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
