User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20141011015303 Steps to reproduce: Load and initialize FF NSS native library and try to access FF certificates. This only apply to FF 33 on windows distro. On MacOSX FF 33 works as expected. On Linux (tested only in ubuntu 14) works with system NSS, not yet tested with FF 33 NSS. Actual results: Error looking up function 'SECMOD_UpdateSlotList' Error looking up function 'PK11_FindPrivateKeyFromCert' Error looking up function 'PK11_GetSlotFromPrivateKey'
Joaquin, it would be helpful to know what your goal here is. Is this for a 3rd party app that is separate from Firefox and just uses the libraries that comes with it? Or is this an applet/addon/etc. that runs in Firefox? Also, I gather it needs access to an NSS certificate database. Does this database need to be the one in the user's profile?
Hi David: The application is a java applet (to be platform independant), completly separate from firefox (can run on IE, Chrome/Chromium, Safari and Opera on any operating system, without any privilege and any instalation process, just download and deploy it and run; of course java, and java plugin are needed). The applet is deployed (write applet tag in html DOM) via jquery plugin, forcing to start the java plugin in a separate process (don't need dom.ipc.plugins.java.enabled=true). Both, applet and jquery plugin is the client part of a more complex product. The applet provides capabilities for crypto operations, basically sign, encrypt and ssl support via navigator crypto store. On Windows, MSCAPI for IE, Opera and Chrome and NSS for Firefox; on Linux, NSS or FF NSS for Firefox and NSS Shared DB for Chrome/Chromium; on MacOSX, NSS for Firefox and Keychain for Safari. About Firefox (in all platforms), the applet only opens FF NSS DB in read only mode (NSS_Init and currently working to use NSS_Init_Context instead). This FF DB is the current profile of the user (or last opened profile: Default=1 in profiles.ini). And of course, the applet cannot add, remove or delete any entry in NSS DB. For example, for signing purposes, from CMS to CAdES, from XMLDSIG to XAdES, and of course from PDFSignature to PAdES, including XMLDSIG/XAdES with binary content and more complex operations like counter-signature or co-signature. In any of the process described, the applet only need to select a FF NSS certificate, and then invoke the SGN_Begin, SGN_Update and SGN_End functions via SGNContext using the NSSPrivateKey corresponding to the first step, and in some cases repeating the process with different algorithms (CAdES or XAdES for example needs additonal signatures). The applet also needs to be able to reload certificates once started (I reported a bug to JSS, NSS java port, years ago: bug 313985), but SECMOD_UpdateSlotList is removed from FF 33 distro and I don't want to use WaitForAnyTokenEvent function. As I said, some removed functions can be rewritten and others not. Because Tom's comments (FF NSS should be private), I started looking an alternative using PKCS11, but this requires the user using the applet having administration privileges, so this is not suitable, and of course, expecting required functions wasn't removed from NSS distro.
We have similar features as stated in upper comment. Found out that some exported functions are renamed. Have _Utils postfix, other are just removed. Also found out that those new functions are not in headers in latest gecko sdk. So it's hard to use headers for static linking to nss. removed: NSS_Get_sgn_DigestInfoTemplate PK11_Verify renamed in %func_name%_Utils: SGN_CreateDigestInfo SGN_DestroyDigestInfo So far I found this could be the reason. https://blog.mozilla.org/addons/2014/10/01/compatibility-for-firefox-33/ https://bugzilla.mozilla.org/show_bug.cgi?id=1025998 We fixed to port some code from nss to our code and use dynamic library loading, checking if function exist and use new one if not. The best way to found out what is missing if you are using static linking is to use Dependency Walker and nss3.dll should be from ff33 folder.
> We fixed to port some code from nss to our code and > use dynamic library loading, > checking if function exist and use new one if not. If each release changes exported functions, good luck ;). As I said, sometimes "use new one if not" is possible others not: try to implement SECMOD_UpdateSlotList...
I totally agree. Just stated how we fix ff33 mess. If this kind changes goes on, we will not be able to use firefox cert store for signing documents. Hope that there will be new api if existing will be dropped.
Read from bug 1025998 comment 29 to the end I have NEVER requested a new api, NSS is perfect, including multiplatform isolation (only work with its types), but some people do not agree with my point of view.
Confirmed, FF libnss3.so also exports SECMOD_UpdateSlotList, PK11_FindPrivateKeyFromCert and PK11_GetSlotFromPrivateKey (ubuntu 14). David, I just need a way to access firefox certificates and make some crypto operations, just why not NSS (perfect for these operations)?. As Dragoslav said, FF wouldn't be usable for these purposes. I DONT want another API, I don't need it (FF people want to build a new one? I think NO). When working with the public administration, there are many procedures that need to be submitted electronically also require electronic signature. What a user wants is that when using the browser, the certificate that signs the process is that installed in its browser. The solution has to be designed in what the customer expects and not what the developer thinks is the best solution. If Firefox does not allow access to their certificates or perform signing and encryption operations with them, then what solution can give ?. I do not want to repeat again and again, it is not what I want, it's what users expect, and comments such as Tom, what we get is that users can not do what they need to do. If you do not believe me, check out these blogs (spanish), there are more: 1. Why do I have to be a computer engineer to perform procedures through the internet with the AEAT (Spanish tax agency): http://bartolomeborrego.blogcanalprofesional.es/%C2%BFpor-que-tengo-que-ser-ingeniero-informatico-para-poder-realizar-tramites-a-traves-de-internet-con-la-aeat/ 2. Came the nightmare of every year: http://www.forosuse.org/forosuse/showthread.php?t=29670 3. Sick of the websites of the Administration http://www.kriptopolis.com/node/504
We use nss api our e-banking solutions for signing payments and contracts. In Slovenia digital signature is legally equal person's handwritten signature.
(In reply to Dragoslav Mlakar from comment #8) > In Slovenia digital signature is legally equal person's handwritten > signature. Also in Spain, and in "general" all countries with a digital signature law
(In reply to Joaquin Sanchez Jimenez from comment #2) > The applet is deployed (write applet tag in html DOM) via jquery plugin, > forcing to start the java plugin in a separate process If that's the case, it may work best to distribute the appropriate NSS libraries along with your applet. That way, you know exactly what's available. > About Firefox (in all platforms), the applet only opens FF NSS DB in read > only mode (NSS_Init and currently working to use NSS_Init_Context instead). > This FF DB is the current profile of the user (or last opened profile: > Default=1 in profiles.ini). Just as an FYI, this might not be safe in general. For instance, if Firefox is modifying the DB at the same time that your applet is trying to read it, your applet could crash.
(In reply to David Keeler (:keeler) [use needinfo?] from comment #10) > (In reply to Joaquin Sanchez Jimenez from comment #2) > > The applet is deployed (write applet tag in html DOM) via jquery plugin, > > forcing to start the java plugin in a separate process > > If that's the case, it may work best to distribute the appropriate NSS > libraries along with your applet. That way, you know exactly what's > available. This is not true. If the applet loads its own version of NSS, this may be a problem if the FF NSS is not compatible. Of course, if FF NSS has changed the problem arises in both cases. > > About Firefox (in all platforms), the applet only opens FF NSS DB in read > > only mode (NSS_Init and currently working to use NSS_Init_Context instead). > > This FF DB is the current profile of the user (or last opened profile: > > Default=1 in profiles.ini). > > Just as an FYI, this might not be safe in general. For instance, if Firefox > is modifying the DB at the same time that your applet is trying to read it, > your applet could crash. In my case, it is not possible. If user opens FF certstore, there is no way to get focus on html page and the applet cannot be showed or loaded; if my applet is visible, it is modal, so the user cannot open FF certstore. If FF NSS DB is kept opened, there is no way my applet and FF access to certstore at the same time and viceversa. My applet leaves open FF NSS DB and closes on html page unload event. I have tested that FF and my applet working correctly.
So in 34 you can already use certificate from store to sign stuff or not? Is there any example to have a quick start?
Thank you for your explanation and points where to look for more info. This is very promising. Just one question more if I may. Is there any roadmap with milestones for this feature? Accessing already stored private keys. We are making some decisions about changing our existing digital signature product and any info would be very helpful.
On beta channel version 38 (20150409) this is again broken? NSS api is changed again? Is there and valuable blogs, notes what is going on?
(In reply to Dragoslav Mlakar from comment #17) > On beta channel version 38 (20150409) this is again broken? NSS api is > changed again? > Is there and valuable blogs, notes what is going on? On some platforms, to trim unused code, NSS functions not used by Firefox itself are not available. As mentioned in comment 4, it's probably a better idea to include a proper version of standalone NSS.
(In reply to :Cykesiopka from comment #18) > (In reply to Dragoslav Mlakar from comment #17) > > On beta channel version 38 (20150409) this is again broken? NSS api is > > changed again? > > Is there and valuable blogs, notes what is going on? > > On some platforms, to trim unused code, NSS functions not used by Firefox > itself are not available. As mentioned in comment 4, it's probably a better > idea to include a proper version of standalone NSS. I forgot to mention that it isn't really communicated anywhere because the NSS libs included with Firefox are treated more as internal implementation details.
As far as I can tell, the two mainstream certificate database formats used by NSS and Firefox have been stable. So there probably won't be an compat issues with using standalone NSS.
Anyways, thanks all for filing the bug and taking the time to comment and answer questions. It looks like at this point, the use cases being asked here are not something we really want to support, or can be done via other means.