297518 - Signed extensions are sometimes shown as unsigned when installed from a web page

Status: RESOLVED DUPLICATE of bug 306354

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[Robert Strong (they/them - no direct email)]

When installing a signed extension from a web page it is at times displayed as
unsigned. In nsXPInstallManager::OnCertAvailable aPrincipal is also null and
aStatus is NS_BINDING_ABORTED when this happens. To reproduce go to the supplied
url and start the install for link 1 or link 2 (link 3 seems to always work
possibly due to the cert being imported) without ever clicking install. Usually
the first time it displays and usually the second time it does not. I have also
seen it where the first time it would display, restart the browser, go back to
page, start the install again, and then it doesn't display.

http://exchangecode.com/signing/testsigned.html

Comment 1

[Jim Ginn]

I tested several times and could not reproduce with links 1 or 2.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050614
Firefox/1.0+

Comment 2

[Robert Strong (they/them - no direct email)]

I think I have a reliable way to reproduce. Click "link 1" two or more times
before the install dialog appears. After that it seems that at least some info
is pulled from the cache and I am no longer able to get it to display as signed.

Comment 3

[Peter van der Woude [:Peter6]]

(In reply to comment #2)
> I think I have a reliable way to reproduce. Click "link 1" two or more times
> before the install dialog appears. After that it seems that at least some info
> is pulled from the cache and I am no longer able to get it to display as signed.

WFM

i am unable to reproduce this

Comment 4

[Robert Strong (they/them - no direct email)]

In testing this the cert info that is extracted by the zipreader appears to get
cached so once you have successfully read it once this bug is difficult to
reproduce. The other side of this is once you have reproduced this bug it is
difficult to get it to show that the extension is signed again. I have found
that restarting after viewing successfully that it is signed will usually do the
trick. Also, with a connection about twice the bandwidth of a standard modem it
is pretty easy for me to reproduce... with a broadband connection it is much
more difficult.

Comment 5

[Levi Wolfe]

I was able to reproduce this using my own extension as well as Robert's page. 
It seems to happen maybe 1 in 10 times for his first two linkes (didn't try the
third).  I don't know if its important, but I NEVER installed them.

I reproduced this on Deer Park Alpha 1:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531
Firefox/1.0+

A coworker repro'ed on FF 1.0.4:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
Firefox/1.0.4

Comment 6

[Robert Relyea]

When I first went to this page under the with deer park under the debugger the
'installtrigger' links did not show that they were signed. Before testing them I
set break points in the certificate verify functions in NSS. The functions were
not called. When I click on the 'link' links, then both the installtrigger and
the links showed up as signed and the NSS verify functions were called on each
click. Now, after restarting I can't get either to fail. I never did do an
'install' (always cancel).

This lends some credence to the theory that something is being cached/miscached
in the javascript security layer (though it could be a problem in the jar
parsing code as well).

bob

Comment 7

[Robert Strong (they/them - no direct email)]

I suspect the patch that just landed on the trunk for bug 306354 may fix this...
the comments in that bug state NS_BINDING_ABORTED is returned when this happens
which is the same as my initial findings.

Comment 8

[Robert Strong (they/them - no direct email)]

Using a build just prior to the patch from bug 306354 landing I was able to
reproduce this pretty easily. Using a build from after the patch landed I was no
longer able to reproduce this. Could someone else that has reproduced this
confirm using a trunk build from today? Thanks.

Comment 9

[Stebs]

Heh, I KNEW that there once was a similar bug that was dicussed in Mozillazine
some time ago (was able to reproduce it then), when I read today about the fixed
Bug 306354. Searched a while and found this.

Can confirm that with Trunk Nightly 200508107 this is fixed.
This Bug definitely looks to be a duplicate of Bug 306354 -or the other way round ;)

Comment 10

[Robert Strong (they/them - no direct email)]

Thanks for the confirmation!

*** This bug has been marked as a duplicate of 306354 ***