Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"code object is not signed at all In subcomponent" error after High Sierra update. #155

Open
yoannmoinet opened this issue Nov 8, 2017 · 12 comments

Comments

@yoannmoinet
Copy link

Hi there,
I have updated my system to High Sierra a few days ago, and now I can't sign my apps anymore.

I've tested everything I could think off:

  • updated certs
  • updated provisioning
  • updated dependencies
  • delete everything and pull from scratch
  • I will try to get a Sierra MBP to test the signing, to be sure it's really coming from HighSierra.

Always get the same error on the three Electron helpers.

  • MyApp.app/Contents/Frameworks/MyApp Helper EH.app/Contents/MacOS/MyApp Helper EH
  • MyApp.app/Contents/Frameworks/MyApp Helper NP.app/Contents/MacOS/MyApp Helper NP
  • MyApp.app/Contents/Frameworks/MyApp Helper.app/Contents/MacOS/MyApp Helper

I don't know what to do anymore.

Here's the full error:

../release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper.app/: code object is not signed at all
In subcomponent: /Users/yoann/dev/myapp/release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper.app/Contents/MacOS/MyApp Helper

I've used a simple codesign script to pinpoint the problem :

#!/bin/bash

# Name of your app.
APP="MyApp"
# The path of your app to sign.
APP_PATH="../release/MyApp-mas-x64/MyApp.app"
# The path to the location you want to put the signed package.
RESULT_PATH="../release/$APP.pkg"
# The name of certificates you requested.
APP_KEY="3rd Party Mac Developer Application: Yoann MOINET (REDACTED)"
INSTALLER_KEY="3rd Party Mac Developer Installer: Yoann MOINET (REDACTED)"

FRAMEWORKS_PATH="$APP_PATH/Contents/Frameworks"

codesign -s "$APP_KEY" -f --entitlements "../build/child.plist" "$FRAMEWORKS_PATH/Electron Framework.framework/Versions/A/Electron Framework"
codesign -s "$APP_KEY" -f --entitlements "../build/child.plist" "$FRAMEWORKS_PATH/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib"
codesign -s "$APP_KEY" -f --entitlements "../build/child.plist" "$FRAMEWORKS_PATH/Electron Framework.framework/Versions/A/Libraries/libnode.dylib"
codesign -s "$APP_KEY" -f --entitlements "../build/child.plist" "$FRAMEWORKS_PATH/Electron Framework.framework"
codesign -s "$APP_KEY" -f --entitlements "../build/child.plist" "$FRAMEWORKS_PATH/$APP Helper.app/Contents/MacOS/$APP Helper"
codesign -s "$APP_KEY" -f --entitlements "../build/child.plist" "$FRAMEWORKS_PATH/$APP Helper.app/"
codesign -s "$APP_KEY" -f --entitlements "../build/child.plist" "$FRAMEWORKS_PATH/$APP Helper EH.app/Contents/MacOS/$APP Helper EH"
codesign -s "$APP_KEY" -f --entitlements "../build/child.plist" "$FRAMEWORKS_PATH/$APP Helper EH.app/"
codesign -s "$APP_KEY" -f --entitlements "../build/child.plist" "$FRAMEWORKS_PATH/$APP Helper NP.app/Contents/MacOS/$APP Helper NP"
codesign -s "$APP_KEY" -f --entitlements "../build/child.plist" "$FRAMEWORKS_PATH/$APP Helper NP.app/"
codesign -s "$APP_KEY" -f --entitlements "../build/child.plist" "$APP_PATH/Contents/MacOS/$APP"
codesign -s "$APP_KEY" -f --entitlements "../build/parent.plist" "$APP_PATH"

But the output is as follow:

../release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework: replacing existing signature
../release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib: replacing existing signature
../release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib: replacing existing signature
../release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/Electron Framework.framework: replacing existing signature
../release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper.app/Contents/MacOS/MyApp Helper: code object is not signed at all
In subcomponent: /Users/yoann/dev/myapp/release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper.app/Contents/MacOS/MyApp Helper
../release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper.app/: code object is not signed at all
In subcomponent: /Users/yoann/dev/myapp/release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper.app/Contents/MacOS/MyApp Helper
../release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper EH.app/Contents/MacOS/MyApp Helper EH: code object is not signed at all
In subcomponent: /Users/yoann/dev/myapp/release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper EH.app/Contents/MacOS/MyApp Helper EH
../release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper EH.app/: code object is not signed at all
In subcomponent: /Users/yoann/dev/myapp/release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper EH.app/Contents/MacOS/MyApp Helper EH
../release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper NP.app/Contents/MacOS/MyApp Helper NP: code object is not signed at all
In subcomponent: /Users/yoann/dev/myapp/release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper NP.app/Contents/MacOS/MyApp Helper NP
../release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper NP.app/: code object is not signed at all
In subcomponent: /Users/yoann/dev/myapp/release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper NP.app/Contents/MacOS/MyApp Helper NP
../release/MyApp-mas-x64/MyApp.app/Contents/MacOS/MyApp: code object is not signed at all
In subcomponent: /Users/yoann/dev/myapp/release/MyApp-mas-x64/MyApp.app/Contents/MacOS/MyApp
../release/MyApp-mas-x64/MyApp.app: code object is not signed at all
In subcomponent: /Users/yoann/dev/myapp/release/MyApp-mas-x64/MyApp.app/Contents/MacOS/MyApp

