osx-sign: Invalid Signature and signed app isn't running correctly

Sorry in advance if I overlooked something obvious. I’ve tried to make this work for some hours now, and I’m out of ideas.

I developed a Mac app using electron and everything works as expected after packaging with electron-packager. Now I want to submit the app to the mac app store.

After packaging I’m signing the app using electron-osx-sign --identity="xyz" name.app and then I’m flattening it with electron-osx-flat --identity="xyz" name.app (it doesn’t work without me specifying the identity, although this is the first app that I’m signing) and submit the created .pkg file to Application Loader.

The first problem is that the signed .app file doesn’t work correctly anymore. If I try to execute it, the app starts with a window it usually doesn’t have and doesn’t respond at all:

I’m not sure if I’m still supposed to be able to execute apps that were signed for the MAS, so maybe this is just expected behaviour? Otherwise this may hint to something going wrong when signing.

The second problem: Application Loader accepts the .pkg file without any errors and uploads it to iTunes, but afterwards I get an email stating this error:

Invalid Signature - This error occurs when you have signed your app’s installer incorrectly. There are two certs required for this process: the “3rd Party Mac Developer Application” cert and the “3rd Party Mac Developer Installer” cert. When signing your package, you need to ensure that you are using the Installer cert to sign your package. Ensure that you are specifying this cert when submitting your app via the Xcode Organizer or when running productbuild from the command line.

I do have those two certs and when signing/flattening several certs were requested, so I’m not sure what’s going wrong. I’m not calling productbuild myself, electron-osx-flat is doing that right?

Do you guys have any idea what I might do wrong?

(The xyz in --identity="xyz" from above is the string in the parentheses of "3rd Party Mac Developer Installer: myname (xyz)".)

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 46 (23 by maintainers)

Most upvoted comments

Yeah, I just did that and it worked. 😃 Finally! However I wasn’t sure what default entitlements from this repo I should extend, default.entitlements.mas.inherit.plist or default.entitlements.mas.plist?

And after all, there also seems to be a bug in electron-packager, right? The signing is only working when using electron-osx-sign on its own.

florian on Jun 27, 2016

I submitted the HN app to the MAS today and everything seemed to work fine. So it looks like the original issue is solved 😃

@sethlu This isn’t regarding electron-osx-sign not working, but I thought I’d ask you since you seem to be very knowledgeable with signing/entitlements. I’ll try on StackOverflow if you don’t have any advice or no time for this. So feel free to ignore this if you don’t want to spend time on it. 😃

My app executes AppleScript, e.g. to copy the currently selected text to the clipboard. Executing AppleScript in node is only possible by using /usr/bin/osascript. I’ve spent quite some time trying different entitlements, but I found none that stop this console errors:

03.07.16 21:06:06,358 appleeventsd[61]: rdar://problem/11489077 A sandboxed application with pid 30507, “osascript” checked in with appleeventsd, but its code signature could not be read and validated by appleeventsd, and so it cannot receive AppleEvents targeted by name, bundle id, or signature. Install the application in /Applications/ or some other world readable location to resolve this issue. Error=ERROR: #100001 { “NSDescription”=“SecCodeCopyGuestWithAttributes() returned 100001, -.” } (handleMessage()/appleEventsD.cp #2098) com.apple.root.default-qos 03.07.16 21:06:06,403 sandboxd[146]: ([61]) appleeventsd(61) deny file-read-data /usr/bin 03.07.16 21:06:06,434 sandboxd[146]: ([61]) appleeventsd(61) deny file-read-metadata /usr/bin 03.07.16 21:06:06,465 sandboxd[146]: ([61]) appleeventsd(61) deny file-read-data /usr/bin/osascript

I guess the problem is also that running /usr/bin/osascript spawns a new process that doesn’t have the same entitlements.

My entitlements:

    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.network.client</key>
    <true/>
    <key>com.apple.security.scripting-targets</key>
    <dict>
        <key>com.apple.systemevents</key>
        <true/>
    </dict>

The AppleScripts tell “System Events” to do stuff, thus the scripting target.

florian on Jul 3, 2016

Honestly I don’t know why Electron’s requesting network access; same happens to me.

Well in my case it’s makes sense, as the app itself does network requests (query HackerNews API, display websites).

I should say extending default.entitlements.mas.plist

Alright, then I’ll use that one 😃 Both work, so I guess it’s better to use the more minimal config anyways.

Thanks a lot for the great help throughout the last 8 days. I’m super grateful for the support and the project. 😃

Is it alright if I keep the issue open until I successfully signed (using the correct entitlements) the more complex app?

florian on Jun 27, 2016

electron-osx-sign@0.4.0 is still in beta so we should probably wait until it gets stable

electron-builder uses 0.4.0 and no issues from users, only successful reports that mas target works 😉

develar on Jun 27, 2016

However, I should now recommend checking in your macOS Console (/Applications/Utilities/Console.app) if there are any logs while launching your app. For the blank screen appears, it should say something related to it.

That was a good suggestion. It’s logging 26.06.16 20:48:58,810 sandboxd[151]: ([13399]) HackerNews Helpe(13399) deny mach-lookup org.chromium.Chromium.rohitfork.13398 for my HN app.

I found this electron issue from you regarding this exact error message. 😃

I tried building with the newest Electron version, assuming that should fix everything since the issue is closed. However I now get these errors in the log:

26.06.16 21:40:35,000 kernel[0]: Sandbox: HackerNews Helpe(14575) deny(1) mach-lookup com.electron.hackernews.rohitfork.14574
…
26.06.16 21:40:45,000 kernel[0]: Sandbox: HackerNews(14574) deny(1) file-read-data /Users/florian/Library/Preferences/com.apple.symbolichotkeys.plist

What do you suggest to try next?

My other app also has some other sandbox issues, probably because it’s running some AppleScripts (e.g. to get the currently selected text). I guess it’s better to focus on the simple HN app first and I’ll try to take care of the other missing entitlements for the more complex app myself later. 😃

florian on Jun 26, 2016

Sorry, I can’t execute it right now, I had a hardware problem with my Mac, I’ll update this when it’s fixed. 😃

But I don’t think the log in combination with codesign is that useful. Just to recap, there are two ways to package/sign with different problems:

1. Only using electron-packager

I’m running ˋelectron-packager … --osx-signˋ. In this case I can run the .app file without problems but the signing doesn’t work correctly (according to the mail I get from iTunes). Is there a way I can log electron-osx-signs behaviour when using electron-packager?

2. Using electron-packager and electron-osx-sign

First I run ˋelectron-packager …ˋ followed by ˋelectron-osx-sign …ˋ. This is what I logged in my previous post. Signing works fine here (no complains from iTunes) but running the .app file doesn’t work correctly anymore.

I’ll try ˋcodesignˋ with both approaches when I’m able to in a few days, but the log was only from the packaging way where signing worked anyway (but executing the .app file didn’t).

florian on Jun 22, 2016