1040086 - EV identifier is no longer displayed for addons.mozilla.org when restoring session and HTTP cache v2 enabled

Status: VERIFIED FIXED

(Core :: Security: PSM, defect)

Description

[Mihaela Velimiroviciu (:mihaelav)]

Bug 995801 is reproducing again with the latest Nightly build:
Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Firefox/33.0, build id: 20140717030339,
Built from https://hg.mozilla.org/mozilla-central/rev/a74600665875

+++ This bug was initially created as a clone of Bug #995801 +++

Steps To Reproduce:
1. Open Web pages which have EV identifier
   i.e. https://addons.mozilla.org/en-US/firefox/
        https://bugzilla.mozilla.org/
  --- observe, youcan see green EV identifier
2. Exit Browser And Start Firefox again
3. Restore Previous Session

Actual Results:
  EV identifier is no longer displayed after doing "Restore Previous Session"

Comment 1

[Mihaela Velimiroviciu (:mihaelav)]

The bug is only reproducible on addons.mozilla.org

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Why is this bug part of addons.mozilla.org? Have you tested if that is the same behavior across all versions of Firefox? Also could this be a regression in Firefox? I don't see that those checks have been done. I don't think this is something related to AMO itself.

Comment 3

[Mihaela Velimiroviciu (:mihaelav)]

Yes, I tested it on older versions of Nightly (16June, 1 July, 7 July) and Aurora which worked before and it's reproducible and ONLY with addons.mozilla.org.
It is not reproducible with Firefox 31 (tried beta 5 and RC)

Comment 4

[Gian-Carlo Pascutto [:gcp]]

I can confirm. 

I saw an additional problem:
Trying to expand the certificate (via clicking more information) to see what's up makes the dialog construct and immediately disappear. But this went away after a while.

That said, there's no reason to believe it's a bug with the *site*.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Right, so please check for the regression range.

Comment 6

[Mihaela Velimiroviciu (:mihaelav)]

As mentioned in comment #3 (and discussed with gcp on IRC), this is not a Firefox issue, but a site one.
The issue only reproduces on addons.mozilla.org, it is not reproducible with other EV certificate sites, like bugzilla.mozilla.org or op.fi.
The issue is now reproducible on builds which worked fine before (like the June 16 Nightly and Aurora, July 7 Nightly), after the fix for bug 995801 landed and was successfully verified by QA.
Still, it seems that it works fine on the Firefox 31 beta/RC builds.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

If you say it works with older versions of Firefox why wouldn't you want a regression window? It may be a site issue or a Firefox issue. Knowing what change in Firefox makes it no longer work is surely going to be very informative.

Comment 8

[[:mmc] Monica Chew (no longer reading bugmail)]

Hi Mihaela,

For example certificate pinning was enabled for addons.mozilla.org in FF 32. That would be a Firefox issue *and* a site issue if it broke recently. I don't think pinning is responsible for this particular breakage don't think we can eliminate the possibility that it is a Firefox issue quite yet. There have also been many changes to certificate verification and OSCP interaction with EV recently. Actually, I suspect one of those, needinfo'ing keeler.

Thanks,
Monica

Comment 9

[[:mmc] Monica Chew (no longer reading bugmail)]

I also cannot reproduce the breakage on mac on 7/17's nightly.

Comment 10

[Alice0775 White]

Steps To Reproduce:
1. Make sure uncheck "Don't load tabs until selected". i.e, browser.sessionstore.restore_on_demand = false
2. Open any web page in [TAB A]
3. Open https://addons.mozilla.org/en-US/firefox/ in [TAB B]
4. Select [TAB A]
5. Exit Browser And Start Firefox again
6. Restore Previous Session
7. Select [TAB B] after completion to load all tabs

Actual Results:
  EV identifier is no longer displayed after doing "Restore Previous Session"


