439
edits
Changes
→Issues to be resolved
= Issues to be resolved =
# 32-bit vs 64-bit packages: Do 32-bit and 64-bit packages both want to use the same directories, ~/.pki/nssdb and /etc/pki/nssdb, or do we want to have 64-bit versions of those directories, such as ~/.pki64/nssdb and /etc/pki64/nssdb or ~/.pki/nssdb64 and /etc/pki/nssdb64, or perhaps yet some other means? ## [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 #11
modules (particularly hardware modules) to a machine dependent directory, not
a user dependent directory. Implementing $ARCH above would also mitigate that
some 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.
** [ Correct, this does not address these issues, though it mitigates some of them. Primarily the issue of how do you deal with a library opening NSS with one set of directories while the app opens them with another. Under this scheme this will only happen with a few apps. We still have the problem that a library opens NSS, uses it, then unilaterally closes it. We could say 'don't close it if NSS isn't open but then you trip over the cause where the library opens NSS first, then the app opens NSS, then the library closes NSS while the app is still using it ]
* How does a library know if it is the first caller of NSS? Does it need to know?
** [ There is already a call to tell if NSS is already initialized. I don't think knowing that info, however, solves all the problems. The primary problem it doesn't solve is how to deal with shutdown. It probably solves the 97% case, which is bad because we may not trip over the 3% case until someone makes it a firedrill. ]
= Other comments =
* I don't see anything about this proposal that uniquely ties it to Linux. Seems to me that an improved Module DB Library would be useful on all platforms.
