Error: code object is not signed at all

[zeke]

Hey @sethlu and @malept. I've been working on getting an Electron app into the MAS for a few days. 😅 -- lots of googling and I keep seeing your names pop up on old threads. Thanks for helping people figure this stuff out!

I've got all my signing certs set up:

I'm using this electron-packager incantation to generate a .pkg file and publishing the build to iTunes Connect using Application Loader:

# package for MAS
electron-packager . \
  --platform=mas \
  --arch=x64 \
  --out=dist \
  --prune=true \
  --app-bundle-id=com.sikelianos.zeke.illuminati \
  --app-version="$npm_package_version" \
  --build-version="$npm_package_version_build" \
  --icon=build/icon.icns \
  --osx-sign

# copy provision profile
cp embedded.provisionprofile dist/Illuminati-mas-x64/Illuminati.app/Contents/

# flatten
electron-osx-flat dist/Illuminati-mas-x64/Illuminati.app \
  --pkg dist/illuminati.pkg

The Application Loader step succeeds, but I got an email back:

Invalid Signature - The executable at path Illuminati.app/Contents/Resources/app/node_modules/fsevents/build/Release/.node has following signing error(s): code object is not signed at all In architecture: x86_64 . Refer to the Code Signing and Application Sandboxing Guide at http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html and Technical Note 2206 at https://developer.apple.com/library/mac/technotes/tn2206/_index.html for more information.

Any pointers on what I might be missing?

Ideas:

• Should I be using codesign somewhere too, or is electron-osx-sign all I need?
• Do I need an Info.plistfile with some custom stuff in it? The app doesn't have any special requirements that I know of.

[malept]

This is well outside my area of knowledge, I will let @sethlu handle this.

[sethlu]

Hi @zeke! 😺

I think the issue comes from the native node addons (from the fsevents dependency). Since electron-osx-sign bypasses scanning files that begin with a dot . (typically the hidden files, e.g. .gitignore), it happens to skip code signing this binary file located at Illuminati.app/Contents/Resources/app/node_modules/fsevents/build/Release/.node. While files with names like something.node will be automatically signed.

🏅 I guess it may be good for electron-osx-sign to expect .node as a binary?

A revised workflow for now may be the following:

# package for MAS
electron-packager . \
  --platform=mas \
  --arch=x64 \
  --out=dist \
  --prune=true \
  --app-bundle-id=com.sikelianos.zeke.illuminati \
  --app-version="$npm_package_version" \
  --build-version="$npm_package_version_build" \
  --icon=build/icon.icns \

# copy provision profile (best to do this before code signing)
# you don't really have to manually do this as electron-osx-sign will scan the working directory for a matching provisioning profile and copy it there
cp embedded.provisionprofile dist/Illuminati-mas-x64/Illuminati.app/Contents/

# codesign (explicitly put the binary from fsevents, electron-packager avoids passing additional binaries)
electron-osx-sign dist/Illuminati-mas-x64/Illuminati.app \
  dist/Illuminati-mas-x64/Illuminati.app/Contents/Resources/app/node_modules/fsevents/build/Release/.node

# flatten
electron-osx-flat dist/Illuminati-mas-x64/Illuminati.app \
  --pkg dist/illuminati.pkg

Lemme know if it helps 😄

[sethlu]

Oh, and in response to your ideas: (Forgot to address them in an earlier post)

Should I be using codesign somewhere too, or is electron-osx-sign all I need?

Yep, electron-osx-sign calls codesign itself so we don't have to tweak all those parameters.

Do I need an Info.plist file with some custom stuff in it? The app doesn't have any special requirements that I know of.

electron-osx-sign will at times modify the Info.plist file if it doesn't contain enough information, ElectronTeamID for example. Providing an env variable DEBUG=electron-osx-sign* should have it displaying all those changes and what files are actually signed.

[zeke]

Thanks a ton for this info, @sethlu! You got me over the build hurdle. The build worked, and the app is now in review. 🤞

[zeke]

I ended up working around it by removing the dependency on fsevents which was coming from elemon a file watcher that I should have put in devDependencies anyway, as those get pruned from the build. 👍

[sethlu]

@zeke That's great! 🎉 Hopefully it gets thru the review the first run 😸

[zeke]

Rejected! But it's okay. I think I can address all the issues.

🏅 I guess it may be good for electron-osx-sign to expect .node as a binary?

Do you want to leave this issue open as a reminder to sign .node files?

[malept]

It seems like Electron Packager could build up a list of binary files in the copied app that could be passed to osx-sign.binaries. We'd need that anyway if I want to turn on asar by default (to prevent those files from being in the asar).

[sethlu]

@malept electron-osx-sign also scans for binary files in the application package and individually signs those related files. I guess I can just change the directory scan function to sign all binary-like files?

[SanthoshPixmonks]

Hi @zeke and @sethlu

First of all thank you so much for the solution on skipped fsevents signin and it worked like a charm for me.

Secondly i need my electron application to access bluetooth on mac system for that i have provided bluetooth permission on entitlements plist file and tested it on developer PKG build there it is allowing the access but the same permission is not allowing for production profile signed build it will be a great help if you guys provide any suggestions regarding the same

[sethlu]

Hi @SanthoshPixmonks Sorry about the late reply!

If bluetooth is working in the app bundle signed with the development certificate, it should work nicely after signed with the production certificate I think. Can you provide a bit more details about if you're trying to distribute your app inside/outside the Mac App Store? And what's the test that you conducted that led you to think the bluetooth isn't allowed in the production build?

[sethlu]

Oh, and now that #169 is merged, the original issue should be fixed @zeke

[zeke]

Hey Seth thanks for following up! I'm not able to test this fix right now, and probably won't get back to this any time soon. Feel free to close this issue.

[SanthoshPixmonks]

Hi @sethlu we fixed this issue and successfully launched on app store thanks for your reply.

[sethlu]

@SanthoshPixmonks Congrats! I'm glad to hear that you got the app on the Mac App Store! Closing this issue now 😸