Closed Bug 82259 Opened 22 years ago Closed 21 years ago
_Find External Root() tries to load library names that can never exist
The secmod_FindExternalRoot() function tries to load a whole bunch of library names, most of which don't exist. For example, on non-Windows platforms, the *dll names are bound to fail. While this is a simple way to get it to work on all platforms, it is inefficient. The 'dllnames' array should be made platform specific, so that we don't waste time loading library names that can never exist.
Proposed patch. Order the filenames, by platform, with #ifdefs so that only that platform's candidate filenames are compiled in. Then, within platform, order by most likely success of finding a rootcert. Wan-Teh, Terry, Nelson. Please review.
I wonder why the first row of the old names table was duplicated. This patch looks OK to me.
Larry, #pragma error is not portable. Use #error. Other than that, your patch is good. Remember to ask Relyea about the ordering of roots.dll, mozckbi.dll, and netckbi.dll.
Checked in parts. Bob Relyea! Is there some reason that dllnames contained duplicate lines? I deleted duplicates in the re-ordering.
Target Milestone: --- → 3.3
This seems like a fix that mozilla0.9.1 or mozilla0.9.2 should take because NSS is now loading 8-11 nonexistent library names on all platforms during NSS initialization.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Instead of adding: #else #pragma error,"Uh! Oh! I don't know about this platform." #endif the old way should have been used for unknown platforms. #else "roots.dll", "libroots.so","libroots.sl","Root Certs", "roots.dll", "libroots.so","libroots.sl","Root Certs", "nssckbi.dll","libnssckbi.so","libnssckbi.sl","NSS Builtin Root Certs", "mozckbi.dll","libmozckbi.so","libmozckbi.sl","Mozilla Builtin Root Certs", "netckbi.dll","libnetckbi.so","libnetckbi.sl","Netscape Builtin Root Certs", #endif That way platforms that aren't included in this list (like XP_OS2 and XP_BEOS) wouldn't be broken Incidentally, OS/2 can follow the WIN32 path in this case.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The OS/2 breakage has been fixed.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.