Nelson B Bolyard wrote:
SECMOD_LoadUserModule() will load new modules without trying to add the module to secmod.db. SECMOD_OpenUserDB() will open new database slots in the internal database module.Howard Chu wrote, On 2008-08-11 20:07:Nelson B Bolyard wrote:I've been studying this some more; I still don't see a clean/backward-compatible solution for this situation:Howard Chu wrote, On 2008-08-10 14:13:It would make it impossible to use in e.g. OpenLDAP/nss_ldap because applications would be unable to load their own configuration settings after nss_ldap/libldap/nss initialized.Nothing prevents each application from having its own configuration. Nothing prevents an application from changing its configuration while it is running. Not even with cert8.db files.3rd party library "foo" calls NSS_Init("my path") and expects the DB files from "my path" to be used.Mozilla browser calls NSS_Init("profilepath") and expects the DB files from "profilepath" to be used.If the browser calls some other library that triggers foo, the DB in effect depends on which NSS_Init call came first. One or the other of these two pieces of software is going to break. There's no way for any software to detect that NSS_Init was called already,Except for calling this function: PRBool NSS_IsInitialized(void); Rest snipped, since it was based on the assumption that "there's no way". The next question to ask is: if a library finds out that NSS is already initialized, what function does it call to register additional modules that may use additional resources (potentially additional DBs)?
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
