For anyone who might have cared, it looks like this is a case of missing
some of the Firefox DLLs from my program's search path. It looks
(behavior-wise... haven't checked the code) like the OS/2-specific code
for the dynamic loader in SECMOD_AddNewModule is not checking its return
codes for failure to locate needed subsequent DLLs, and I get a GPF
instead of a more informative message about not being able to find the
needed module.
Once I copied all of the needed DLLs, my app now starts up every time,
regardless of whether or not Firefox is running.
Marty wrote:
Wan-Teh Chang wrote:
On Tue, Feb 9, 2010 at 12:16 AM, Marty <n...@comcast.martyamodeo> wrote:
I'm trying to use the NSS/NSPR DLLs from Firefox on OS/2 for another
application (libpurple, an instant messaging library). I'm linking
up with
them correctly (as far as I can tell), and initializing them in a
standard
way, but when I call SECMOD_AddNewModule, I get a GPF unless Firefox is
already running on the system. When I have Firefox running, everything
seems to work well and I can make SSL connections through NSS
successfully.
My app is GCC and GLIB-based. Is it possible that the CRTL within
the NSS
DLLs are not getting initialized correctly? Or is there some other
problem
in my initialization process? Here is the code snippet that starts
things
up:
static void
ssl_nss_init_nss(void)
{
char *lib;
PR_Init(PR_SYSTEM_THREAD, PR_PRIORITY_NORMAL, 1);
NSS_NoDB_Init(".");
lib = g_strdup("nssckbi.dll");
SECMOD_AddNewModule("Builtins", lib, 0, 0);
/* GPF right on the above line if Firefox isn't running. */
g_free(lib);
NSS_SetDomesticPolicy();
SSL_CipherPrefSetDefault(TLS_DHE_RSA_WITH_AES_256_CBC_SHA, 1);
SSL_CipherPrefSetDefault(TLS_DHE_DSS_WITH_AES_256_CBC_SHA, 1);
SSL_CipherPrefSetDefault(TLS_RSA_WITH_AES_256_CBC_SHA, 1);
SSL_CipherPrefSetDefault(TLS_DHE_DSS_WITH_RC4_128_SHA, 1);
SSL_CipherPrefSetDefault(TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 1);
SSL_CipherPrefSetDefault(TLS_DHE_DSS_WITH_AES_128_CBC_SHA, 1);
SSL_CipherPrefSetDefault(SSL_RSA_WITH_RC4_128_SHA, 1);
SSL_CipherPrefSetDefault(TLS_RSA_WITH_AES_128_CBC_SHA, 1);
SSL_CipherPrefSetDefault(SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, 1);
SSL_CipherPrefSetDefault(SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, 1);
SSL_CipherPrefSetDefault(SSL_DHE_RSA_WITH_DES_CBC_SHA, 1);
SSL_CipherPrefSetDefault(SSL_DHE_DSS_WITH_DES_CBC_SHA, 1);
_identity = PR_GetUniqueIdentity("Purple");
_nss_methods = PR_GetDefaultIOMethods();
}
Hi Marty,
dev-tech-crypto is the right mailing list for NSS questions.
I'm using the USENET server, but it looks like the mailing lists are
linked appropriately, so I'll send to the appropriate newsgroup, thanks.
In any case, your code looks correct to me.
When you initialize NSS with NSS_NoDB_Init(), secmod.db won't be created,
so the issue Walter Meinl mentioned should be irrelevant.
I suspected as much. Thanks for the confirmation.
Is your code running inside the Firefox process or as a separate process?
This is running in a completely separate process.
I'm sorry I may not be able to help much because I'm not familiar with
OS/2. For example, I don't know what "the CRTL within the NSS DLLs"
means.
OS/2 is a "DOSish"/Windows-like platform which has a fairly extensive
porting environment for Unix apps. (Actually OS/2 users prefer to think
that the good parts of Windows are OS/2-like.) ;-)
That quote above was just a random guess that the C runtime library
initialization within the DLL (shared library) may not be happening
correctly, but I don't have any evidence of this. All of the Firefox
DLLs on OS/2 seem to have per-process initialization and termination, so
this is probably not the issue. There is some other kind of data,
global to all processes which use these DLLs, that is being initialized
correctly by Firefox, but not by me.
--
[Reverse the parts of the e-mail address to reply.]
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
