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

[Nalin Dahyabhai]

On Mon, Oct 10, 2011 at 06:33:31PM -0400, Greg Hudson wrote:
> I think you want to call PR_GetLibraryName(NULL, "nsspem") to get the
> appropriate module spec string.

Yup, I completely missed that NSPR already provided that.  Fixed.

On Tue, Oct 11, 2011 at 01:37:20PM -0400, Greg Hudson wrote:
> On 10/10/2011 06:33 PM, Greg Hudson wrote:
> > I'm actually not sure where SECMOD_LoadUserModule looks for relative
> > paths.
> 
> It appears to translate into a straight dlopen() call on Unix.  On
> Linux, dlopen() consults the rpath or runpath values in... something (I
> can't figure out what exactly, but in my tests it was checking an rpath
> value which either came from the pkinit module object or an NSS library,
> since none was set on krb5kdc or the nspr library).
> 
> Anyway, I assume this problem will go away if and when nsspem becomes a
> built-in module for NSS, so let's ignore this problem for now.

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.

> In a line-by-line review, I found just one more problem: don't use
> strcpy, strcat, or sprintf, even safely; use strlcpy, strlcat, or
> snprintf instead.  (k5-platform.h and libkrb5support ensure the
> availability of those functions.)
> http://k5wiki.kerberos.org/wiki/Coding_style/Practices#String_Handling

Sure thing.  There are a couple of places where we try to escape the
name of a module that we pass to SECMOD_LoadUserModule(), where building
the result up using a k5buf didn't seem like a clear win over the
current method, so I left them alone, but if that still looks
problematic I'll rework it.  The rest should be sorted.

Thanks,

Nalin