1138535 - V2 signatures broken in current aurora and m-c nightlies

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Steven Michaud [:smichaud] (Retired)]

To see this problem, you need to make sure "Allow downloaded applications from" in the Security & Privacy system pref panel is set to its default value of "Mac App Store and identified developers".

With that setting, double-clicking on today's m-c nightly causes the following error:

FirefoxNightly is damaged and can't be opened. You should move it to the Trash.

spctl -a -v returns the following:

FirefoxNightly.app: a sealed resource is missing or invalid

codesign -vvvv returns the following:

In architecture: i386
resource added: /[...]/FirefoxNightly.app/Contents/Resources/precomplete

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Here's the regression range:

firefox-2015-02-19-03-02-04-mozilla-central
firefox-2015-02-19-07-07-49-mozilla-central

http://hg.mozilla.org/mozilla-central/pushloghtml?&fromchange=360b5f211180&tochange=986e840a2979

Comment 2

[Stephen A Pohl [:spohl]]

Bug 1123990 broke v2 signatures on OSX. The precomplete file has to be created before the bundle is signed, so this change will not work[2].

To verify a valid signature, run the following commands in a terminal:
> spctl -a -v {bundlename}.app
> codesign -vvvv {bundlename}.app
> codesign -dv {bundlename}.app

[1] http://hg.mozilla.org/mozilla-central/rev/986e840a2979
[2] http://hg.mozilla.org/mozilla-central/diff/986e840a2979/toolkit/mozapps/installer/packager.mk

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Actually this effects both the 38 and 39 branches.

[Tracking Requested - why for this release]:

Firefox won't run on OS X with the default security settings.

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 38 and 39.   When you have a working fix please nominate this for uplift to 38. Thanks!

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

I gave this a try just now in MacOS X (Yosemite), resetting the Security & Privacy panel to default, and opening the latest Nightly with a new profile. It opened without any error.  Is there a step I'm missing to reproduce this? Or might it only be affecting particular versions of OSX?

Comment 6

[Stephen A Pohl [:spohl]]

It's the download that gets tagged as potentially insecure. The only bulletproof way to tell whether or not a signature is valid is to run the three commands in comment 2 from a Terminal.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

You need to test with a "new" FF distro -- a new copy of FF that you've just dragged off a DMG that you previously downloaded over http.  Apple's security check isn't made for a copy that you previously ran successfully at least once (by double-clicking on it), presumably when your security setting was less strict.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

> over http

over http or ftp (i.e. using a browser)

Comment 9

[Steven Michaud [:smichaud] (Retired)]

It's been suggested that we need a test to make sure we don't break V2 signatures again in the future.  Not a bad idea, but it may be too difficult to be practical.

It almost certainly can't be a mochitest.  In fact the only thing I can think of is to change the build process to run "spctl -a -v" on a Mac build signed using codesign, just after we've signed it.  Then we can look for the appropriate parts of the following result:

FirefoxNightly.app: accepted
source=Developer ID

Of course, this would only make sense for a build we'd signed, and only then for one signed using codesign.  (There are other signing technologies in play in the building process.)  It'd also only make sense if we could set "Allow applications downloaded from" to "Mac App Store and identified developers" on all of our build machines -- which may or may not be feasible.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #9)

The spctl command may need to connect to Apple servers, which might rule out its use on our building machines (or at least our signing machines).

Comment 11

[Michael Shal [:mshal]]

