273406 - signed xpi plugin installer gets "Signing could not be verified" error

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Steve S]

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!

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

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?

Comment 2

[Steve Schmitt]

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.

Comment 3

[Doug Turner (:dougt)]

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.

Comment 4

[Steve Schmitt]

(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.

Comment 5

[Doug Turner (:dougt)]

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?

Comment 6

[Daniel Veditz [:dveditz]]

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]

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Doug, the cited XPI is signed with a cert that chains to a Thawte root 
that is present in old and new nssckbi's.  

Comment 8

[Steve Schmitt]

(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.

Comment 9

[chris hofmann]

+ , try for 1.0.1

Comment 10

[Asa Dotzler [:asa]]

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?

Comment 11

[Doug Turner (:dougt)]

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.

Comment 12

[Anbo Motohiko]

(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.

Comment 13

[Daniel Veditz [:dveditz]]

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.

Comment 14

[Daniel Veditz [:dveditz]]

Attachment: Only verify signing once for old style install scripts

Comment 15

[Doug Turner (:dougt)]

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 16

[Daniel Veditz [:dveditz]]

Comment on attachment 174077 [details] [diff] [review]
Only verify signing once for old style install scripts

setting flags for doug's review.

Comment 17

[chris hofmann]

Comment on attachment 174077 [details] [diff] [review]
Only verify signing once for old style install scripts

a=chofmann for 1.0.1

Comment 18

[Daniel Veditz [:dveditz]]

fix checked in to the aviary branch

Comment 19

[Daniel Veditz [:dveditz]]

Fixed on trunk

Comment 20

[Alfred Kayser]

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.

Comment 21

[Jay Patel [:jay]]

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

Comment 22

[sairuh (rarely reading bugmail)]

also looks good with 2005021806-1.0.1 Mac firefox bits.

Comment 23

[Benjamin Smedberg]

*** Bug 284814 has been marked as a duplicate of this bug. ***