(Not sure yet if this is the right component, just guessing at this point; will grab builds and find a regression range tomorrow) On trunk XULRunner, the Builtin Roots Module (nssckbi.dll) is not correctly loaded. It attempts to load it from the app dir (instead of the GRE dir where it actually exists). Somehow despite it not existing it still manages to show up in the Manage Security Devices dialog, but with no children (Builtin Object Token doesn't show up). This means none of the root certs are loaded. Steps to reproduce: 1) Grab a trunk build of XULRunner ( http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/latest-trunk/ ) 2) Grab mfinkle's webrunner ( http://www.starkravingfinkle.org/blog/wp-content/uploads/2007/03/webrunner-src-0.2.zip ) 3) Unzip 1) and 2) of course 4) Attempt to open a HTTPS site C:\Path\to\XULRunner\xulrunner.exe C:\Path\to\webrunner\application.ini -uri https://www.microsoft.com/ Expected results: page loads Actual results: Unknown authority dialog
Works in: 2006-12-05-10-trunk Broken in: 2006-12-06-10-trunk This may be related to bug 362980 (which is itself fallout from bug 176501). I don't currently have a debug build handy, will find one later.
This surprises me, do you still get this bug? While you are right, in bug 176501 we changed the search order for nssckbi. The application directory will get searched first. But if the lib isn't found there, we'll go on and search for it in GRE dir.
I'm able to reproduce this bug. I used a slightly different approach and I used Linux. I installed Benjamin Smedberg's minimal "mybrowser" xulrunner application. Reference for me: - download and extract xulrunner - cd xulrunner - mkdir mb - cd mb - unzip mybrowser.xulapp - ../xulapp application.ini Using "strace -f" I see the following calls: [pid 8632] open("/home/kaie/.mozillatest/mybrowser/wlg2gfig.default/libnssckbi.so", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 8632] open("/tmp/xulrunner/mb/libnssckbi.so", O_RDONLY) = -1 ENOENT (No such file or directory) The first line is the application process dir. It appears xulrunner created a profile directory for that application and uses that for as the process directory. Not very helpful, I had hoped the process directory to be the directory where xulrunner-bin residers! The second line is probably from our attempt to load in the GRE directory. This is again confusing, why is the current directory, the directory where I started the application? Shouldn't GRE dir be the directory where xulrunner resides? Finally, it confuses me that there is no third attempt to load nssckbi! The code added in bug 176501 should be causing us to make such a third attempt.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I was able to reproduce this bug. We actually didn't end up trying the GRE dir at all, the search always stopped after searching current-process-dir :-/ This will be fixed with a new patch to bug 176501.
Status: NEW → ASSIGNED
I checked in another fix for bug 176501. Please retry this bug using tomorrow's nightly build. (My check in might have been too late to get picked up by today's builds).
Fixed in xulrunner-1.9a6pre.en-US.linux-i686.tar.bz2 28-Jun-2007 08:26 8.4M (The Windows nightly didn't get built, so tested the Linux one instead) Thanks!
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.