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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org