Bug#732201: Please add libnssdb.a and libnssckfw.a to libnss3-dev

[Timo Aaltonen]

On 15.01.2014 23:31, Mike Hommey wrote:
> AIUI, cryptoki is in nssckfw. Leaving aside the false sense of 
> security in static linking, that doesn't explain why nss internals 
> are needed. It sounds to me like they need some guts exposed, and 
> would need to talk to NSS upstream to expose them.

here are some comments from the Red Hat NSS devs:

On 15.01.2014 20:01, Robert Relyea wrote:
> On 01/15/2014 09:48 AM, Elio Maldonado wrote:
>> On 01/15/2014 09:38 AM, Robert Relyea wrote:
>>> The problem isn't dynamic linking, is what you are dynamically 
>>> linking to. You can't link to NSS proper because that would
>>> cause a circular dependency (NSS loads PKCS #11 modules to do
>>> it's crypto). Since modrevocator was first written, NSS has now
>>> split out nssutil out so
>> We did split nss-util out but I think you meant to type 
>> nss-pkcs11-devel?
> 
> No, I meant nss-util. The functions in libnssb.a are now in util 
> (though they may not be exported).
> 
>>> that PKCS #11 modules can link against it. This won't help 
>>> modrevocator, however, since it's linking against the cryptoki 
>>> framework, with is outside of NSS altogether.
>>> 
>>> BTW if debian could at all put these is a separate packages. 
>>> While PKCS #11 modules need them, regular applications should 
>>> *NOT* use them. That is why they aren't part of the regular 
>>> -devel package for NSS itself.


-- 
t