Closed Bug 1138535 Opened 6 years ago Closed 6 years ago

V2 signatures broken in current aurora and m-c nightlies

Categories

(Core :: Widget: Cocoa, defect)

38 Branch
All
macOS
defect
Not set
major

Tracking

()

VERIFIED FIXED
Tracking Status
firefox37 + verified
firefox38 + verified
firefox39 + verified

People

(Reporter: smichaud, Assigned: mshal)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

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
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
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
Assignee: nobody → mshal
Blocks: 1123990
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.
Version: unspecified → 38 Branch
Summary: V2 signatures broken in current m-c nightlies → V2 signatures broken in current aurora and m-c nightlies
Tracking for 38 and 39.   When you have a working fix please nominate this for uplift to 38. Thanks!
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?
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.
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.
> over http

over http or ftp (i.e. using a browser)
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.
(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).
(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.
> 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.
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'?
> 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?
Flags: needinfo?(spohl.mozilla.bugs)
(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.
Flags: needinfo?(spohl.mozilla.bugs)
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
(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.
(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
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)
Flags: needinfo?(spohl.mozilla.bugs)
> 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.
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
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.
(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.
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.
Flags: needinfo?(spohl.mozilla.bugs)
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...
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.
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).
(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
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.
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.
Flags: needinfo?(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...
Flags: needinfo?(bhearsum)
(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?
Flags: needinfo?(bhearsum)
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!
Flags: needinfo?(bhearsum)
Depends on: 1139393
(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.
(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.
(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.
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.
Performing the check prior to upload would be a good place to do this.
(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.
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?
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.
(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.
OK, thanks for clarification. We should fix this ASAP.
I will need to uplift the fix here to Aurora and Beta also.
Flags: needinfo?(cpearce)
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
The output in comment 45 looks correct! Thanks!
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/
Flags: needinfo?(smichaud)
(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.
OS X looks good now.

$ check-signature /Volumes/Nightly/FirefoxNightly.app 
(c) 2014 Apple Inc.  All rights reserved.
YES
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
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
Flags: needinfo?(smichaud)
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.
Attachment #8573252 - Flags: approval-mozilla-beta?
Attachment #8573252 - Flags: approval-mozilla-aurora?
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(cpearce)
Resolution: --- → FIXED
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+
Attachment #8573252 - Flags: approval-mozilla-beta?
Attachment #8573252 - Flags: approval-mozilla-beta+
Attachment #8573252 - Flags: approval-mozilla-aurora?
Attachment #8573252 - Flags: approval-mozilla-aurora+
Flags: qe-verify+
I think this caused bug 1141508.
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.
Flags: needinfo?(mshal)
I'm not sure, maybe :smichaud can provide some insight?
Flags: needinfo?(mshal) → needinfo?(smichaud)
(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.
Flags: needinfo?(smichaud)
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.
You need to log in before you can comment on or make changes to this bug.