Closed Bug 273406 Opened 18 years ago Closed 18 years ago
signed xpi plugin installer gets "Signing could not be verified" error
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 The XPI file referenced in the URL field above is a signed plugin installer. On on NS6, NS7, Moz 1.5, 1.6 or 1.73 it says the signing is valid and installs properly. On FF 1.0 it says "signing could not be verified". If the file is not signed, it does install. We want to distribute signed xpi only. Please fix Firefox so that it recognizes our signature just like Netscape and Mozilla do. Reproducible: Always Steps to Reproduce: 1. Download http://www.swiftview.com/product/sv_710/svinstall_p.xpi to your desktop. 2. Drag and drop the file onto NS6, NS7, Moz 1.5, 1.6 or 1.73 if you're skeptical about it being a valid, signed, plugin installer. 3. Drag and drop the file onto FF 1.0. Actual Results: Step 2 results in installation. Step 3 results in the message Firefox could not download the file at C:\Documents and Settings\steves\Desktop because: Signing could not be verified." There is then no option to install it. Expected Results: It should have verified the signature just as netscape and mozilla did and executed the installer. I chose 'major' as severity because if FF wants to gain acceptance in the business world, full support for plugins is necessary. Part of support is signing... you can't expect end users to install unsigned plugins on a regular basis. Note: if you do succeed in installing the plugin, you will notice that it doesn't do anything! That's because version 7.1.0 of our product was made for Moz and isn't FF aware yet. To manually install, if you want to see it work, you need to install it on one of the other browsers it does work on (ns 6-7, moz 1.5-1.7) and copy the npsview.dll into the Firefox/plugins folder. The eng version of SwiftView already has this fixed. We're committed to supporting Firefox, hope you guys can return the love!
Doug, I verified (with signtool 3.10) that the signature on the XPI file cited above is valid. Any idea why FF 1.0 doesn't like it?
As promised, our new installer for 7.1.1 supports firefox, I just put it up today. Get it here: http://www.swiftview.com/product/sv_711/svinstall_p.xpi instead of the above-mentioned http://www.swiftview.com/product/sv_710/svinstall_p.xpi if you want to see it actually install.
are the roots the same in ff and the nssckbi.dll that you are using with signtool? Also, I am using FF 1.0 and the xpi appears to be signed in the confirmation dialog.
(In reply to comment #3) > are the roots the same in ff and the nssckbi.dll that you are using with signtool? > It shouldn't matter how I signed it. The signing works perfecly in Netscape 6, 7, and Mozilla, but fails in Firefox, so Firefox has somehow gotten less tolerant. I run signtool under Linux anyway, so no dll involved. > Also, I am using FF 1.0 and the xpi appears to be signed in the confirmation dialog. Yes it does, but you need to go a little farther to get the error... from the confirmation window, click the Install Now button, and you will see the "signing could not be verified" error. You don't need to be hesitant to install SwiftView. We've been around since 1987 and we uninstall from Firefox just fine via the Windows control panel.
Assignee: firefox → dveditz
Target Milestone: --- → Firefox1.1
Steve, my comments were to nelson and I am sure he understood what I was talking about regardless of the name I used for the "dll extension". Here are two guesses at the cause: (a) the roots are different between the FF11 browser and the others that work -- where did you get your signing cert?, or (b) there is some download manager bug that caused this problem. Dan, are you looking at this or should I poke it some?
Assignee: dveditz → firefox
Sure, Doug, poke away :-). You know the signing stuff better than I do. Note bug 276006 implies that signed installs *do* work in Firefox (http://www.j-maxx.net/abtrans/abextension.php given as an example). This still might be specific to this install somehow. Or some magic Firefox trick that abtrans happened to stumble on. [for those unable to see 276006 the details are unimportant here, just notes a trunk flaw we need to fix]
Assignee: firefox → dveditz
Doug, the cited XPI is signed with a cert that chains to a Thawte root that is present in old and new nssckbi's.
(In reply to comment #7) > Doug, the cited XPI is signed with a cert that chains to a Thawte root > that is present in old and new nssckbi's. SwiftView has a newly issued Thawte certificate. It is from Thawte Code Signing CA, and I did import the intermediate cert into IE and export it from IE so that I could use it in linux. A possibly important difference between Jeff Klawiter's signed XPI from http://www.j-maxx.net/abtrans/abextension.php and mine is that his is an extension, but mine is a plugin.
+ , try for 1.0.1
Flags: blocking-aviary1.0.1? → blocking-aviary1.0.1+
Dan or Doug, is this something you all think we can still get for 1.0.1? Do we know is it a widespread problem or not?
i unzipped your xpi, re-zipped it up, and it appears to work now. Don't have time to analyze the two zip files for deltas. I can mail it to someone that has a tad more time (i was going to attach it, but there is a restiction on the attachment size!!) It might be nice to know how you constructed your xpi.
(In reply to comment #11) > i unzipped your xpi, re-zipped it up, and it appears to work now. Don't have > time to analyze the two zip files for deltas. I can mail it to someone that has > a tad more time (i was going to attach it, but there is a restiction on the > attachment size!!) I can also confirm this. Maybe excluding directories ('-D' option of Info-zip) cause this problem. I successfully installed repackaged xpi with directories, and xpi without directories failed.
The problem is that when Ben added the extension manager stuff he copied a bunch of the original code, and the result is that if the install is *not* the new style (which is checked for first) then the code calls Init() on the Jar twice and verifies the signatures twice. The first time it passes, but after the second init() the file list contains two entries for each actual content file. The manifest total is still correct, however, and when they don't match the signing fails because it thinks someone is slipping extra unsigned files into the archive. nsJar should never be initialized twice. In addition to this problem it leaks minor stuff like the PR_Lock and prossibly leaves the file open for reading. There should be code in nsJAR to prevent this, or at least assert.
Whiteboard: [sg:fix] → [sg:fix] need review
Comment on attachment 174077 [details] [diff] [review] Only verify signing once for old style install scripts r=dougt. Please run these changes through the test cases here: http://www.mozilla.org/projects/xpinstall/signed/testcases/
Comment on attachment 174077 [details] [diff] [review] Only verify signing once for old style install scripts setting flags for doug's review.
Whiteboard: [sg:fix] need review → [sg:fix] need approval
Comment on attachment 174077 [details] [diff] [review] Only verify signing once for old style install scripts a=chofmann for 1.0.1
Attachment #174077 - Flags: approval-aviary1.0.1? → approval-aviary1.0.1+
Whiteboard: [sg:fix] need approval → [sg:fix] need checkin
fix checked in to the aviary branch
Fixed on trunk
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Regarding comment 13: Added note in bug 214672 to also fix the double entries after re-initialisation of an existing JAR object. Generally the currently libjar doesn't really like re-init or init after close and things like that.
Verified fixed with Aviary 1.0.1 branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20050218 Firefox/1.0 With DougT's cert, all of the testcases at http://www.mozilla.org/projects/xpinstall/signed/testcases/ pass and I am also able to successfully install the SwiftView plugin found at http://www.swiftview.com/product/sv_711/svinstall_p.xpi
Status: RESOLVED → VERIFIED
also looks good with 2005021806-1.0.1 Mac firefox bits.
*** Bug 284814 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.