NSS for PKINIT, in-progress patches available, feedback sought
nalin at redhat.com
Wed Oct 12 17:52:10 EDT 2011
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.)
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.
More information about the krbdev