(In reply to Stephen Pohl [:spohl] from comment #2)
> To verify a valid signature, run the following commands in a terminal:
> spctl -a -v {bundlename}.app
> codesign -vvvv {bundlename}.app
> codesign -dv {bundlename}.app

Do I need to run all three to verify? I downloaded a .dmg from a build and did the following on my local mac:

$ hdiutil attach firefox-39.0a1.en-US.mac.dmg
Checksumming Driver Descriptor Map (DDM : 0)…
     Driver Descriptor Map (DDM : 0): verified   CRC32 $3C0B81ED
Checksumming Apple (Apple_partition_map : 1)…
     Apple (Apple_partition_map : 1): verified   CRC32 $7EB8565B
Checksumming DiscRecording 6.0d1 (Apple_HFS : 2)…
...................................................................................................................................
 DiscRecording 6.0d1 (Apple_HFS : 2): verified   CRC32 $BBE87108
verified   CRC32 $E140217E
/dev/disk2          	Apple_partition_scheme         	
/dev/disk2s1        	Apple_partition_map            	
/dev/disk2s2        	Apple_HFS                      	/Volumes/Nightly

$ spctl -a -v /Volumes/Nightly/Nightly.app/
/Volumes/Nightly/Nightly.app/: unknown error -67021=fffffffffffefa33

$ codesign -vvvv /Volumes/Nightly/Nightly.app/
/Volumes/Nightly/Nightly.app/: a sealed resource is missing or invalid
In architecture: i386
resource added: /Volumes/Nightly/Nightly.app/Contents/Resources/precomplete

$ codesign -dv /Volumes/Nightly/Nightly.app/
Executable=/Volumes/Nightly/Nightly.app/Contents/MacOS/firefox
Identifier=org.mozilla.nightly
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=388 flags=0x0(none) hashes=13+3 location=embedded
Signature size=1698
Signed Time=Mar 2, 2015 7:59:50 PM
Info.plist entries=20
Sealed Resources rules=4 files=71
Internal requirements count=1 size=196

For spctl, I'm not sure what that error is about. Maybe I don't have something configured correctly on my machine? And for 'codesign -dv', it exits with an error code of 0, so it might not be as useful in a test. The 'codesign -vvvv' one exits with 1 and has a useful message - is it sufficient to just use that for my local verification?

I ran all these with tcpdump in another window and I didn't see any network activity, though perhaps spctl was bailing out before it got to that point.

I agree it would be great if we could incorporate that into a test somewhere, but I'm not sure where best to do that. The 'codesign -vvvv' command does run very quickly (~100ms), so there shouldn't be much impact if we can find the right place to add it.

Anyway, I'm trying to test out a fix on ash. This is a bit confusing since on OSX we need to create the precomplete file before signing (otherwise we trigger this bug), but on Windows we need to sign exes before generating the EME voucher, and we have to generate the EME voucher before we create the precomplete file. Altogether it sounds very circular, but I think things are sufficiently ifdef'd to work around that.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

> For spctl, I'm not sure what that error is about.

I'd bet it's caused by running spctl on an app in a (mounted) dmg.

I'm pretty sure that spctl -a -v doesn't write anything to the app it's checking.  But the spctl utility may not like running on something in a volume that can't be written to.

Comment 13

[Michael Shal [:mshal]]

Hmm, I tried copying Nightly.app out (so it's writeable now), but I still get the -67021 error. If 'codesign -vvvv' looks good, can I claim victory? Or are there other things that are checked by spctl and 'codesign -dv'?

Comment 14

[Steven Michaud [:smichaud] (Retired)]

> The 'codesign -vvvv' one exits with 1 and has a useful message - is
> it sufficient to just use that for my local verification?

I think so.

Let's just forget about spctl.

spctl does check other things (that's presumably why it can take so long).  But I expect the check done by 'codesign -vvvv' is "good enough".  What do you think, Stephen?

Comment 15

[Stephen A Pohl [:spohl]]

(In reply to Steven Michaud from comment #14)
> > The 'codesign -vvvv' one exits with 1 and has a useful message - is
> > it sufficient to just use that for my local verification?
> 
> I think so.
> 
> Let's just forget about spctl.
> 
> spctl does check other things (that's presumably why it can take so long). 
> But I expect the check done by 'codesign -vvvv' is "good enough".  What do
> you think, Stephen?

I think it's sufficient to use 'codesign -vvvv' to verify this particular bug here. But could you clarify: are you saying that codesign exits with 1 when the signature check was successful? That should most definitely be 0, but I'm not sure if you were referring to the current (broken) state, or the expected (valid signature) state.

Comment 16

[Michael Shal [:mshal]]

Can you double-check the builds on ash?

https://treeherder.mozilla.org/#/jobs?repo=ash&revision=746c98217111
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/ash-macosx64/1425393725/
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/03/2015-03-03-06-42-14-ash/

I think they're good now - at least the message about the precomplete file is gone:

$ codesign -vvvv /Volumes/Nightly/Nightly.app/
/Volumes/Nightly/Nightly.app/: valid on disk
/Volumes/Nightly/Nightly.app/: does not satisfy its designated Requirement

The "does not satisfy its designated Requirement" is because the builds on ash use self-signed keys:

$ codesign -dvv /Volumes/Nightly/Nightly.app/
...
Authority=Mozilla Fake DMG Cert

Comment 17

[Michael Shal [:mshal]]

(In reply to Stephen Pohl [:spohl] from comment #15)
> I think it's sufficient to use 'codesign -vvvv' to verify this particular
> bug here. But could you clarify: are you saying that codesign exits with 1
> when the signature check was successful? That should most definitely be 0,
> but I'm not sure if you were referring to the current (broken) state, or the
> expected (valid signature) state.

I was referring to the broken state. 'codesign -vvvv' returns 1 if it's broken and 0 if it's ok. This is in comparison to 'codesign -dv', which exited with 0 even for a broken app.

Comment 18

[Stephen A Pohl [:spohl]]

(In reply to Michael Shal [:mshal] from comment #16)
> Can you double-check the builds on ash?

Hmm, I checked the two builds here:

> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/ash-macosx64/
> 1425393725/
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/03/2015-03-03-06-
> 42-14-ash/

But the output doesn't look right (it's the same output for both):

spohl:mozilla-central Stephen$ codesign -vvvv ~/Documents/bugs/bug1138535/1/Nightly.app
/Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app: nested code is modified or invalid
file modified: /Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app/Contents/MacOS/crashreporter.app
file modified: /Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app/Contents/MacOS/firefox-bin
file modified: /Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app/Contents/MacOS/libfreebl3.dylib
file modified: /Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app/Contents/MacOS/libmozalloc.dylib
file modified: /Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app/Contents/MacOS/libmozglue.dylib
file modified: /Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app/Contents/MacOS/libnss3.dylib
file modified: /Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app/Contents/MacOS/libnssckbi.dylib
file modified: /Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app/Contents/MacOS/libnssdbm3.dylib
file modified: /Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app/Contents/MacOS/libplugin_child_interpose.dylib
file modified: /Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app/Contents/MacOS/libsoftokn3.dylib
file modified: /Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app/Contents/MacOS/plugin-container.app
file modified: /Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app/Contents/MacOS/updater.app
file modified: /Users/Stephen/Documents/bugs/bug1138535/1/Nightly.app/Contents/MacOS/XUL

Comment 19

[Michael Shal [:mshal]]

Can you list the exact steps you're doing? Here's what I'm doing, and I don't see the nested code error:

$ wget http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/ash-macosx64/1425393725/firefox-39.0a1.en-US.mac.dmg
$ hdiutil attach firefox-39.0a1.en-US.mac.dmg 
$ codesign -vvvv /Volumes/Nightly/Nightly.app/
/Volumes/Nightly/Nightly.app/: valid on disk
/Volumes/Nightly/Nightly.app/: does not satisfy its designated Requirement

I tried this on my local mac, as well as a build slave (bld-lion-r5-043)

Comment 20

[Steven Michaud [:smichaud] (Retired)]

> wget

Don't use wget to download the DMG.  Instead use any web browser.

If you use wget, I don't believe the DMG will have a com.apple.quarantine attribute -- which it needs to have for Apple to require a security check of apps dragged out of the DMG.

Comment 21

[Steven Michaud [:smichaud] (Retired)]

After using Firefox to download your ash dmg from comment #19, then dragging Nightly.app out of it, 'spctl -a -v' returns the following on it, which you reported above (and which I've never seen before):

Nightly.app: unknown error -67021=fffffffffffefa33

Comment 22

[Steven Michaud [:smichaud] (Retired)]

Later versions of codesign return more information.  I get the same results as Stephen (comment #18) when I use 'codesign -vvvv' on OS X 10.10.2.

Comment 23

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #20)

Actually, the presence or absence of the com.apple.quarantine attribute doesn't seem to make any difference to the results from 'codesign -vvvv' and 'spctl -a -v'.  It *does* make a difference, though, to what happens when you double-click on a build dragged from a DMG:  If the DMG doesn't have a com.apple.quarantine attribute (and I've confirmed that it doesn't when you use wget), neither does the build dragged from it.  And even when that build is signed improperly or not at all, double-clicking on it works just fine.

Use the xattr -l command to see a file's or directory's extended attributes.

Comment 24

[Stephen A Pohl [:spohl]]

Michael, are you on OSX 10.9.5 or above? codesign varies based on the version of OSX and you will need to verify on 10.9.5 or above. FYI, copying codesign from one version of OSX to another will not work either.

Comment 25

[Michael Shal [:mshal]]

Nope, my mac is on 10.8.5, while our build machines (or at least, this one I'm testing with) is 10.7.2.

I'm trying to find a way to build this with real keys to see if that's causing the -67021 error from spctl and the "does not satisfy its designated Requirement" error from codesign, or if there's still a problem with the patch. I downloaded an older nightly and I can run both codesign and spctl successfully on that...

Comment 26

[Stephen A Pohl [:spohl]]

Michael, your best path forward is to get a hold of a machine with 10.9.5 or above. It will be very difficult or even impossible to verify v2 signatures on any version of OSX that's lower than 10.9.5.

Comment 27

[Steven Michaud [:smichaud] (Retired)]

Actually I think you can usefully run 'codesign -vvvv' on older versions of OS X than 10.9, and get a quick "good" or "bad" result.  So it's still possible to use this as a test on build machines running old versions of OS X.

But you don't get nearly as much information as you need to fix the problems you're still having (as evidenced by Stephen's results in comment #18).

Comment 28

[Stephen A Pohl [:spohl]]

(In reply to Steven Michaud from comment #27)
> Actually I think you can usefully run 'codesign -vvvv' on older versions of
> OS X than 10.9, and get a quick "good" or "bad" result.  So it's still
> possible to use this as a test on build machines running old versions of OS
> X.

Yes, you can *run* codesign on older versions, but not to *verify v2 signatures* (which is necessary to solve this bug): "To test Gatekeeper conformance, you must use OS X 10.9.5 or later."[1]


[1] https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG211

Comment 29

[Steven Michaud [:smichaud] (Retired)]

So Stephen, are you saying there's no point in including 'codesign -vvvv' in the build process as a test that we haven't broken v2 signatures?  Here I assume that we're not going to be able to change the version of OS X on our build machines.

Comment 30

[Stephen A Pohl [:spohl]]

Well, we can include it to make sure we haven't broken the v1 part of the signature (which is still used on OSX lower than 10.9.5). But you're right that we can't add this test to check the v2 signatures unless it's run on 10.9.5 or above. On the other hand, once we run this test on 10.9.5 or above, we don't have to also run it on on lower versions since a v2 signature will never be valid if the v1 aspect of it is broken.

I'm a bit confused by yhe fact that we mention old versions of OSX being used to sign with v2 signatures. AFAIK, this also requires that we run on 10.9.5 or above and I seem to remember that we do just that on trunk. Ben, could you confirm the version of OSX that we use to sign our builds with v2 signatures? Any advice for Michael to test with one of those machines? Thanks.

Comment 31

[[e-mail] (:bhearsum)]

(In reply to Stephen Pohl [:spohl] from comment #30)
> Well, we can include it to make sure we haven't broken the v1 part of the
> signature (which is still used on OSX lower than 10.9.5). But you're right
> that we can't add this test to check the v2 signatures unless it's run on
> 10.9.5 or above. On the other hand, once we run this test on 10.9.5 or
> above, we don't have to also run it on on lower versions since a v2
> signature will never be valid if the v1 aspect of it is broken.
> 
> I'm a bit confused by yhe fact that we mention old versions of OSX being
> used to sign with v2 signatures. AFAIK, this also requires that we run on
> 10.9.5 or above and I seem to remember that we do just that on trunk. Ben,
> could you confirm the version of OSX that we use to sign our builds with v2
> signatures? Any advice for Michael to test with one of those machines?
> Thanks.

We sign on 10.9.5. I'm not sure what you mean by "any advice to test with one of those machines". I certainly can't give anyone else access to them...

Comment 32

[Stephen A Pohl [:spohl]]

(In reply to Ben Hearsum [:bhearsum] from comment #31)
> We sign on 10.9.5. I'm not sure what you mean by "any advice to test with
> one of those machines". I certainly can't give anyone else access to them...

Eh, poorly phrased. I meant: Is there a branch that Michael can commit to that will sign with v2 signatures? I get the impression from comment 16 and comment 25 that we don't seem to do that on all branches, or at least not on ash. Is that true?

Comment 33

[Michael Shal [:mshal]]

It looks like maple is setup correctly, so I'm trying to switch to there. ash (and many others) just use the fake keys. I'll keep you posted!

Comment 34

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #30)

> I'm a bit confused by yhe fact that we mention old versions of OSX
> being used to sign with v2 signatures.

I wasn't saying that.  Comment #25 indicates that at least some of our
build machines run OS X 10.7.2. 

So it depends on where we run our proposed test.  If we run it on the
signing machines we can use the "correct" version of codesign, which
knows about v2 signatures.  But if it's run elsewhere we'll need to
use an older version of codesign, which only knows about v1
signatures.

There are presumably some problems (v2 signature specific ones) that
"old" versions of codesign couldn't detect.  But I expect they'll
detect many of them -- like this bug.

In any case, though, it's probably best to run our 'codesign -vvvv'
test on the actual signing machines.

Comment 35

[[e-mail] (:bhearsum)]

(In reply to Steven Michaud from comment #34)
> (In reply to comment #30)
> 
> > I'm a bit confused by yhe fact that we mention old versions of OSX
> > being used to sign with v2 signatures.
> 
> I wasn't saying that.  Comment #25 indicates that at least some of our
> build machines run OS X 10.7.2. 

Yes, our _build_ machines run 10.7.2. But we don't do any signing there. All of that is done on 10.9.5 (except for esr31).

> So it depends on where we run our proposed test.  If we run it on the
> signing machines we can use the "correct" version of codesign, which
> knows about v2 signatures.  But if it's run elsewhere we'll need to
> use an older version of codesign, which only knows about v1
> signatures.
> 
> There are presumably some problems (v2 signature specific ones) that
> "old" versions of codesign couldn't detect.  But I expect they'll
> detect many of them -- like this bug.
> 
> In any case, though, it's probably best to run our 'codesign -vvvv'
> test on the actual signing machines.

Comment 36

[Stephen A Pohl [:spohl]]

(In reply to Steven Michaud from comment #34)
> In any case, though, it's probably best to run our 'codesign -vvvv'
> test on the actual signing machines.

This wouldn't help. In fact, it may even give us a wrong sense of security. If the v2 signing step succeeds on the 10.9.5 signing server, the package is by definition signed correctly and has a valid signature. Otherwise, the signing step would have failed. The issue here is that we modified the package after the signing step, and after it had left the signing machine. So, the only thing that would help here is to verify the signature once all the build and post-build steps have completed and the .dmg has been posted to our ftp server. Test machines that run 10.9.5 or above come to mind and I seem to recall that we were working on getting those up and running. But I don't know what the status is on those.

Comment 37

[Michael Shal [:mshal]]

Yeah, I really think we'd want to run the check during one of the test suites, so that it's grabbing the final dmg from ftp and checks that. I think if we do it anywhere during the build process, there's a chance that we're not checking the right thing. I'm not sure how we'd properly account for signed vs. unsigned builds, though.

Comment 38

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

Performing the check prior to upload would be a good place to do this.

Comment 39

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #36)

>> In any case, though, it's probably best to run our 'codesign -vvvv'
>> test on the actual signing machines.
>
> If the v2 signing step succeeds on the 10.9.5 signing server, the
> package is by definition signed correctly

Yup, you're right.  Sorry for the confusion.  I now agree that we
shouldn't run 'codesign -vvvv' on the signing machines.

Comment 40

[Chris Pearce [:cpearce (Not reading bugmail)]]

I need to uplift bug 1123990 and bug 1137060 to Beta37 for EME by Monday. Those bugs caused that failure. Just so I understand the issue here, this completely breaks Nightly on MacOSX?

Comment 41

[Stephen A Pohl [:spohl]]

This completely breaks the *signature* on the Firefox.app bundle. Any user with default settings, on 10.9.5 or above, will be unable to open Firefox after a first install. He will either have to change his system settings to make them less secure, or jump through hoops to open Firefox despite the broken signature. To be clear: This does not affect updates to Firefox, but all first-time installs with default system settings on 10.9.5 and above.

Comment 42

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Chris Pearce (:cpearce) from comment #40)
> I need to uplift bug 1123990 and bug 1137060 to Beta37 for EME by Monday.
> Those bugs caused that failure. Just so I understand the issue here, this
> completely breaks Nightly on MacOSX?

Sorry, I meant bug 1123990 needs to be uplift to Beta37.

Comment 43

[Chris Pearce [:cpearce (Not reading bugmail)]]

OK, thanks for clarification. We should fix this ASAP.

Comment 44

[Chris Pearce [:cpearce (Not reading bugmail)]]

I will need to uplift the fix here to Aurora and Beta also.

Comment 45

[Michael Shal [:mshal]]

I think the fix on maple looks good. I asked bhearsum to double-check since he has a 10.9.5+ mac:

bhearsum-04988:Desktop bhearsum$ codesign -vvvv Nightly.app/
--prepared:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/crashreporter.app
--validated:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/crashreporter.app
--prepared:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/firefox-bin
--validated:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/firefox-bin
--prepared:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libfreebl3.dylib
--validated:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libfreebl3.dylib
--prepared:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libmozalloc.dylib
--validated:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libmozalloc.dylib
--prepared:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libmozglue.dylib
--validated:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libmozglue.dylib
--prepared:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libnss3.dylib
--validated:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libnss3.dylib
--prepared:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libnssckbi.dylib
--validated:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libnssckbi.dylib
--prepared:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libnssdbm3.dylib
--validated:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libnssdbm3.dylib
--prepared:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libplugin_child_interpose.dylib
--validated:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libplugin_child_interpose.dylib
--prepared:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libsoftokn3.dylib
--validated:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/libsoftokn3.dylib
--prepared:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/plugin-container.app
--validated:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/plugin-container.app
--prepared:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/updater.app
--validated:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/updater.app
--prepared:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/XUL
--validated:/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/XUL
Nightly.app/: valid on disk
Nightly.app/: satisfies its Designated Requirement
bhearsum-04988:Desktop bhearsum$ spctl -a -v Nightly.app/
Nightly.app/: accepted
source=Developer ID
bhearsum-04988:Desktop bhearsum$ codesign -dv Nightly.app/
Executable=/Users/bhearsum/Desktop/Nightly.app/Contents/MacOS/firefox
Identifier=org.mozilla.nightly
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=403 flags=0x0(none) hashes=13+3 location=embedded
Signature size=8523
Timestamp=Mar 5, 2015, 12:32:39 AM
Info.plist entries=20
TeamIdentifier=43AQ936H96
Sealed Resources version=2 rules=12 files=85
Internal requirements count=1 size=188

Comment 46

[Michael Shal [:mshal]]

Attachment: 0001-Bug-1138535-generate-precomplete-before-signing-for-.patch

Comment 47

[Stephen A Pohl [:spohl]]

The output in comment 45 looks correct! Thanks!

Comment 48

[Michael Shal [:mshal]]

pushed to m-c: https://hg.mozilla.org/mozilla-central/rev/993eb76a8bd6

Comment 49

[Michael Shal [:mshal]]

Builds are rolling in - OSX signatures and the Windows voucher look good as far as I can tell. Can you guys double-check the platforms you're interested in please?

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/03/2015-03-05-07-21-41-mozilla-central/

Comment 50

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Michael Shal [:mshal] from comment #49)
> Builds are rolling in - OSX signatures and the Windows voucher look good as
> far as I can tell. Can you guys double-check the platforms you're interested
> in please?
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/03/2015-03-05-07-
> 21-41-mozilla-central/

Adobe EME works in the Win32 build here.

Comment 51

[Nomis101]

OS X looks good now.

$ check-signature /Volumes/Nightly/FirefoxNightly.app 
(c) 2014 Apple Inc.  All rights reserved.
YES

Comment 52

[Stephen A Pohl [:spohl]]

Tested this build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/03/2015-03-05-07-21-41-mozilla-central/firefox-39.0a1.en-US.mac.dmg

All looks good:
spohl:mozilla-central Stephen$ codesign -vvvv ~/Documents/bugs/bug1138535/FirefoxNightly.app
--prepared:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/crashreporter.app
--validated:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/crashreporter.app
--prepared:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/firefox-bin
--validated:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/firefox-bin
--prepared:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libfreebl3.dylib
--validated:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libfreebl3.dylib
--prepared:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libmozalloc.dylib
--validated:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libmozalloc.dylib
--prepared:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libmozglue.dylib
--validated:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libmozglue.dylib
--prepared:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libnss3.dylib
--validated:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libnss3.dylib
--prepared:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libnssckbi.dylib
--validated:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libnssckbi.dylib
--prepared:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libnssdbm3.dylib
--validated:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libnssdbm3.dylib
--prepared:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libplugin_child_interpose.dylib
--validated:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libplugin_child_interpose.dylib
--prepared:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libsoftokn3.dylib
--validated:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/libsoftokn3.dylib
--prepared:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/plugin-container.app
--validated:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/plugin-container.app
--prepared:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/updater.app
--validated:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/updater.app
--prepared:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/XUL
--validated:/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/XUL
/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app: valid on disk
/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app: satisfies its Designated Requirement
spohl:mozilla-central Stephen$ codesign -dv ~/Documents/bugs/bug1138535/FirefoxNightly.app
Executable=/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app/Contents/MacOS/firefox
Identifier=org.mozilla.nightly
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=403 flags=0x0(none) hashes=13+3 location=embedded
Signature size=8524
Timestamp=Mar 5, 2015, 12:09:42 PM
Info.plist entries=20
TeamIdentifier=43AQ936H96
Sealed Resources version=2 rules=12 files=85
Internal requirements count=1 size=188
spohl:mozilla-central Stephen$ spctl -a -v  ~/Documents/bugs/bug1138535/FirefoxNightly.app
/Users/Stephen/Documents/bugs/bug1138535/FirefoxNightly.app: accepted
source=Developer ID

Comment 53

[Steven Michaud [:smichaud] (Retired)]

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/03/2015-03-05-07-21-41-mozilla-central/firefox-39.0a1.en-US.mac.dmg

I tested this on OS X 10.8.5 and 10.10.2.  I didn't see any problems.

I ran all of the following commands, and also tried double-clicking on a distro newly dragged off the DMG.

spctl -a -v
codesign -vvvv
codesign -dv

Comment 54

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8573252 [details] [diff] [review]
0001-Bug-1138535-generate-precomplete-before-signing-for-.patch

Approval Request Comment
[Feature/regressing bug #]: EME plugin-container voucher
[User impact if declined]: MacOSX build will break when we uplift EME
[Describe test coverage new/current, TreeHerder]: Local testing on multiple platforms
[Risks and why]: Could break the build somehow I guess, it has been tested however.
[String/UUID change made/needed]: None.

Comment 55

[Chris Pearce [:cpearce (Not reading bugmail)]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/33852948b0e8

Comment 56

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

Comment on attachment 8573252 [details] [diff] [review]
0001-Bug-1138535-generate-precomplete-before-signing-for-.patch

Technically 37 is not yet affected but it will be affected shortly. Best to take the fix before the bustage occurs. Beta+ Aurora+

Comment 57

[Chris Pearce [:cpearce (Not reading bugmail)]]

https://hg.mozilla.org/releases/mozilla-beta/rev/68707623b5a3

Comment 58

[[e-mail] (:bhearsum)]

I think this caused bug 1141508.

Comment 59

[Ada [:adalucinet]]

Couldn't fully reproduce this issue with Nightly from 2015-03-02 on both OS X 10.9.5 and 10.10: the window with "FirefoxNightly is damaged and can't be opened. You should move it to the Trash." [1] is displayed, but all the 3 commands return the correct values. 

What am I missing here? Please note that also the "Allow downloaded applications from" pref is set accordingly. 

When double clicking on Fx 37 beta 4 (Build ID: 20150309191715), latest DevEd 38.0a2 (Build ID: 20150309004203) and Nightly 39.0a1 (Build ID: 20150309030224) apps, the window [1] which highlights the broken build is no longer visible.

Comment 60

[Michael Shal [:mshal]]

I'm not sure, maybe :smichaud can provide some insight?

Comment 61

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #59)

Alexandra, I assume you're saying that the 2015-03-02 nightly (the mozilla-central nightly?) is "broken", and FF 37b4 and the 2015-03-09 mozilla-central nightlies are "fixed".  You're just puzzled by what's displayed by the following three commands on the 2015-03-02 nightly.

spctl -a -v
codesign -vvvv
codesign -dv

I just tried these myself on my own copy of the 2015-03-02 mozilla-central nightly, and both "spctl -a -v" and "codesign -vvvv" displayed error messages (containing the phrase "a sealed resource is missing or invalid").  But "codesign -dv" didn't indicate any error -- which may be normal.

I have no idea why you're not seeing errors from "spctl -a -v" and "codesign -vvvv".  So I suggest restarting your computer, deleting the copy of the 2015-03-02 nightly that you've been testing with, and dragging another copy out from the DMG.

Comment 62

[Ada [:adalucinet]]

Finally, I was able to reproduce this issue with Nightly from 2015-03-02: with "codesign -vvvv" and  "spctl -a -v" commands, I get “FirefoxNightly.app: a sealed resource is missing or invalid” is displayed via Terminal. 
Verified as fixed with Fx 37 beta 4 (Build ID: 20150309191715), latest DevEd 38.0a2 (Build ID: 20150311004633) and Nightly 39.0a1 (Build ID: 20150310030235) under OS X 10.9.5.