Last Comment Bug 726125 - Certificate of a signed extension is validated on each startup
: Certificate of a signed extension is validated on each startup
Status: VERIFIED FIXED
[Snappy:P1]
: addon-compat, compat, dev-doc-needed
Product: Toolkit
Classification: Components
Component: Add-ons Manager (show other bugs)
: Trunk
: All All
: -- normal with 5 votes (vote)
: mozilla18
Assigned To: Nicolás Chaim
:
: Andy McKay [:andym]
Mentors:
: 753437 774949 (view as bug list)
Depends on:
Blocks: abp 719180 774949
  Show dependency treegraph
 
Reported: 2012-02-10 12:26 PST by Wladimir Palant
Modified: 2013-01-31 15:55 PST (History)
42 users (show)
dveditz: sec‑review+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
verified
verified


Attachments
List of signed add-ons (37.45 KB, text/plain)
2012-08-05 21:14 PDT, Blair McBride [:Unfocused] (UNAVAILABLE)
no flags Details
Proposed patch (4.65 KB, patch)
2012-08-09 11:37 PDT, Nicolás Chaim
no flags Details | Diff | Splinter Review
Proposed patch (4.65 KB, patch)
2012-08-09 12:37 PDT, Nicolás Chaim
taras.mozilla: review+
vladan.bugzilla: feedback+
brian: feedback+
trev.moz: feedback+
Details | Diff | Splinter Review
Proposed patch (4.79 KB, patch)
2012-08-10 10:50 PDT, Nicolás Chaim
bzbarsky: superreview+
akeybl: approval‑mozilla‑aurora+
akeybl: approval‑mozilla‑beta+
vladan.bugzilla: checkin+
Details | Diff | Splinter Review
New regression test (4.72 KB, patch)
2012-08-28 15:02 PDT, Vladan Djeric (:vladan)
bzbarsky: feedback+
Details | Diff | Splinter Review

Description Wladimir Palant 2012-02-10 12:26:28 PST
Steps to reproduce:

* Install Element Hiding Helper from https://addons.mozilla.org/addon/elemhidehelper/
* Restart your browser with Wireshark or a similar monitoring tool

Expected results:

All requests made at startup are related to restoring the session.

Actual results:

Firefox makes an OCSP request to ocsp.startssl.com on startup. Wireshark shows that it verifies the validity of certificate 02:40 - that's the certificate used to sign Element Hiding Helper. It is similar if Adblock Plus is installed but there the request is only made when the Add-ons Manager is opened (Element Hiding Helper is restartless while Adblock Plus isn't, this might be the important difference). Altogether this check seems pointless and from the source code it doesn't look like it is intended to happen.

