On Wed, Oct 13, 2010 at 5:32 PM, Bill Durant <cipherte...@gmail.com> wrote:
That may not be sufficient, can ldfips be modified(?), it's certainly needed to link static to the fips canister. I'd put your energies into building a dylib which would give you a smidge more flexibility.
fipsld can be modified, as it is used after the module is created. It just expresses what has to happen in order for the FIPS-validated module to be considered valid (which basically involves creating a premain entry point and using it to check the loaded fipscanister's HMAC signature).
I don't know what ldfips will do. I will have to try it to see.
I think fipsld will do exactly what it's supposed to. I've not tried it for the last couple years though.
I think creating universal binaries with dylib will be more straight forward but I would prefer static libs instead in order to guarantee that my app will use the correct libcrypto lib (I am trying not to rely on the dynamic loader to determine which to use -- my lib or the system's lib).
Creating universal binaries with static linking is as straightforward as creating universal binaries with dynamic linking -- as you mentioned in another post in the thread, lipo(1) is your friend. And as for not relying on the dynamic linker, I approve. OpenSSL is known to have a bad interaction with OSX's dynamic loader, as documented in the PROBLEMS file. There's a workaround described therein, as well. OpenSSL-FIPS provides something that Apple does not -- a FIPS-validated cryptographic container. That alone is worth the headache to get it working right for a lot of people. -Kyle H
smime.p7s
Description: S/MIME Cryptographic Signature
