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 runtime. 2) Use the package manager available on the system to >> identify what the best "system" version of openssl is, in >> conjunction with number 1. 3) Do not use openssl, instead use >> libnss (from Mozilla) or tinyssl (which is small enough to >> statically link) or one of the other SSL libraries out there. > > Static linkage is the only practical approach to this threat model -
This issue takes yet another turn when government regulation is taken into account. The "mindset" of FIPS 140-2 validation (U.S. and Canada) is biased against static linking; most validated crypto libraries are shared libraries although static linking is possible. On the flip side, export regulations (U.S.) can heavily favor static linking over dynamic due to a requirement that shared calls be obfuscated. Pity the poor the poor software vendor who wants to write technically sound and secure code that can be validated and exported. -Steve M. -- Steve Marquess Open Source Software institute [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
