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 > >> 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. >
Indeed - original poster presented an interesting problem. Some requirements are in direct conflict with an "assured chain of authenticity" It seems that person will have to brief their legal department - then decide what compromises will have to be made to get executable code out of the door. Mike > -Steve M. > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