Reproduced in Firefox 10 and a current mozilla-central nightly on Windows 7 x64.
Comment 1 Wladimir Palant 2012-02-10 12:33:37 PST
In case of Adblock Plus the check seems to be triggered by the icon displayed in the Add-ons Manager. If I change the hosts file to send ocsp.startssl.com connections to 1.2.3.4 (takes a while for the connection to fail) the icon doesn't show up for quite some time.
Comment 2 Dave Townsend [:mossop] 2012-02-10 14:43:07 PST
Huh, I didn't even know we supported doing ocsp lookups for XPI signing certs. I bet the jar: protocol handler is doing this somewhere, we use that to load bootstrap.js for restartless add-ons and the icon for non-restartless add-ons.
Comment 3 Wladimir Palant 2012-02-11 02:13:53 PST
That's what I suspected as well but Element Hiding Helper initializes without a delay, even while the OCSP request is ongoing - so the check isn't triggered by bootstrap.js.
Comment 4 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-02-13 02:01:23 PST
(In reply to Dave Townsend (:Mossop) from comment #2)
> I bet the jar: protocol handler is doing this somewhere

After a quick look at the spaghetti:

AFAICT, it happens during nsJARChannel::GetOwner(), which calls nsIZipReader::GetCertificatePrincipal(), which reads and parses the manifest.

And (AFAICT), nsDocShell calls nsIChannel::GetOwner() when a resource is loaded. The icon is a resource loaded by a docshell, while bootstrap.js isn't loaded by a docshell and therefore doesn't get that check.
Comment 5 Wladimir Palant 2012-07-11 05:31:52 PDT
A bunch of user reports recently complained about slow browser startup caused by Element Hiding Helper - around 10 seconds delay (a ridiculous amount given that the extension does almost nothing at startup). It seems that this was caused by ocsp.startssl.com being unreachable. When I tried mapping ocsp.startssl.com to 1.2.3.4 via hosts file I could reproduce the same slow browser startup. So this bug isn't a mere annoyance, it is also a serious startup performance issue.

Adblock Plus isn't affected because the current version is no longer signed (due to bug 765676), I guess that I will stop signing the other extensions as well.
Comment 6 Wladimir Palant 2012-07-11 13:30:56 PDT
For reference: the issue mentioned in comment 5 was apparently caused by a (still ongoing) DDoS attack on StartSSL infrastructure.
Comment 7 Justin Dolske [:Dolske] 2012-07-12 18:02:23 PDT
Would it be useful to spinoff a bug to add telemetry for measuring this (with the intention of getting it on aurora/beta quickly)? Taras noted on his blog that "I think we finally have a good explanation for some of the ridiculously slow startups we’ve been looking at", which makes me very much want to know exactly how much of the problem he just found! \o/
Comment 8 Nicholas Nethercote [:njn] 2012-07-12 20:19:13 PDT
(In reply to Wladimir Palant from comment #5)
> A bunch of user reports recently complained about slow browser startup
> caused by Element Hiding Helper - around 10 seconds delay (a ridiculous
> amount given that the extension does almost nothing at startup). It seems
> that this was caused by ocsp.startssl.com being unreachable. When I tried
> mapping ocsp.startssl.com to 1.2.3.4 via hosts file I could reproduce the
> same slow browser startup.

I'm trying to understand the sequencing here.  Does the entire start-up sequence block while trying to contact ocsp.startssl.com?  Does it then time out after 10 seconds?
Comment 9 Wladimir Palant 2012-07-12 23:59:48 PDT
(In reply to Nicholas Nethercote [:njn] from comment #8)
> I'm trying to understand the sequencing here.  Does the entire start-up
> sequence block while trying to contact ocsp.startssl.com?  Does it then time
> out after 10 seconds?

No, the start-up sequence completes just fine in my tests. Actually, I see the "load" event for the first browser window at the usual time - but it then takes 10 seconds for the window to show up. And the code causing the window to show up slowly is this:

> let style = window.document.createProcessingInstruction("xml-stylesheet", 'class="elemhidehelper-node" href="chrome://elemhidehelper/skin/overlay.css" type="text/css"');
> window.document.insertBefore(style, window.document.firstChild);

Element Hiding Helper inserting its stylesheet into the browser window apparently triggers the certificate check and the window cannot show up until the check times out.

Note that this is for some reason not reproducible with Element Hiding Helper only - I have to install another extension like User Agent Switcher as well.
Comment 10 (dormant account) 2012-07-17 16:32:25 PDT
This hurts most on startup, but seems like it also causes blocking networking IO on UI thread during extension install, etc. I think the solution here to make nsJARChannel not check the signature by default and instead provide a proper async API to do that for places that actually need to verify the signature(ie addon manager during install time?).

Blair would that work for you?
Comment 11 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-07-17 17:12:23 PDT
Yes, I think that will work rather nicely. It also works around some issues with re-packing without the signing info, and help keep the app responsive during install time (though I still have some work to do there).
Comment 12 Justin Dolske [:Dolske] 2012-07-17 20:36:59 PDT
Random thought: Thankfully signed addons are fairly rare. Umm, except for the hotfix addon that we shipped to Windows users (bug 741004). :-o [It's ok, it will have uninstalled itself for anyone able to upgrade past FF12.]
Comment 13 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-07-19 11:56:38 PDT
(In reply to Taras Glek (:taras) from comment #10)
> This hurts most on startup, but seems like it also causes blocking
> networking IO on UI thread during extension install, etc. I think the
> solution here to make nsJARChannel not check the signature by default and
> instead provide a proper async API to do that for places that actually need
> to verify the signature(ie addon manager during install time?).

It is better to check the signatures when loading the addon if there's any reasonable way to do so because the addons are code that is being loaded from an untrusted location (the user's profile).

The network I/O is caused by OCSP fetching. We need to start caching OCSP responses so we don't fetch them over the network every time. But, even then the performance might be unacceptable, and plus there's no ETA for that caching. A reasonable compromise would be to turn off the network OCSP fetching during the startup-time signature check so that we'd only do revocation checking at installation time. That would be better than completely disabling the signature validation.

Regardless, any certificate validation must be done off the main thread because certificate validation (and anything else that looks up certificates from the certificate store) does disk I/O.
Comment 14 Wladimir Palant 2012-07-19 14:30:37 PDT
(In reply to Brian Smith (:bsmith) from comment #13)
> It is better to check the signatures when loading the addon if there's any
> reasonable way to do so because the addons are code that is being loaded
> from an untrusted location (the user's profile).

That's not what is actually happening right now - there is no check for the add-on code, merely some unintended check for its styles with very limited consequences. Not that it matters because any malicious application manipulating user's profile can simply remove the signature. So the current check really serves no purpose.

Note that the same delay will likely happen for any new browser window opened, not just for the first browser window.
Comment 15 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-07-20 12:37:25 PDT
(In reply to Wladimir Palant from comment #14)
> Not that it matters because any malicious application
> manipulating user's profile can simply remove the signature. So the current
> check really serves no purpose.

I agree. I filed bug 776071 about the idea I mentioned above. I agree that, unless/until we decide to have a proper implementation of the idea in bug 776071, we should ensure that no hashing or signature verification is being done on XPIs after they've been installed.
Comment 16 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-07-22 18:48:45 PDT
(In reply to Justin Dolske [:Dolske] from comment #12)
> Random thought: Thankfully signed addons are fairly rare. Umm, except for
> the hotfix addon that we shipped to Windows users (bug 741004). :-o [It's
> ok, it will have uninstalled itself for anyone able to upgrade past FF12.]

AFAIK, all hot fixes are going to get signed. 

I wrote a little tool to search through addons-mxr for patterns, and gather stats on affected daily users (I'll blog about it when I get time). I found 518 signed addons, totaling 14,921,862 daily users (does not take into account users with multiple signed addons installed, or addons not on AMO).
Comment 17 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-07-22 18:55:41 PDT
(In reply to Brian Smith (:bsmith) from comment #13)
> It is better to check the signatures when loading the addon if there's any
> reasonable way to do so because the addons are code that is being loaded
> from an untrusted location (the user's profile).

Note that we already can't check all addons at startup time (addons that are unpacked).
Comment 18 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-07-22 19:18:53 PDT
(In reply to Blair McBride (:Unfocused) from comment #17)
> Note that we already can't check all addons at startup time (addons that are
> unpacked).

Yep. The many changes that would be needed to do what I suggested in comment #13 are best discussed in bug 776071 if that ever becomes a priority.
Comment 19 Dave Townsend [:mossop] 2012-07-22 19:49:37 PDT
(In reply to Blair McBride (:Unfocused) from comment #17)
> (In reply to Brian Smith (:bsmith) from comment #13)
> > It is better to check the signatures when loading the addon if there's any
> > reasonable way to do so because the addons are code that is being loaded
> > from an untrusted location (the user's profile).
> 
> Note that we already can't check all addons at startup time (addons that are
> unpacked).

Well, there is no code written to do it, there is nothing physically impossible about checking the signature of unpacked add-ons I think
Comment 20 Kshitij Chawla 2012-07-28 20:22:34 PDT
Can a list of such addons be published and made available?
Comment 21 Wladimir Palant 2012-07-30 17:10:25 PDT
*** Bug 753437 has been marked as a duplicate of this bug. ***
Comment 22 Nils Maier [:nmaier] 2012-07-31 06:33:32 PDT
(In reply to Taras Glek (:taras) from comment #10)
> This hurts most on startup, but seems like it also causes blocking
> networking IO on UI thread during extension install, etc. I think the
> solution here to make nsJARChannel not check the signature by default and
> instead provide a proper async API to do that for places that actually need
> to verify the signature(ie addon manager during install time?).

XPIProvider.jsm does not even use the nsJarChannel::GetOwner stuff at all during extension installation. Instead nsIZipReader.getCertificatePrincipal() is called directly and the corresponding certificate, if any, is verified.
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/XPIProvider.jsm#4505

Having the certificate checks in nsJARChannel::GetOwner is completely useless overhead, at least for local jars belonging to extensions... Are there any supported other local or remote users left that use this mechanism for privilege elevation? The Java signed-jar stuff within Gecko seems to be dead, as is the signed remote XUL/XBL stuff and netscape.security.PrivilegeManager.enablePrivilege API?!

I removed the code in nsJARChannel::GetOwner in a local build and there was no apparent functional difference. XPI signing still displays the author on installation, and signed XPIs with a signature mismatch (corrupt, tampered with) are still rejected.
Comment 23 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-08-05 21:14:15 PDT
Created attachment 649175 [details]
List of signed add-ons

(In reply to Kshitij Chawla from comment #20)
> Can a list of such addons be published and made available?

Here you go. Sorry for the delay, I had to find some free time to modify my code to output all this.
Comment 24 Nicolás Chaim 2012-08-06 09:07:04 PDT
I tried removing the code in nsJARChannel::GetOwner while working on related bug 774949, but this causes a problem validating script expanded privileges as described in bug 657267.

https://tbpl.mozilla.org/?tree=Try&rev=cd127106223f
Comment 25 Nicolás Chaim 2012-08-09 11:37:41 PDT
Created attachment 650629 [details] [diff] [review]
Proposed patch
Comment 26 Nicolás Chaim 2012-08-09 11:57:05 PDT
Comment on attachment 650629 [details] [diff] [review]
Proposed patch

Removing the code in nsJARChannel::GetOwner does seem to be a viable solution. Went ahead and removed the test for bug 657267, given that signed scripts are deprecated. The test was failing because the signed script was now being handled as unprivileged, and the other unprivileged context was able to access it without a permission error.
Comment 27 Vladan Djeric (:vladan) 2012-08-09 12:12:22 PDT
Comment on attachment 650629 [details] [diff] [review]
Proposed patch

>-ifneq ($(OS_TARGET),Android)
>-ifndef MOZ_PLATFORM_MAEMO
>-MOCHITEST_FILES +=	test_bug657267.html \
>-		bug657267.jar \
>-		test_bug564330.html \
>-		test_bug618017.html
>-endif
>-endif

Why did you remove all the tests? Afaict, only one is related to unsigned/signed script interaction
Comment 28 Nicolás Chaim 2012-08-09 12:37:37 PDT
Created attachment 650646 [details] [diff] [review]
Proposed patch
Comment 29 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-08-09 13:19:32 PDT
Comment on attachment 650646 [details] [diff] [review]
Proposed patch

feedback+ for the approach, not for the specifics of what the code does, though the patch does seem reasonable to me.

If we land this, then we need to update MDN to remove the documentation for signed scripts.
Comment 30 Nicolás Chaim 2012-08-09 13:35:18 PDT
*** Bug 774949 has been marked as a duplicate of this bug. ***
Comment 31 (dormant account) 2012-08-09 21:51:54 PDT
Comment on attachment 650646 [details] [diff] [review]
Proposed patch

This needs a comment explaining the empty GetOwner. Can just say
// bug 726125: avoid main-thread network io
Comment 32 Wladimir Palant 2012-08-09 23:09:21 PDT
Comment on attachment 650646 [details] [diff] [review]
Proposed patch

You might want to copy the GetOwner implementation from HttpBaseChannel - it is easier to read and will actually check whether aOwner is not null. But in general this approach is fine with me, it should solve all the issues.
Comment 33 Nicolás Chaim 2012-08-10 10:50:14 PDT
Created attachment 650944 [details] [diff] [review]
Proposed patch
Comment 34 Danial Horton 2012-08-10 11:11:46 PDT
can we get this on aurora?
maybe beta as well? (as unlikely as that is)
Comment 35 (dormant account) 2012-08-13 16:54:33 PDT
(In reply to Danial Horton from comment #34)
> can we get this on aurora?
> maybe beta as well? (as unlikely as that is)

This needs to land on mc before we can discuss uplift.
Comment 36 Blair McBride [:Unfocused] (UNAVAILABLE) 2012-08-13 18:32:23 PDT
I mentioned this to Taras on IRC already, but just to be clear: This approach sounds good to me.
Comment 37 Nicolás Chaim 2012-08-14 08:27:25 PDT
Does this need a sec-review before it can be checked in?
Comment 38 Daniel Veditz [:dveditz] 2012-08-16 18:23:47 PDT
Comment on attachment 650944 [details] [diff] [review]
Proposed patch

This needs a super-review from bz. I'm particularly nervous that you removed a test for an critical security bug[1] and secondly that you didn't answer why you needed to do that.

[1] http://www.mozilla.org/security/announce/2011/mfsa2011-29.html#cve-2011-2993
(bug 657267)

Note that bug 657267 was the resurrection of http://www.mozilla.org/security/announce/2008/mfsa2008-23.html so worries that this can recur are not outlandish. The need to remove the test as part of this patch makes me wonder if this patch re-introduces it, in fact.

Alternately, if you can finally drive a stake through the heart of enablePrivilege then this is no longer a concern. But many have perished attempting to surmount bug 546848
Comment 39 Daniel Veditz [:dveditz] 2012-08-16 19:48:21 PDT
> and secondly that you didn't answer why you needed to do that.

I apologize, you most certainly did (comment 26). comment 27 was asking about the other two tests and you put them back.

If you've broken signed scripts/enablePrivilege as implied in comment 26 then "yay", but in that case I don't understand how you aren't failing the couple hundred tests that still use enablePrivilege because SpecialPowers are not yet Special enough.
https://mxr.mozilla.org/mozilla-central/search?string=enablePrivilege&find=test&tree=mozilla-central

"sec-review+" meaning I'm done with the review, not that I'm approving the change. The "action item" from the review is "get bz to review this". If he's happy with it then I'm happy. The intent was never to validate signed add-ons after the install, the installer originally and for years unpacked the .xpi and threw away the signature. The fact that it's kept now is accidental due to changes that had nothing to do with security requirements (iirc perf related, ironically). My only security concern is whether we reintroduce earlier bugs, but I think we're OK since it appears we no longer prompt users for enhanced privileges.
Comment 40 Boris Zbarsky [:bz] (still a bit busy) 2012-08-16 20:03:36 PDT
> but in that case I don't understand how you aren't failing the couple hundred tests that
> still use enablePrivilege

None of those use signed jars; they just use enablePrivilege in a whitelisted hostname context.

What you probably need to do is add a test that checks that enablePrivilege in a signed jar fails.

That said, there are certainly consumers of signed jars out there.  Bobby, do we need more of a deprecation period + warning here than we've already had with enablePrivilege?  I'm guessing we might not...
Comment 41 Daniel Veditz [:dveditz] 2012-08-17 07:06:10 PDT
(In reply to Boris Zbarsky (:bz) from comment #40)
> That said, there are certainly consumers of signed jars out there.  Bobby,
> do we need more of a deprecation period + warning here than we've already
> had with enablePrivilege?  I'm guessing we might not...

We certainly shouldn't try to land this on beta as suggested in comment 34 given that hits the release channel in 10 days -- too much surprise.
Comment 42 Jorge Villalobos [:jorgev] 2012-08-17 07:47:31 PDT
(In reply to Daniel Veditz [:dveditz] from comment #41)
> We certainly shouldn't try to land this on beta as suggested in comment 34
> given that hits the release channel in 10 days -- too much surprise.

I agree. From an addon-compat perspective, I think it's fine that this lands on 16. enablePrivilege has been discouraged for a very long time, so I doubt that extending the deprecation period will buy us anything.
Comment 43 Boris Zbarsky [:bz] (still a bit busy) 2012-08-21 22:13:27 PDT
Comment on attachment 650944 [details] [diff] [review]
Proposed patch

You don't need the NS_ENSURE_ARG_POINTER.  sr=me with that removed and the test I asked for added on aurora if this is going to go there.
Comment 44 Vladan Djeric (:vladan) 2012-08-28 15:02:35 PDT
Created attachment 656223 [details] [diff] [review]
New regression test

New regression test for Aurora.

Regression test confirms 1) that signed JARs get codebase principals, 2) signed JARs can't call enablePrivilege.

I reused the simple signed JAR from bug 657267 -- I was having a lot of trouble creating a new signed JAR that is trusted in the mochitest environment.

The signed JAR contains an html file with a single JavaScript function:

function a() {
  netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
  return Components.stack.toString();
}
Comment 45 Boris Zbarsky [:bz] (still a bit busy) 2012-08-28 22:34:45 PDT
Comment on attachment 656223 [details] [diff] [review]
New regression test

Please just use bug657267.jar directly.  Or at least hg copy instead of just making it look like a wholly new jar file.  But I'd prefer you just use the existing file.

Other than that, looks good.
Comment 46 Boris Zbarsky [:bz] (still a bit busy) 2012-08-28 22:35:35 PDT
Oh, and I assume you checked that the test fails without this patch?
Comment 47 Vladan Djeric (:vladan) 2012-08-29 08:48:43 PDT
(In reply to Boris Zbarsky (:bz) from comment #46)
> Oh, and I assume you checked that the test fails without this patch?

Yes, without the patch, it fails on the first check: accessing a signed page from an unsigned page of the same origin.

Note that signed code can't call enablePrivilege even without this patch unless its domain is whitelisted in prefs.js via "capability.principal.codebase". This patch just has the side-effect of allowing unsigned pages to access signed pages from the same origin. There is no added security risk in this as both signed & unsigned code can call enablePrivilege if their origin is whitelisted in prefs.js.
Comment 48 Boris Zbarsky [:bz] (still a bit busy) 2012-08-29 09:16:36 PDT
Maybe I should have been clearer.

When unsigned code calls enablePrivilege while the pref you mention is not set, it gets an excepton.

When signed code calls enablePrivilege while he pref you mention is not set the user gets a dialog asking whether to allow the request.  At least last I checked.

So it's a lot easier for signed code, right now, to get to the point where it has privileges enabled.

I assume your test tests for enablePrivilege throwing, right?  The question is whether it also throws in your test without your patch; it sounds like without your patch the test doesn't even get that far.  It probably should, so that we'd guarantee a failure (via hanging, basically) if the prompt happens...
Comment 49 Vladan Djeric (:vladan) 2012-08-29 11:35:41 PDT
(In reply to Boris Zbarsky (:bz) from comment #48)
> When unsigned code calls enablePrivilege while the pref you mention is not
> set, it gets an excepton.

Right

> When signed code calls enablePrivilege while he pref you mention is not set
> the user gets a dialog asking whether to allow the request.  At least last I
> checked.

Actually, this dialog was removed in early May by Bobby Holley in Bug 750859:

http://hg.mozilla.org/mozilla-central/rev/05f7445feda3

> So it's a lot easier for signed code, right now, to get to the point where
> it has privileges enabled.

Since signed code can't request extra privileges with a dialog, it has the same limitations as unsigned code

> I assume your test tests for enablePrivilege throwing, right? 

Yes

> The question
> is whether it also throws in your test without your patch; it sounds like
> without your patch the test doesn't even get that far.  

Right, the test would fail on a different check: the check that confirms that signed JARs now get a codebase principal instead of a certificate principal. 

> It probably should,
> so that we'd guarantee a failure (via hanging, basically) if the prompt
> happens...

Is this discussion moot given that the privilege dialog functionality doesn't exist anymore?
Comment 50 Boris Zbarsky [:bz] (still a bit busy) 2012-08-29 11:39:33 PDT
> Actually, this dialog was removed in early May by Bobby Holley in Bug 750859:

Aha!  Yes, then most of this is moot.  Still worth landing the test we have here.
Comment 52 Vladan Djeric (:vladan) 2012-08-30 14:07:45 PDT
Comment on attachment 650944 [details] [diff] [review]
Proposed patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Long-standing issue. Certificates of signed extensions are getting validated on each startup, slowing down startups.
User impact if declined: Slow startups. Users of signed extensions won't see a Firefox window until certificate revocation status is verified over the network. If the OCSP server is unreachable (as was the case with StartSSL recently), startups could be delayed until the request times out (~10 seconds).
Testing completed (on m-c, etc.): Try builds, manual tests
Risk to taking this patch (and alternatives if risky): Unlikely, but theoretically, this patch could introduce a security issue.
String or UUID changes made by this patch: None
Comment 53 Ryan VanderMeulen [:RyanVM] 2012-08-30 18:59:46 PDT
https://hg.mozilla.org/mozilla-central/rev/d14ceaf50295
Comment 54 Nicholas Nethercote [:njn] 2012-08-30 20:44:23 PDT
\o/
Comment 55 Alex Keybl [:akeybl] 2012-08-31 15:44:46 PDT
Comment on attachment 650944 [details] [diff] [review]
Proposed patch

[Triage Comment]
Approving for Aurora and Beta given where we are in the cycle, and the fact that this is believed to be a low risk perf improvement.

If there are any regressions, since this is a longstanding bug, we'll definitely back out of FF16.
Comment 57 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-09-19 10:09:23 PDT
@Wladimir, can you please confirm if this is fixed for you with the latest Firefox 16 Beta and 17 Aurora builds?
Comment 58 Wladimir Palant 2013-01-27 23:03:41 PST
I can confirm that this is fixed in 21.0a1 nightly (2013-01-25) on OpenSUSE - no more OCSP requests on starup.
Comment 59 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-01-31 15:55:04 PST
Thanks Wladimir

Note You need to log in before you can comment on or make changes to this bug.