3

I am having trouble getting an .app bundle to play nicely with gatekeeper. Running a verify with `codesign looks like it works:

$ codesign -dvvvv --deep Juno.app
Executable=/Applications/Juno.app/Contents/MacOS/Atom
Identifier=com.junolab.juno-lt
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=203 flags=0x0(none) hashes=3+3 location=embedded
Hash type=sha1 size=20
CDHash=ec3531899318562f7460000d9bbc218606026369
Signature size=8536
Authority=Developer ID Application: Julia Computing LLC (A427R7F42H)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Jul 19, 2015, 2:34:57 PM
Info.plist entries=17
TeamIdentifier=A427R7F42H
Sealed Resources version=2 rules=12 files=20822
Nested=Frameworks/ReactiveCocoa.framework
Nested=Frameworks/Atom Framework.framework
Nested=Frameworks/Mantle.framework
Nested=Frameworks/Atom Helper EH.app
Nested=Frameworks/Squirrel.framework
Nested=Frameworks/Atom Helper.app
Nested=Frameworks/Atom Helper NP.app
Internal requirements count=1 size=180

But when I attempt to open it with Finder, gatekeeper fails verification, (Note: this happens on OSX 10.11, but things work just fine on OSX 10.11, see edits below) stating that "the identity of the developer cannot be confirmed." Clicking the "?" button in the gatekeeper popup takes me to the help page titled "The app has been modified or damaged", but I thought codesign should have told me about this when asking it to verify the application. Juno.app is publicly-available, so you guys can take a look at it if you wish, however we have a smaller application signed on the same computer with the same certificate that works just fine, and gives very similar output:

$ codesign -dvvvv --deep Julia-0.4.2.app
Executable=/Applications/Julia-0.4.2.app/Contents/MacOS/Julia
Identifier=org.julialang
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=537 flags=0x0(none) hashes=20+3 location=embedded
Hash type=sha1 size=20
CDHash=44a98280c062d9e1f2277e457dbdf8b67e1d4ffc
Signature size=8536
Authority=Developer ID Application: Julia Computing LLC (A427R7F42H)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Dec 6, 2015, 6:20:37 PM
Info.plist entries=15
TeamIdentifier=A427R7F42H
Sealed Resources version=2 rules=12 files=983
Internal requirements count=1 size=176

That second bundle, Julia-0.4.2.app is available for download as well. Is there some way I can figure out what is going wrong in the Juno.app case so that I can change my signing practices?

EDIT: To address l'L'l's question below, the signing process for Juno.app is performed by this script, the key line being line 28:

codesign -f -s "AFB379C0B4CBD9DB9A762797FC2AB5460A2B0DBE" --deep /Volumes/Juno/Juno.app

The .app contains other resources that may have already been signed (such as the contents of Julia-0.4.2.app, as Juno is a distribution of Julia that contains an IDE builtin) which is why we add the -f flag to codesign.

EDIT 2: l'L'l suggested using spctl to drill down into the issue, which yielded the following:

$ spctl -a Juno.app -vvvvv && echo yes
Juno.app: rejected
source=obsolete resource envelope
origin=Developer ID Application: Julia Computing LLC (A427R7F42H)

This led me to think that perhaps either Juno.app or one of its embedded Frameworks might still have an old version 1 sealed resource envelope, but inspecting each nested resource individually shows that everything has a version 2 envelope.

More intriguingly, it looks like this .app works on OSX 10.10, but not on OSX 10.11.

staticfloat
  • 6,752
  • 4
  • 37
  • 51
  • Which version of OS X are you using? and have you tried using the `spctl` command? – l'L'l Dec 24 '15 at 00:09
  • Excellent questions: 1) It turns out, things work just fine on 10.10, but fail on 10.11. I should note that this file was signed on a machine running 10.9. 2) You just taught me about the `spctl` command, so kudos for that! Inspecting Juno.app yields the error `obsolete resource envelope`, however a quick google about that error doesn't turn up anything interesting, as both `.app` bundles (`Julia-0.4.2.app` and `Juno.app`) have a version 2 sealed resources envelope. – staticfloat Dec 24 '15 at 00:22
  • In the past there where some issues with codesignatures on newer versions of OS X not liking them, and using the `--no-strict` flag sometimes got past the problem until Apple fixed the responsible bug. Using the flag `--resource-rules` (which is not supposed to be used anymore), can cause a similar result as you have, although it doesn't appear you're using it. – l'L'l Dec 24 '15 at 01:09
  • What tool takes the `--no-strict` flag? I don't see it in the man pages for `codesign` or `spctl` on OSX 10.11. – staticfloat Dec 24 '15 at 01:14
  • Add it to your codesign command: `codesign -f --verify --no-strict -vvvv -s "AFB379C0B4CBD9DB9A762797FC2AB5460A2B0DBE" --deep /Volumes/Juno/Juno.app`. I'm pretty sure `--no-strict` is an undocumented option (http://www.opensource.apple.com/source/security_systemkeychain/security_systemkeychain-55202/src/codesign.cpp), unless they took it out and I'm looking at old source. – l'L'l Dec 24 '15 at 01:38
  • This might help http://stackoverflow.com/questions/31709087/failure-digitally-signing-a-mac-app-outside-xcode/32025478#32025478 – adlag Dec 26 '15 at 13:14
  • _> Note: this happens on OSX 10.11, but things work just fine on OSX 10.11..._ -- Is this a typo? Did you mean it works fine in **10.10**? – Jonathan Cross Aug 09 '17 at 20:34

0 Answers0