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

Executables within app.asar.unpacked are not being signed correctly in OSX 10.14.5 #3940

Closed
dboakes opened this issue Jun 5, 2019 · 12 comments

Comments

@dboakes
Copy link

dboakes commented Jun 5, 2019

  • Version: 20.43.0

  • Electron Updater Version: 4.0.6

  • Target: Mac OSX 10.14.5

I have implemented the fix mentioned in issue #3828, also outlined here.

However, this isn't working for other binaries found within app.asar.unpacked. Before OSX 10.14.15, I had included a python binary which I had packed via pyinstaller, and this was then automatically signed by Electron Builder.

The error output states "Code signature found in [FILE_PATH]_ not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed."

I can see in the Contents folder of the app, that the CodeResources file contains keys for all the python binaries, but they don't seem to be recognised.

I have tried signing the files manually with codesign, which allowed the app to work on my mac, but when trying to open the app on another mac, it would get an error, as the package had been amended after being signed.

@dboakes dboakes changed the title Executables within app.asar.unpacked are not being signed correctly in OSX 10.14.15 Executables within app.asar.unpacked are not being signed correctly in OSX 10.14.5 Jun 5, 2019
@yoannsark
Copy link

I had the same problem, that was fixed by adding com.apple.security.cs.disable-library-validation to plist file.

My electron builder configuration :

    "mac": {
      "hardenedRuntime": true,
      "gatekeeperAssess": false,
      "entitlements": "./mac_build_files/entitlements.mac.inherit.plist",
      "entitlementsInherit": "./mac_build_files/entitlements.mac.inherit.plist",
      "target": ["dmg"]
    },

My entitlements.mac.inherit.plist :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
    <key>com.apple.security.cs.allow-dyld-environment-variables</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
  </dict>
</plist>

@dboakes
Copy link
Author

dboakes commented Jun 24, 2019

Only just seen your comment. Updating the plist with your suggestions worked perfectly! Amazing cheers mate.

@julienma
Copy link

I had the same issue (with native node extension Keytar).
I don't know what are the pros/cons of adding too much, so I tried to add the minimum required to get it working, and this is what I ended up with:

  <dict>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
  </dict>

@jwheare
Copy link
Contributor

jwheare commented Jul 18, 2019

I can confirm the same as @julienma, I didn't need the com.apple.security.cs.allow-dyld-environment-variables entitlement to fix this. Not sure if there are cases where it is needed, @yoannsark does your case work if you remove it? If so, might be worth removing it from the defaults added in 519bb47

@yoannsark
Copy link

Yes, com.apple.security.cs.allow-dyld-environment-variables is not necessary
The fix is just com.apple.security.cs.disable-library-validation

@dannypaz
Copy link

dannypaz commented Sep 4, 2019

@Kilian you might need to update your article to include this, I was having an issue with entitlements following the guide (this is not to say that your guide is unappreciated)

lidel added a commit to ipfs/ipfs-desktop that referenced this issue Mar 9, 2020
lidel added a commit to ipfs/ipfs-desktop that referenced this issue Mar 10, 2020
lidel added a commit to ipfs/ipfs-desktop that referenced this issue Mar 10, 2020
* chore: macOS notarizing

This adds scripts that run electron-notarize
as additional manual or build steps on darvin runtime, loosly following
https://kilianvalkhof.com/2019/electron/notarizing-your-electron-application/

Context:
#1211

entitlements should enable us to pass process with go-ipfs binary
electron-userland/electron-builder#3940 (comment)

notarize-cli.js uses electron-notarize-dmg,
works like electron-notarize but supports DMG without
stapling (which is what we want for now)

License: MIT
Signed-off-by: Marcin Rataj <[email protected]>
@LackoDan
Copy link

LackoDan commented Jul 1, 2020

Adding the entitlement worked for me as well. Thanks everyone!

@Kilian I also came across this issue after following your excellent guide. Thanks for providing clear instructions on how to sign and notarize for Mac OS! (Weird that something like this is still not included in the official documentation.) Just wanted to remind you of @dannypaz's request - I think it would really prevent a lot of wasted time.

@diksha11s
Copy link

I created my package using https://github.com/munki/munki-pkg. I signed and notarised my executables after which installer stopped working. I do not have any "entitlements.mac.inherit.plist". With munkipkg only build-info.plist is produced. I need to add it there? I am pretty new to all of this, figuring out how to fix this.

Sayuki0x added a commit to vex-chat/vex-desktop that referenced this issue Jan 8, 2021
barmac added a commit to camunda/camunda-modeler that referenced this issue Feb 25, 2021
barmac added a commit to camunda/camunda-modeler that referenced this issue Feb 25, 2021
barmac added a commit to camunda/camunda-modeler that referenced this issue Feb 25, 2021
barmac added a commit to camunda/camunda-modeler that referenced this issue Feb 25, 2021
barmac added a commit to camunda/camunda-modeler that referenced this issue Feb 26, 2021
@toffyui
Copy link

toffyui commented Aug 17, 2021

Hey I think if you use BigSur, now you should not use com.apple.security.cs.disable-library-validation.
Because of com.apple.security.cs.disable-library-validation, yes you can build and use unsigned library, but another problem will occur: YOUR APP cannot be opened because it is from an unidentified developer even though you do code-sign correctly.
If you use Catalina, no problem but for your customers it's better not to use this solution.

So, I strongly recommend you to use asarUnpack option.
in package.json, you can write like this. (for example, I used node-mac-permissions and keytar)

"build": {
    "asarUnpack": [
       "node_modules/node-mac-permissions",
       "node_modules/keytar"
    ]
}

@tobiasmuecksch
Copy link

@yuikoito Will this also work for native addons like sqlite3?

@toffyui
Copy link

toffyui commented Oct 5, 2022

@tobiasmuecksch Sorry I didn't try native addons..

@panther7
Copy link
Contributor

panther7 commented Feb 7, 2023

@tobiasmuecksch Yes, it's works.

only for MacOS (all node modules)

"build": {
  "mac": {
    "asarUnpack": "node_modules/**/*.node"
  }
}

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