678547 - Firefox 8.0a1 crashes [@ nsHandleSSLError ] if security.OCSP.require is true

Status: RESOLVED DUPLICATE of bug 678440

(Core :: Security: PSM, defect)

Description

[linuser]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0a1) Gecko/20110812 Firefox/8.0a1
Build ID: 20110812030744

Steps to reproduce:

I was restarting nightly to install the daily update


Actual results:

Nightly crashed and the crash report window came up

Comment 1

[linuser]

The browser didn't crash again after setting security.OCSP.require to false ( by editing ~/.mozilla/firefox<profile>/prefs.js )

Comment 2

[Thomas Ahlblom]

Moving Report IDs off Crash Signature and putting the crash signature there instead.

bp-f4f30de3-ef62-4a58-9016-c30fa2110812
bp-fa7c9e56-3338-4b0e-aca8-916d12110812
bp-29124a97-1f64-45e9-987c-696952110812

Comment 3

[Matthew N. [:MattN]]

Confirming as I can reproduce this starting with today's nightly with security.OCSP.require set to true on Mac OS X 10.6.8:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a1) Gecko/20110812 Firefox/8.0a1

Likely caused by changeset http://hg.mozilla.org/mozilla-central/rev/0cf822d12c64 from bug 674571

Comment 4

[Luke Wagner [:luke]]

Judging by the crash address (http://hg.mozilla.org/mozilla-central/annotate/f262c389193e/security/manager/ssl/src/nsNSSIOLayer.cpp#l1439), which is immediately after a NS_GetProxyForObject, I think the cause is the next cset http://hg.mozilla.org/mozilla-central/rev/be91fb29d950 which explictly aborts.

It would seem that OCSCP.require lacks automated tests, since this would have been caught and fixed earlier.

Comment 5

[Luke Wagner [:luke]]

I can't reproduce by setting OCSP.require to true.  Is there a particular startup page that is causing this?  This could also be caused by a plugin writing wrapped JS for certain NSS interfaces; could you test whether the crash reproduces with all extensions disabled?

Comment 6

[Matthew N. [:MattN]]

(In reply to Luke Wagner [:luke] from comment #5)
> I can't reproduce by setting OCSP.require to true.  Is there a particular
> startup page that is causing this?  

I'm working on STR

> This could also be caused by a plugin
> writing wrapped JS for certain NSS interfaces; could you test whether the
> crash reproduces with all extensions disabled?

I could reproduce it in safe-mode: https://crash-stats.mozilla.com/report/index/bp-2d5cbd37-8ce8-402b-8f64-7c1fa2110812

Comment 7

[Luke Wagner [:luke]]

Great.  comment 4 fingered the offending code, I'll write a patch to convert the bad proxy use to a plain old runnable.

Comment 8

[Matthew N. [:MattN]]

(In reply to Matthew N. [:MattN] from comment #6)
> (In reply to Luke Wagner [:luke] from comment #5)
> > I can't reproduce by setting OCSP.require to true.  Is there a particular
> > startup page that is causing this?  
> 
> I'm working on STR

I can't seem to reproduce this anymore after setting the pref back to true.  Perhaps the OCSP server is responding properly now so the error code path is not getting executed.

Comment 9

[Luke Wagner [:luke]]

Attachment: fix

This patch removes the offending NS_GetProxyForObject calls which caused the abort.

Comment 10

[Daniel Veditz [:dveditz]]

Comment on attachment 552824 [details] [diff] [review]
fix

Kai: please review or pass on to bsmith if you're too busy. This crash needs to be fixed if we want to require OCSP responses (especially for all the people who currently have that enabled in the aftermath of #comodogate).

Comment 11

[Luke Wagner [:luke]]

Comment on attachment 552824 [details] [diff] [review]
fix

The assert has been backed out (5f0596a0b81e) which should be in the latest nightly.

Comment 12

[Luke Wagner [:luke]]

Crashes have dropped to 0.