Notarization fails on MacOS 10.15.3 #4656
Comments
|
I'm having the same issue with both fsevents and Puppeteer. @Ankitr19 did you figure this out? Also, are you using electron-notarize? |
|
Started having the same issue within the last week. For me it's python binaries within app.asar.unpacked. Presumably Apple have changed how they handle notarization? |
|
Notarisation has started failing for us for the same reason. |
|
Ok, I think I narrowed it down. This tweet/video helped me. So it looks like we have to sign each of the individual packages. Now the question is, how do we do that? Any guesses @timfish @dboakes @Ankitr19 ? |
|
It looks like Apple tightened up notarisation on Feb 3rd and warnings became errors. Because warnings are not displayed by For |
|
@timfish I was about to mention electron-builder's option to add additional binaries. I'm not having any luck with it though right now, but I don't think I have the correct paths. I'm using, |
|
I think the signing step occurs before packaging so the path would be more like I've also seen some logic in I'm in the process of running some CI builds with |
|
I'm trying out your suggestions now. I also found this plist param that seems to allow you to skip code signing for "arbitrary" plugins & frameworks. Not entirely sure what that means, but I tried it and it didn't work. |
|
It seems like that might be a runtime option but you never know, maybe the notarisation service pays attention to it? Edit |
|
@timfish I'm not having any luck. I've tried a number of different ways. Are you having any luck? I also noticed that sometimes I get this error and sometimes I don't. I don't even have fsevents in my package.json. I have it in my yarn.lock file for some reason. I tried deleting it, but it still pops up. So obviously when I try adding it to the list of binaries, it says it can't find it. |
|
Nope, no luck working around this for now.
|
|
I tried messing around with afterPack yesterday, ran a function to manually codesign the binaries that are coming causing the issue, but like you said, says the path doesn't exist. I'm all out of ideas as well, but desperate for a fix! |
|
Can you post your electron-builder config part from package.json? Do you build for MAS or without any target specified? |
|
|
Try to unpack all .node executable files and put them in a folder called app.asar.unpacked. You do this by adding: Then the files will be signed and Apple will be able to read the signature. |
|
@kzimny we are using that option and it doesn't appear to help. Our config is: productName: **snip**
appId: **snip**
copyright: Copyright © **snip**
directories:
buildResources: '../build'
output: '../releases'
app: './'
files:
- '**/*'
- '!**/*.{map,dll,so,dylib,cat,inf,sys,exe}'
- '!**/node_modules/**/*.{cc,c,h,obj,pdb,map,lib,tlog,m4,sh,S}'
- '!**/node_modules/**/doc/**'
- '!**/node_modules/**/configure'
afterPack: ../build/afterpack.js
afterSign: ../build/notarize.js
asarUnpack:
- '**/*.node'
win:
**snip**
linux:
**snip**
mac:
hardenedRuntime: true
darkModeSupport: true
extraFiles:
- from: ../build/${os}/${arch}
to: ./resources/
filter:
- '**/*'
target:
- target: dmg
arch:
- x64and we're using the latest Since Apple tightened up their notarisation on 3rd of Feb, we've started getting this error. I've run some builds with |
|
Just for a test, try to remove the target and all excluded files: |
|
Made no difference for me sadly. For me, the binaries that are showing as unsigned, are within the python binary I am already unpacking. |
Build is running in CI. Will let you know how it goes. I could dump the debug output here but it would take me a while to sanitise it! |
|
No, notarisation still fails with the same error with the simplified config. Oh, one point worthy of note is that we don't get any notarisation errors about the other 5 native modules we're using ( I've got to leave my desk for much of the rest of the day but later I'll try a build with |
@dboakes I debugged the CI build yesterday and fsevents doesn't become available until some point after the code signing event and I'm not sure how to remove chokidar from the build as @timfish suggested. I tried manually code signing each binary in travis-ci, but I was unable to add the keychain to "list-keychains". Has anyone tried to codesign manually? |
|
I was able to successfully notarize the app, but I've made so many changes I'm not sure what did it. However, I made the following changes prior to:
package.json entitlements.mac.plist I also just ran a build without asarUnpack (because that causes path issues in my app) and it worked. Update: my app is now not running correctly, because it cannot find Puppeteer. It's included in the package, but it can't reach it. It only seems to work if I add it to extraResources, but then it gives me the issue we've all been dealing with. |
|
Great. Thank you for the information. |
|
Same problem here. I tried It's mostly tripping over |
|
We're using |
|
@timfish I tried using extraFiles instead of extraResources, but my app still can't locate Puppeteer. Can you think of any way around this? Is there a way to add these directories to the system path so that it will look there when being imported? I see the files option has |
|
@twigs67 I've not solved these issues yet for our app yet so I'm not really in a position to advise! Today I'm going to put together a simple reproduction of this issue. This is not being helped by the fact that the npm registry is returning 404 for |
|
What does work is codesign these extra resources manually, something like this: I'm still figuring out if I should write a script that codesigns everything or some other method. But this is a temporary workaround at the very least. |
|
Our signing is all on CI and uses I'd rather get this fixed in |
I use puppeteer whith Chromium.The |
|
Ya, I found a workaround for this as I wasn't able to get the Chromium binary to sign or Apple to take it. @HoldSkill are you able to notarize your app with Chromium? |
|
We resolved the issue, by moving fsevents as a Dev dependency. |
@timfish I did set And I checked the |
|
After read through the source code of electron-osx-sign, I think the problem is that in https://github.com/electron/electron-osx-sign/blob/master/util.js#L227, it rejectes hidden file when walking through Contents folder. case '': // Binary
if (path.basename(filePath)[0] !== '.') {
return getFilePathIfBinaryAsync(filePath)
} // Else reject hidden file
break@develar @sethlu Have any clue that why hidden files are ignored, and why they are still included in |
|
@parachvte It looks like |
|
@timfish Edit: Finally we resolve this issue by moving
|
…ts code sign issue The `fsevents` code sign issue can be seen here: electron-userland/electron-builder#4656
|
I think there are kind of 2 questions brought up here?
The historical/original intention for hidden files is that files that However, this turned out to be overlook as reported in electron/osx-sign#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 Therefore, electron/osx-sign#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 Hope this helps! |
|
To add my two cents.. I'm also experiencing similar issues with deep code signing, this time with 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! |
|
After inspecting I'm seeing entries for the two binaries that apple is complaining about, and I can't see why they are any different than any of the other files... Again, any advice would be awesome! |
|
@eschirtz Sorry about the delay. Can you open an issue at |
@parachvte I'm currently trying the "devDependencies" workaround for |
|
@davidmurdoch I would suggest that you check for an upgrade of The second option is to sign code by calling Also you could consider testing for electron/osx-sign#169 and get it merge into |
|
That actually did work (specifying the binaries). Would you still like me to open an issue in that repo, or is this the expected functionality? Thank you! |
|
@eschirtz I'm glad it worked! This is the expected behavior at the moment before electron/osx-sign#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. |
|
@sethlu Your patch worked. All binaries included in my bundle were signed. |
|
@portah Thanks for testing! electron/osx-sign#169 is just merged and will come with a next release in a few days. |
|
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
|
Solution to use puppeteer and notorize app : |
We are trying to notarize our electron app, but the notarization is not working . It fails with the following issue :-
"issues": [ { "severity": "error", "code": null, "path": "/Contents/Resources/app/node_modules/fsevents/build/Release/.node", "message": "The binary is not signed.", "docUrl": null, "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "/Contents/Resources/app/node_modules/fsevents/build/Release/.node", "message": "The signature does not include a secure timestamp.", "docUrl": null, "architecture": "x86_64" } ]How to resolve this error, and also if we have a method for deep code signing in electron-builder?
The text was updated successfully, but these errors were encountered: