[17282] in Kerberos_V5_Development
Re: NSS for PKINIT, in-progress patches available, feedback sought
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Oct 10 18:33:36 2011
Message-ID: <4E9372BB.2080601@mit.edu>
Date: Mon, 10 Oct 2011 18:33:31 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: Nalin Dahyabhai <nalin@redhat.com>
In-Reply-To: <20111010213404.GA29670@redhat.com>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 10/10/2011 05:34 PM, Nalin Dahyabhai wrote:
> Hmm, I should have remembered and noted that. It's being tracked
> upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=402712, but
> it's taking a while.
I see that there was some initial resistance, but there's motivation
from a few parties to get this in. So eventually this should resolve,
hopefully.
> The Fedora packaging puts the module in $libdir along with the soft
> token (libsoftokn3) and the built-in roots (libnssckbi), so I'd expect
> (well, hope for, more like) libnsspem to land there as well.
I'm actually not sure where SECMOD_LoadUserModule looks for relative
paths. If it looks in the NSS library directory than there's no
problem. If it only looks at the runtime linker path ($LD_LIBRARY_PATH
or /usr/lib) then that's unfortunate if NSS and krb5 are built into
non-default locations. This is not a problem for OS distributors, of
course.
>> 4. The name libnsspem.so is ELF-specific.
>
> I've added an attempt at guessing [...]
I think you want to call PR_GetLibraryName(NULL, "nsspem") to get the
appropriate module spec string.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