Please note that my app has a ê in its name, if that could be relevent.
But I never had any issue with this before High Sierra update.

Thank you for your help.

@sethlu
Copy link
Contributor

sethlu commented Nov 8, 2017

Hi @yoannmoinet I'm updating my laptop to High Sierra tonight so'll be able to try testing out the issue. Would you provide a little more details about which Electron version you are using?

And it's a little weird that even a binary executable cannot be successfully signed. Did you manage to manually have this file individually signed?

../release/MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper.app/Contents/MacOS/MyApp Helper: code object is not signed at all

Also, I'm wondering if it's an older incompatible version of codesign that's used? Are your Xcode command line tools updated to the latest?

@yoannmoinet
Copy link
Author

yoannmoinet commented Nov 8, 2017

Hi @sethlu thank you for your fast answer.

I've tested both with electron 1.7.* and 1.8.1.

Tried to sign single executable as well, exact same result.

Right after the High Sierra update, I've launched XCode and it asked to install command line tools, which I did. So I guess I have the latest version there as well. I also had to reconnect my Apple Account in XCode, if it has any relevance at all.

@sethlu
Copy link
Contributor

sethlu commented Nov 8, 2017

@yoannmoinet Mhm. I was just looking at electron-userland/electron-builder#2125 and that seems slightly related. Have you tried to package an app without non-ASCII characters and codesign that plain version?


Related? https://eclecticlight.co/2017/07/05/high-sierra-and-filenames-apple-is-relenting/

@yoannmoinet
Copy link
Author

yoannmoinet commented Nov 8, 2017

I'll try that later today as well, right after the Sierra test.
Will report back.

That would be weird that the non-ASCII characters is now an issue, since my app is signed and on the AppStore for several months now. I'll test it nonetheless.

@sethlu
Copy link
Contributor

sethlu commented Nov 8, 2017

@yoannmoinet Great! I'll try to run a basic electron-quick-start packaging & signing and see it that works after the macOS version bump.

@yoannmoinet
Copy link
Author

Removed the ê from the previous packaged application, and it signed correctly.

I think your link about the new file system is what's happening... god dammit Apple, what did you do?

I'll check a bit further this direction then.
This is so much trouble, I can't even understand how they overlooked this.

@yoannmoinet
Copy link
Author

yoannmoinet commented Nov 8, 2017

Got it to work.

It was indeed ê.
I copied another ê displayed in the Finder, and used it in my app.

Apparently, ê isn't supported by codesign, but is.
Should have figured this out 🙃

It is now working.

@sethlu
Copy link
Contributor

sethlu commented Nov 9, 2017

@yoannmoinet I was able to reproduce the error with a ć as well. (I will post a link to a simplified version very soon.) Probably with the current set up--High Sierra--it's better to sign with ASCII compatible path names, though I think a build environment in Sierra should support distribution of signed apps in High Sierra?

@sethlu
Copy link
Contributor

sethlu commented Nov 9, 2017

@yoannmoinet I've posted the reproduction here: reproduce-155. I think the issue boils down to the unicode string passed into codesign: The failing case with ê is <c3 aa>, whereas the working one is <65 cc 82> (more like combining a few emojis to a symbol.) So far I believe the latter is better supported in APFS. So by copying the name directly from Finder and pasting it as the app name the issue is resolved.

I think we can introduce a patch to address the unicode encoding issue?

Some insights from an Apple discussion: https://discussions.apple.com/thread/4714392


Amend: Also some insights here: https://eclecticlight.co/2017/04/06/apfs-is-currently-unusable-with-most-non-english-languages/

@yoannmoinet
Copy link
Author

@sethlu awesome stuff.

Copying from the Finder is indeed what I did to fix my issue.
But how do you see a patch for this?
I'm not that fluent in encoding matters unfortunately 😞 , at least for now.

Thank you very much for your support though, without your link to the eclecticlight post, I wouldn't have found the solution.

Should we re-open the issue?

@sethlu
Copy link
Contributor

sethlu commented Nov 10, 2017

@yoannmoinet No worries! 👍 And I'm not very sure... But I'll find some time to try to devise a workaround for unicode normalization. Let's keep the issue open for some time until a fix is available.

@sr258
Copy link

sr258 commented Oct 11, 2021

You're a lifesafer! Copying the characters from finder solved the same issue for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants