439
edits
Changes
→Issues to be resolved
#* [We are already dealing with this by path. The databases and config files stored in /etc/pki/nssdb are platform independent (data sizes and endianness prespecified). The only issue is the load modules. Currently we are specifying loadmodules with implicit paths and depending on the correct libpath to load them. We probably need something better like defining a arch specific path component (like $ARCH) which points to 32bit or 64bit directories as appropriate. Linux supposedly parses these in dlopen, but I haven't had any success. Perhaps including such code in pk11wrap before we load the module would be appropriate)]
# what about the case of an NFS-mounted home directory that is used from different machines on different OS platforms. Perhaps the path should also attempt to differentiate by architecture more broadly than just 32/64 bits, e.g. linux-x86-32, linux-x86-64, linux-S360, Linux-sparc-v8plus (32), Linux-sparc-v9 (64), Solaris-sparc-v9, etc., etc.
#* [ We are currently dealing with this by the fact that the wrong binary won't load on a foreign OS -- our solution we've been living with for over a decade.This proposal mitigates this quite a bit. It moves configuration of PKCS #11modules (particularly hardware modules) to a machine dependent directory, not a user dependent directory. Implementing $ARCH above would also mitigate thatsome provide a strong possible solution this issue as well. ]
# More work is still needed on the problems faced by libraries.
* How does a library call NSS initialization functions in a way that works well, whether it is the first caller of NSS_Initialize in the process, or is not the first caller.