Regression window(m-c)
Good:
https://hg.mozilla.org/mozilla-central/rev/e8df6826a571
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140703202504
Bad:
https://hg.mozilla.org/mozilla-central/rev/0bcf1102e943
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140704044517
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e8df6826a571&tochange=0bcf1102e943


Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7231daefbb28
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140703232503
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/240a0b085725
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140703234337
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7231daefbb28&tochange=240a0b085725

Regressed by:
240a0b085725	Harsh Pathak — Bug 643041 - Merge nsIX509Cert2 and nsIX509Cert3 into nsIX509Cert, and merge nsIX509CertDB2 into nsIX509CertDB. r=keeler

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks a lot Alice for this ultra-fast regression analysis! Moving bug back into Core.

Comment 12

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

I can reproduce the problem in aurora (32), which means that bug 643041 isn't the culprit (it landed in 33 and hasn't been uplifted). I will investigate further tomorrow.

Comment 13

[hpathak]

Not able to reproduce the issue for 7/17's nightly on Mac.

Comment 14

[Mihaela Velimiroviciu (:mihaelav)]

(In reply to Alice0775 White from comment #10)
> Steps To Reproduce:
> 1. Make sure uncheck "Don't load tabs until selected". i.e,
> browser.sessionstore.restore_on_demand = false
> 2. Open any web page in [TAB A]
> 3. Open https://addons.mozilla.org/en-US/firefox/ in [TAB B]
> 4. Select [TAB A]
> 5. Exit Browser And Start Firefox again
> 6. Restore Previous Session
> 7. Select [TAB B] after completion to load all tabs
> 
> Actual Results:
>   EV identifier is no longer displayed after doing "Restore Previous Session"

I reproduce the issue with more simple steps:
1. Launch Firefox with new profile
2. Go to addons.mozilla.org -> so far, this is the only website I reproduced the issue with
3. Close Firefox
4. Start Firefox again, with the same profile as in step 1
5. Restore previous session

Result: EV identifier is not displayed for addons.mozilla.org

> Regression window(m-c)
> Good:
> https://hg.mozilla.org/mozilla-central/rev/e8df6826a571
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
> ID:20140703202504
> Bad:
> https://hg.mozilla.org/mozilla-central/rev/0bcf1102e943
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
> ID:20140704044517
> Pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=e8df6826a571&tochange=0bcf1102e943

As mentioned in comment #3, I can reproduce the issue even on older builds, like July 1 Nightly and June 16 Aurora, with the steps I provided in this comment.

(In reply to hpathak from comment #13)
> Not able to reproduce the issue for 7/17's nightly on Mac.

I can still reproduce on Ubuntu with latest Nightly build (20140718030202) and steps I mentioned in this comment

(In reply to Dana Keeler (:keeler) [use needinfo?] from comment #12)
> I can reproduce the problem in aurora (32), which means that bug 643041
> isn't the culprit (it landed in 33 and hasn't been uplifted). I will
> investigate further tomorrow.

I also reproduced the issue with a June 16 Aurora. Bug 995801, which has the same STR, was verified on June 13 Aurora build and it worked fine then (on addons.mozilla.org and other pages).

Comment 15

[Alice0775 White]

:mihaelav
So, regression range?

Comment 16

[Mihaela Velimiroviciu (:mihaelav)]

OS: Ubuntu 14.04, x86

I cannot determine the "exact" regression range here because of bug 995801.
Here is what I found while trying to get a regression range:
* 18Jan2014 Nightly - all works fine (EV certificate identifier is displayed for all sites after restart and session restore - with steps from comment 14)
* 19Jan2014 Nightly - first build on which I reproduced bug 995801 (EV certificate identifier is not displayed in the location bar for ALL sites - with AMO and bugzilla.mozilla.org and steps from comment 14)
* 29May2014 Nightly - first build on which bug 995801 was fixed (and later verified as fixed by QA); this is also the first build on which NOW I reproduce the issue but ONLY with addons.mozilla.org (I cannot reproduce it with bugzilla.mozilla.org, with the same steps as in comment 14)

I usually use latest Nightly builds and didn't see the issue while using those builds in June 17 - July 11 timeframe (although I tested around this area).

Comment 17

[Benjamin Kerensa [:bkerensa]]

Have you been able to reproduce on Nightly? Would like to see some reproduction on Nightly to help make the tracking decision.

Comment 18

[u279076]

(In reply to Benjamin Kerensa [:bkerensa] from comment #17)
> Have you been able to reproduce on Nightly? Would like to see some
> reproduction on Nightly to help make the tracking decision.

I'm not able to reproduce this bug with the steps provided. Perhaps someone who is able to reproduce this would be better to make that judgement call. However, if this is truly isolated to just addons.mozilla.org, I'd be inclined not to track it.

Comment 19

[Mihaela Velimiroviciu (:mihaelav)]

I can still reproduce the issue with latest Nightly build (Build identifier: Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Firefox/33.0, build id 20140720030203) with my steps from comment #14

Comment 20

[Jim Jeffery not reading bug-mail 1/2/11]

100% reproducible with a clean profile on win7 x64 with latest m-c Nightly build.  

I cannot repo with my 2 year old 'dirty' profile.  Cleaning History and Cookies for AMO makes no difference, here it still shows the EV on the dirty profile.

This on AMO only, Bugzilla & Paypal both display EV in both clean/dirty profiles.

Comment 21

[Sylvestre Ledru [:Sylvestre]]

Harsh, does it a bell?

Anyway, tracking because EV matters.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #20)
> I cannot repo with my 2 year old 'dirty' profile.  Cleaning History and
> Cookies for AMO makes no difference, here it still shows the EV on the dirty
> profile.

Jim, what happens when you clean the cache first? Or any other setting through "Clear Recent History"? Something has to cause this, even if it is a user preference.

Comment 23

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to Henrik Skupin (:whimboo) from comment #22)
> (In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #20)
> > I cannot repo with my 2 year old 'dirty' profile.  Cleaning History and
> > Cookies for AMO makes no difference, here it still shows the EV on the dirty
> > profile.
> 
> Jim, what happens when you clean the cache first? Or any other setting
> through "Clear Recent History"? Something has to cause this, even if it is a
> user preference.

Sorry for delay, required a bunch of testing.

I have found for me at least that the new Cache2 is the causing the problem.
My 'dirty' profile I have the new Cache2 disabled and still using the old cache.

Turning off the new cache2 in about:config, 
Open the Options panel - Custom Setting -> Privacy -> Settings, clear everything
Close Browser
Delete the cache folders manually in Windows Explorer
Restart the browser - Options panel uncheck 'clear history' on close
visit AMO 
open/close several times with the 'old cache' after clearing everying and cache2 'off' and AMO will show EV everytime.

Comment 24

[Patrick McManus [:mcmanus]]

comment 23

Comment 25

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Great catch Jim! I can perfectly replicate this behavior on my box. So it's clearly the HTTP cache v2, which is causing this problem.

Comment 26

[hpathak]

(In reply to Sylvestre Ledru [:sylvestre] from comment #21)
> Harsh, does it a bell?

As Jim/Henrik have mentioned, its probably due to caching v2. Also, as per comment 12, this was present in aurora before the uplift.

Comment 27

[Michal Novotny [:michal]]

It's almost impossible to reproduce this bug on my linux machine. I hit it just twice in many tries. AFAICS this is definitely not a cache2 bug. This is just a coincidence that it can be reproduced with cache2 and not with the old cache. What happens is that the security info is stored to the cache entry sooner than the certificate is validated, so the certificate is stored with mCachedEVStatus == ev_status_unknown. After restart, the security info is read from the cache entry and it is not re-validated, instead the mCachedEVStatus is set to ev_status_invalid in nsNSSCertificate::getValidEVOidTag().

I don't know the security code, so I don't know whether the problem is that we store the certificate with unknown EV state or that the certificate is not re-validated when we read such certificate from the cache.

Comment 28

[Jason Duell]

Dana, any idea who could look at this?  Sounds like it's a matter of making sure the cert has been validated by the time we store security info in the cache.  Michal is under the impression that's where the bug is here, and not in the cache itself.

Comment 29

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Right now we don't re-validate certificates from the cache (see bug 660749). My guess is the entry is being stored in the cache when mCachedEVStatus = ev_status_unknown and isn't getting replaced when mCachedEVStatus is set to ev_status_valid. Since Honza knows both PSM and Necko, I think he would be a good candidate for figuring this out.

Comment 30

[Jason Duell]

I agree Honza would be a good person for this, but he's out on PTO for an unknown amount of time.  And this bug is presumably on beta (firefox 32) because that's when cache2 landed.  So if this is important enough to not land on release we'll need to find someone else.  

From my very quick parsing of bug 660749 it sounds like we want to teach the HTTP cache to revalidate anyway for other reasons (at least if the symptoms in bug 660749 comment 0 are still true, i.e. "accept this cert only for this session" is broken when cached).  But that also sounds like it would involve storing new fields in the cache (bug 660749 comment 50), which is a large-ish change for late in the beta cycle.  How bad do we consider this bug?

Comment 31

[Jason Duell]

Valentin's going to try to fix this (probably by fixing bug 660749).

Comment 32

[Valentin Gosu [:valentin] (he/him)]

I think I may have figured out how to do the revalidation. However, I'm confused about when we should be doing it. If we dispatch the task to revalidate when we load the cache entry from disk and it has a ev_status_unknown, would the revalidation fix this issue? Or do we need to refresh the page somehow to get the green EV identifier to display?

Comment 33

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Keep in mind that verifying a certificate for EV requires revocation information, which means fetching OCSP (until we have OCSP GET, this information isn't cached on disk). Doing this on the main thread is undesirable. Doing it at all is a bummer because in this case we're loading a site from the cache but we're still taking the performance hit by waiting on the network.

Comment 34

[Valentin Gosu [:valentin] (he/him)]

Michal indicated CacheEntry::GetSecurityInfo() as a good place to start, so I'm going to look at that.
This revalidation shouldn't be too costly, as it would only happen for cache entries that are saved before the validation is finished. It would be great if we could delay saving the entry to disk for a while, but revalidating it seems a good compromise in the mean time.

Comment 35

[Jason Duell]

It does seem like waiting for validation before saving the entry to disk would be ideal here.  Is that more complicated than adding revalidation?  Perhaps we could add some "wait for notification to write cache entry to disk" flag on channels?

Comment 36

[Valentin Gosu [:valentin] (he/him)]

Upon investigation I managed to figure out the issue. Bug 660749 comment 52. I'm moving the discussion to that bug, in hope that we can figure out a fix.

Comment 37

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Valentin Gosu [:valentin] from comment #36)
> Upon investigation I managed to figure out the issue. Bug 660749 comment 52.
> I'm moving the discussion to that bug, in hope that we can figure out a fix.

Does this mean that this bug should be marked as a dup of bug 660749?

Comment 38

[Valentin Gosu [:valentin] (he/him)]

Yes, this is the same bug. Feel free to mark it as a duplicate unless you want it to be tracked separately.

Comment 40

[Honza Bambas (:mayhemer)]

Discussion moved to a different bug.

Comment 41

[Honza Bambas (:mayhemer)]

Hmm.. that bug is a bit about a different issue, reopening as a standalone issue.  This has nothing to do with cert revalidation, this is probably an unrelated regression.


Mihaela, Alice0775, can you please provide content of a file located at:

  <profile>/cache2/entries/6D58A80BA1A95408C85CE28E9AE05FC839FA7AE2 

for the case you can reproduce the missing EV status?  That is the file bound to the https://addons.mozilla.org/en-US/firefox/ URL, I want to make sure it's cache that stores the status wrong.

Thanks.

Comment 42

[Alice0775 White]

I cannot reproduce the problem on latest Nightly34.0a1 and Aurora33.a2 as well.

I cannot reproduce the problem on bad build of Comment 10 too....

Comment 43

[Michal Novotny [:michal]]

Attachment: logs and cache entries

(In reply to Honza Bambas (:mayhemer) from comment #41)
> for the case you can reproduce the missing EV status?  That is the file
> bound to the https://addons.mozilla.org/en-US/firefox/ URL, I want to make
> sure it's cache that stores the status wrong.

I think it's clear from my comment #27. Attached are logs from my linux box where I was able to reproduce it just twice. The cache entries are from my windows notebook, where I was able to reproduce it much more often, but I don't have development environment there.

Comment 44

[Honza Bambas (:mayhemer)]

(In reply to Michal Novotny (:michal) from comment #43)
> Created attachment 8475306 [details]
> logs and cache entries
> 
> (In reply to Honza Bambas (:mayhemer) from comment #41)
> > for the case you can reproduce the missing EV status?  That is the file
> > bound to the https://addons.mozilla.org/en-US/firefox/ URL, I want to make
> > sure it's cache that stores the status wrong.
> 
> I think it's clear from my comment #27. 

I wasn't sure you really have seen the badly stored value.

> Attached are logs from my linux box
> where I was able to reproduce it just twice. The cache entries are from my
> windows notebook, where I was able to reproduce it much more often, but I
> don't have development environment there.

Thanks!

Comment 45

[Jim Jeffery not reading bug-mail 1/2/11]

Still 100% reproducable here on the latest m-c hourly build on win7 x64.

cset: https://hg.mozilla.org/mozilla-central/rev/4d94eeca89f3

Using my steps above it was easily re-created using AMO and having the cache2 enabled.

Comment 46

[Honza Bambas (:mayhemer)]

I think I know why this demonstrates so more often with cache v2.  The same bug is in cache v1 - the same race condition!

Difference is that cache v1 serializes the security info simply later, in nsDiskCacheMap::CreateDiskCacheEntry.  Cache v2 does it immediately when the object is set on the entry in nsHttpChannel::AddCacheEntryHeaders which is mostly called very soon from nsHttpChannel::OnStartRequest.  I don't follow why there is this race, the EV state cache should be up-to-date at that moment.  However chasing that bug - if that is a bug - is an overkill.

I can think of storing the sec-info again in e.g. OnStopRequest as a short-therm workaround.  Other way (more correct IMO) could be to just set the object down at the CacheFileMetadata that are persisted way later.  Serialization of the object can happen there.  It's mid-complex work to do.

Comment 47

[Honza Bambas (:mayhemer)]

Plan failed - when we serialize sec info at the time we want to write the metadata there is a race with NSS shutdown (happening at profile-before-change): nsNSSCertificate has already dropped the reference to mCert, hence it cannot be serialized anymore...  Our final pending metadata serialization happens in xpcom-shutdown.

I'll try the OnStopRequest:SetSecurityInfo approach and submit a try to check with.

Comment 48

[Honza Bambas (:mayhemer)]

Attachment: v1

https://tbpl.mozilla.org/?tree=Try&rev=864f565ec187

Anyone able to reproduce, please check with these try builds (at this time in progress of build).  Hopefully we will at least minimize the number of occasions to insignificant percents.

Comment 49

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to Honza Bambas (:mayhemer) from comment #48)
> Created attachment 8476338 [details] [diff] [review]
> v1
> 
> https://tbpl.mozilla.org/?tree=Try&rev=864f565ec187
> 
> Anyone able to reproduce, please check with these try builds (at this time
> in progress of build).  Hopefully we will at least minimize the number of
> occasions to insignificant percents.

Tested with 2 different vanilla profiles just to be sure, cleared cache and cache2.  

After visiting AMO, and doing several restarts of the browser in both profiles I can confirm that I'm NOT able to reproduce the issue, where before it was very easy to do, so this looks from my end.

Comment 50

[Honza Bambas (:mayhemer)]

Comment on attachment 8476338 [details] [diff] [review]
v1

Seems like a good workaround, thanks for the test Jim!

https://tbpl.mozilla.org/?tree=Try&rev=857e7aaeefb8

Comment 51

[Jason Duell]

Comment on attachment 8476338 [details] [diff] [review]
v1

Review of attachment 8476338 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/protocol/http/nsHttpChannel.cpp
@@ +3655,5 @@
>      if (doom) {
>          LOG(("  dooming cache entry!!"));
>          mCacheEntry->AsyncDoom(nullptr);
> +    } else {
> +      // Store updated security info, makes the cached EV status race less likely

might be worth putting bug # in comment, in case this ever gets cut-and-pasted, etc.  Not a big deal.

Comment 52

[Jason Duell]

Comment on attachment 8476338 [details] [diff] [review]
v1

Approval Request Comment
[Feature/regressing bug #]: long standing but aggravated by cache2
[User impact if declined]: see bug: no EV shown when session restored from cache
[Describe test coverage new/current, TBPL]: no, but we have STR
[Risks and why]: low risk.  One liner, just writes data to disk later.
[String/UUID change made/needed]: none

Comment 53

[Jason Duell]

 https://hg.mozilla.org/integration/mozilla-inbound/rev/543af9cd7448

Comment 54

[Ryan VanderMeulen [:RyanVM]]

Due to scheduling reasons, this isn't likely to make it over to m-c tonight, but it's sufficiently green on inbound that I'm confident saying that it's not getting backed out at this point.

Comment 55

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8476338 [details] [diff] [review]
v1

Approved for aurora and beta based on the patch being green on inbound.

Comment 56

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/a10c80107907
https://hg.mozilla.org/releases/mozilla-beta/rev/33ea2d7e342e

Comment 57

[Mihaela Velimiroviciu (:mihaelav)]

I tested with Firefox 32.0 beta 9, latest Aurora (Aug 22) and latest Nightly(Aug 22) on the following environments:
* Ubuntu 14.04, 32 bit
* Mac OS 10.8.5

I wasn't able to reproduce the issue anymore with Firefox 32 beta 9 and latest Aurora, BUT latest Nightly seems to still have some issues. After several tries/restarts, having multiple pages with EV certificate open (a few addons.mozilla.org/... pages and a few bugzilla.mozilla.org/... ones) I noticed that one (randomly) of the tabs doesn't show the EV identifier (instead, it shows the DV one). I tried on several clean profiles on Mac and Ubuntu, and I was able to reproduce this (with different page each time, once it was one of the AMO pages - on Ubuntu, some times it was one of the Bugzilla pages - search page, a bug page, etc - on Mac).

I couldn't reproduce this on Aurora nor on Beta, yet, and haven't tested on Windows because the builds are not available.

Comment 58

[Honza Bambas (:mayhemer)]

Mihaela, Thanks.  As I said, there still is a possibility for the root race condition.  The patch mostly just makes is much less likely to happen.

I believe you will be able to (less likely, but still likely) reproduce it even with cache v1.

Let's file a new bug like "rarely missing EV on session restore" if you are confident this really happens rarely.

Comment 59

[juan becerra [:juanb]]

Tested this on Win7 using Fx32b9(build1) and I haven't been able to reproduce the problem. I won't mark it as verified on beta until Mihaela has a chance to double check.

Comment 60

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/543af9cd7448

Comment 61

[Mihaela Velimiroviciu (:mihaelav)]

I tested on Win 7 x64 with Firefox 32 beta 9, latest Aurora and latest Nightly and didn't reproduce the issue. 
Marking verified across all branches.

Comment 62

[Mihaela Velimiroviciu (:mihaelav)]

(In reply to Honza Bambas (:mayhemer) from comment #58)
> Let's file a new bug like "rarely missing EV on session restore" if you are
> confident this really happens rarely.

Logged bug 1058009

Comment 63

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Honza Bambas (:mayhemer) from comment #58)
> Mihaela, Thanks.  As I said, there still is a possibility for the root race
> condition.  The patch mostly just makes is much less likely to happen.

I think the problem here was simply that Mihaela tested Nightly before it actually had the fix. As stated in comment 54 there were scheduling issues for the inbound -> m-c merge. So the patch landed about 8h after Mihaela tested Nightly.