electron-builder: Notarization fails on MacOS 10.15.3

Our signing is all on CI and uses CSC_LINK and CSC_KEY_PASSWORD so it’s going to be a pain to get manual codesign working with that.

I’d rather get this fixed in electron-builder so everyone can benefit from it.

To add my two cents…

I’m also experiencing similar issues with deep code signing, this time with @tensorflow/tfjs-node.

{
severity: "error",
code: null,
path: "Samply_Staging.zip/Samply (Staging).app/Contents/Resources/app.asar.unpacked/node_modules/@tensorflow/tfjs-node/deps/lib/libtensorflow.so",
message: "The binary is not signed.",
docUrl: null,
architecture: "x86_64"
},
{
severity: "error",
code: null,
path: "Samply_Staging.zip/Samply (Staging).app/Contents/Resources/app.asar.unpacked/node_modules/@tensorflow/tfjs-node/deps/lib/libtensorflow.so",
message: "The signature does not include a secure timestamp.",
docUrl: null,
architecture: "x86_64"
},
{
severity: "error",
code: null,
path: "Samply_Staging.zip/Samply (Staging).app/Contents/Resources/app.asar.unpacked/node_modules/@tensorflow/tfjs-node/deps/lib/libtensorflow_framework.so",
message: "The binary is not signed.",
docUrl: null,
architecture: "x86_64"
},
{
severity: "error",
code: null,
path: "Samply_Staging.zip/Samply (Staging).app/Contents/Resources/app.asar.unpacked/node_modules/@tensorflow/tfjs-node/deps/lib/libtensorflow_framework.so",
message: "The signature does not include a secure timestamp.",
docUrl: null,
architecture: "x86_64"
}

I’ve read through this thread a couple times now and can’t quite find “the fix”. Wondering if anyone has any input, or if any help is needed to get this resolved in electron-builder itself.

Thanks!

I think there are kind of 2 questions brought up here?

1. Why are hidden files ignored?
2. Why is the PR https://github.com/electron/electron-osx-sign/pull/169 there?

The historical/original intention for hidden files is that files that .gitignore or .DS_Store can be skipped because they aren’t really executable binaries. Also, funnily they don’t have an extension name because the dot-DS_Store is its name (as far as path.basename() concerns). The actual binary executables also don’t usually have an extension. So the decision was made to skip all the hidden-file-looking files.

However, this turned out to be overlook as reported in https://github.com/electron/electron-osx-sign/issues/168 not because native node modules are ignored and causing code-signing issues, but because the compiled native code modules can simply be named as .node and placed in a dist directory (which was unheard of, at that time, to me). And the current version of electron-osx-sign@0.4.15 still skips the .node file, but you can force-code-sign that file by passing an argument to electron-osx-sign.

Therefore, https://github.com/electron/electron-osx-sign/pull/169 is created so that we check all files if they are binary-looking and we code-sign them all. However, I didn’t have much time to test it, so it’s left as an open PR. Theoretically, it should work. I’ll be curious to hear if this PR works for people so it can be merged to master without causing troubles for existing workflows that people set up.

The _CodeSignature/CodeResources are artifacts from code-signing. And you may find more information about them here: https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html

Hope this helps!

I’ve checked the debug output with DEBUG=electron-osx-sign and it lists all the binaries it’s signing in the app. Everything looks good and there is no erroneous node_modules/fsevents/build/Release/.node entry listed there.

I have no idea how the erroneous entry is ending up in _CodeSignature/CodeResources because that file is written by the codesign tool. 🤷‍♂️

I did this before the building and before the packing. Basically before running any build script.

I don’t know about how node_modules works in this case. I made sure I signed all files that were in the sign logs from Apple. In my case mostly .so and .dylib files. You should check those logs and see which files are the problem.

You can use something like this to sign them: find . -name *.so -exec codesign -s "Company Name" --options=runtime -v {} \;

@eschirtz I’m glad it worked! This is the expected behavior at the moment before https://github.com/electron/electron-osx-sign/pull/169 is merged in. If you’re interested in giving this PR a try perhaps we can make it available to everyone who may get similar issues of binary files missing codesigning.

@eschirtz Sorry about the delay. Can you open an issue at electron-osx-sign and I can take a closer look at the issue? My take on the problem you’re having right now is that the tensorflow shared objects (.so) are not codesigned. If you’re using electron-osx-sign, then you can explicitly provide a list of paths to these binary files to include them during codesigning.

It looks like Apple tightened up notarisation on Feb 3rd and warnings became errors. Because warnings are not displayed by electron-notarize we’re only finding out about them now.

For electron-builder macOS configuration there is a binaries option but looking at it’s usage, these need to be an array of full paths to each binary. electron-builder is already detecting binaries for relocation to app.asar.unpacked so it should ideally add these to the list of files to automatically sign.