NSS for PKINIT, in-progress patches available, feedback sought

[Greg Hudson]

I'm about to commit this.

I'm seeing an apparent regression in the crypto-after-fork situation
(which I don't think has anything to do with the PKINIT support).  The
symptom is that t_workers.py fails with the child workers failing to
start.  The control flow is:

* k5_nss_init() detects the fork and calls SECMOD_RestartModules
* NSC_Finalize() is invoked and succeeds
* secmod_ModuleInit() is invoked and succeeds
* PK11_InitToken() is invoked for the module's first slot (of 3)
* NSC_GetTokenInfo() is invoked to get info for the slot
* sftk_SlotFromID() is invoked
* nscSlotHashTable[0] is NULL, so sftk_SlotFromID() returns NULL
* Errors are returned down the chain until SECMOD_RestartModules()
returns a failure

I think this problem is internal to NSS, so I'm going to leave it up to
you guys to figure out where the mistake is if this manifests on Fedora.
 I'll attach a backtrace from where the error originates.

> That's fine by me; I'm not sure how dependencies on other out-of-tree
> libraries are handled elsewhere in the package -- libk5crypto has to
> have this problem when it's built with something other than built-in
> crypto, and I guess the kdb_ldap driver does, too.

krb5 dependencies are generally linked in, not dynamically loaded at
runtime.  If you want to link libk5crypto with an NSS installation
outside of /usr/lib, you set the appropriate linker flags to add a
DT_RPATH or DT_RUNPATH to libk5crypto so the linker can find the
dependent libraries at load time.

NSS appears to be unusual in that it has dynamically loaded modules but
no apparent framework for locating them.  Relying on dlopen() to find
modules in the place where NSS libraries are installed seems to work on
some platforms, but hardly seems reliable.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: backtrace.txt
Url: http://mailman.mit.edu/pipermail/krbdev/attachments/20111013/c2abd5f8/attachment.txt