Invalid Signature and signed app isn't running correctly #61
Comments
|
Hi @florian, thanks for filing this issue! From my first observation, the signing identities may be improperly used. Would you run the following script in your Terminal, snd post the output (with sensitive info like team id crossed out) here? Usually $ security find-identity |
|
Thanks for the quick answer! :) You were right about the identities. I had this problem before, and I did import the new certificate. This stopped Application Loader from showing errors, that's why I thought it was fixed. But I also had to remove the old certificate. I just did this, and now I still have the other problem. After signing, executing the .app file doesn't work properly anymore. I tried signing it directly when packaging: Now executing it works fine but after flattening and submitting it to Application Loader, I get this error:
I don't get any errors about identities though, so Do you have any suggestions on what I should try next? |
|
@florian usually an app after sandboxed, though may be made for mas, should still be able to run locally. Would you try npm install -g electron-osx-sign # Please try the latest 0.4.0-beta4
export DEBUG=electron-osx-sign*
electron-osx-sign <app> # This should now display what is being signed and the entitlements embedded within the app |
|
Sure. I've replaced the cert identity and similar stuff with {identity}, {appname} or {myname}. So |
|
Hi @florian, sorry for my late reply... Personally I don't see any issues with your code signing. Following the err message, we probably should then check whether the entitlements signed on the helper apps are correct; would you run the following script on $ codesign --display --entitlements - <helperapp>It should output with |
|
Sorry, I can't execute it right now, I had a hardware problem with my Mac, I'll update this when it's fixed. :) But I don't think the log in combination with codesign is that useful. Just to recap, there are two ways to package/sign with different problems: 1. Only using electron-packager I'm running ˋelectron-packager ... --osx-signˋ. In this case I can run the .app file without problems but the signing doesn't work correctly (according to the mail I get from iTunes). 2. Using electron-packager and electron-osx-sign First I run ˋelectron-packager ...ˋ followed by ˋelectron-osx-sign ...ˋ. This is what I logged in my previous post. Signing works fine here (no complains from iTunes) but running the .app file doesn't work correctly anymore. I'll try ˋcodesignˋ with both approaches when I'm able to in a few days, but the log was only from the packaging way where signing worked anyway (but executing the .app file didn't). |
|
@florian Or you can try use electron-builder – no need to manually flat after package, no need to explicitly specify identity (corresponding will be automatically found). Just
The same way, |
|
@florian Actually, the logging with |
|
Yes, I'll do that! Sorry for the delay. |
|
@florian no worries 😉 keep us updated. |
|
The hardware problem is now fixed and I tried your suggestions. Nothing was logged. So either logging doesn't work like that when signing via electron-packager; or electron-osx-sign is just never called by electron-packager. If I run |
|
@florian you can enable the logs inline; I'm also having the same problem; same e-mail from Apple after submitting the app, and also, same blank screen after signing. I used the script in the instructions for signing.
Not sure what |
|
@florian We should probably code-sign your app by calling If an app fails to launch after code-signed, I should say the result may be normal because some tweaks may be necessary for your app to work as expected. Was your previous test (with |
|
@azer I used to have the exact same problem. Just follow the instructions here. You just need to import Apple's new certificate and remove the old one. @sethlu Updating electron-packager was a good idea. Now both ways to sign/package result in the same problem, and not into two seperate problems. :) I tried signing with My app is similar to apps like Spotlight or Alfred. It only consists of a floating window, and the visibility of that window can be toggled using a hotkey. By default it's not shown. So the window that appears when starting the signed app is definitely unexpected behaviour.
I tested it for both ways (seperate worked, all with electron-packager didn't). I just tried again, after updating electron-packager, and now both ways show that the signing worked for that file. |
|
I thought trying it with a different app would be a good idea, since the app that I want to submit to the MAS has this special window behaviour. However I get the same problem with the other app I tried (which is open source by the way). The only difference is that the size of the unresponsive window is larger (as big as it usually is when the app is started and is working). So I guess that means that it's probably not app specific but has something to do with my dev environment. |
|
Hi @florian, glad to hear that the issues now resolve into one. I'll try packing your open-sourced project tomorrow myself and see if encountering any issues. However, I should now recommend checking in your macOS Console ( |
That was a good suggestion. It's logging I found this electron issue from you regarding this exact error message. :) I tried building with the newest Electron version, assuming that should fix everything since the issue is closed. However I now get these errors in the log: What do you suggest to try next? My other app also has some other sandbox issues, probably because it's running some AppleScripts (e.g. to get the currently selected text). I guess it's better to focus on the simple HN app first and I'll try to take care of the other missing entitlements for the more complex app myself later. :) |
|
@florian From your mentioning $ codesign --display --entitlements - <app>
|
After I found your issue regarding the error message, I upgraded to the newest Electron version (v1.2.5). All of the error message beginning from my last post are from that Electron version. I just triple checked that I'm definitely using that electron version. The packaging process outputs "Packaging app for platform mas x64 using electron v1.2.5 mas-x64 finished!". I also tried logging the electron version when running the packaged and signed app. dialog.showMessageBox(mainWindow, { message: process.versions.electron, buttons: [] });
mainWindow.loadURL(`file://${__dirname}/app/app.html`)This works and shows an alert like window with the content "1.2.5". So I'm definitely using the newest Electron version. Interesting side note:
I wasn't sure if you wanted me to run that on the parent .app file, so I also ran this on the nested .app file that I previously ran codesign on. |
|
@florian 😄 I think I see where the issue is now; in the entitlements signed with your app we should have the We would like to see what similar to above, as you posted earlier #61 (comment). The latest |
Now, the app opens without freezing. However nothing network dependent is being loaded. The data that's coming from an HN API is missing, and the webview doesn't show anything either. I also checked the console: |
|
@florian great it's working! Honestly I don't know why Electron's requesting network access; same happens to me. Anyway, would you create a custom entitlements file with the following? The file extension may be <!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.app-sandbox</key>
<true/>
<key>com.apple.security.network.client</key>
<true/>
</dict>
</plist>And then, code-sign your app again 😄 with the following script: $ electron-osx-sign <app> --entitlements <entitlements>After that the networking issue should be resolved. Let me know how it goes. |
|
Yeah, I just did that and it worked. :) Finally! And after all, there also seems to be a bug in electron-packager, right? The signing is only working when using electron-osx-sign on its own. |
|
@florian I should say extending |
electron-builder uses 0.4.0 and no issues from users, only successful reports that mas target works ;) |
Well in my case it's makes sense, as the app itself does network requests (query HackerNews API, display websites).
Alright, then I'll use that one :) Both work, so I guess it's better to use the more minimal config anyways. Thanks a lot for the great help throughout the last 8 days. I'm super grateful for the support and the project. :) Is it alright if I keep the issue open until I successfully signed (using the correct entitlements) the more complex app? |
|
@florian It's fine to keep this open. 😸 We'll see how much we may help. |
|
I submitted the HN app to the MAS today and everything seemed to work fine. So it looks like the original issue is solved :) @sethlu This isn't regarding electron-osx-sign not working, but I thought I'd ask you since you seem to be very knowledgeable with signing/entitlements. I'll try on StackOverflow if you don't have any advice or no time for this. So feel free to ignore this if you don't want to spend time on it. :) My app executes AppleScript, e.g. to copy the currently selected text to the clipboard. Executing AppleScript in node is only possible by using
I guess the problem is also that running My entitlements: The AppleScripts tell "System Events" to do stuff, thus the scripting target. |
|
Hi @florian glad to know the code-signing worked! 🎊 From my understanding of the entitlements only as I haven't had much experience with AppleScript, I would recommend trying adding the following to your entitlements and then code-signing again. <key>com.apple.security.temporary-exception.files.absolute-path.read-only</key>
<array>
<string>/usr/bin</string>
</array>
On the message given by |
|
Thanks a lot for your reply. :) I tried both suggestions and they didn't work, I still get the same errors. Does a temporary exception mean it's only permitted for a short time after the app starts? Because I'm executing AppleScripts from time to time. A read right (
I think the problem regarding that message is that |
|
@florian "A temporary exception entitlement permits your OS X app to perform certain operations otherwise disallowed by App Sandbox." (ref: https://developer.apple.com/library/mac/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AppSandboxTemporaryExceptionEntitlements.html#//apple_ref/doc/uid/TP40011195-CH5-SW1) It should allow actions throughout your code execution, not limited to how much you access it I think. I was thinking about
I'm not sure why it is complaining this way... If we are executing something from node, we may probably go with I've found this online, and not sure if it may become an alternative to using AppleScript when copying selected text to clipboard: http://www.javascriptkit.com/javatutors/copytoclipboard.shtml |
No, I need it to use system wide, not just in my app. And there's also some other AppleScript stuff, that I definitely can't replace, so I'm stuck with AS.
Yeah, I'm using a helper library for executing AppleScript and parsing the return values, and it's calling
I'd say the difference is that your PHP scripts are not interacting with the UI like AppleScript does, but the |
|
@florian Sorry for my late reply. I thought the JavaScript trick may work around. 😢
I did the following to have my php script running last year without additional entitlements: require("child_process").exec("php -r ...")Not sure if it may be helpful in your app. 😕 Also:
I'm not sure but from some online forums... Moving the app ( |
|
@florian I am currently running into the same exact issue: Did you happen to fix this, and if so, how? Kind of stumped here! |
|
@florian @thomastuts a quick thought from me: Are your AppleScript put in actual files that are called as arguments for |
Nope. I kept trying for another day but then I stopped because university exams were coming up. And it was also really frustrating and not a lot of fun to work on this :P
I only tried directly passing strings to osascript. According to |
|
@sethlu @florian I've been using files instead of inlining the AppleScript code. By the looks of the error, it seems like it's an entitlement issue rather than a code signing one (especially if inlining the code doesn't work either). I'll give it a shot this week and see if that changes anything. Just to be sure, @sethlu, how would I go about signing the file? Would it be the same process that is outlined in the Electron docs? More specifically, something like this:
|
|
@thomastuts I'm not sure about the AppleScript files... However, as codesign works upon file integrity, it is fine I think to apply the same code on them. 😕 Sorry I haven't tried AppleScript myself; not sure what to do upon cases like this. |
|
@sethlu Did you make any progress this week? |
|
@florian I was quite busy during the week... However, I've found some related hints about code signing on AppleScript: https://developer.apple.com/library/mac/releasenotes/AppleScript/RN-AppleScript/RN-10_8/RN-10_8.html I'm trying to get myself familiar to the language so that I could create a test case to test its workability in the coming week. Would you try if the methods in the Apple doc work? |
|
@sethlu Sounds good, I'll take a closer look at your link on the weekend.
You don't really need to learn AppleScript for that :) I've just created a minimal example Electron app that uses AppleScript: https://github.com/florian/electron-sign-applescript To be exact it uses Do you think I should open a new issue for AppleScript signing? It seems that we're cluttering this issue a little bit. |
|
@florian Nice, thanks for pushing a test case! I'll have a look into that tonight. I'm in the middle of trying to include provisioning profiles for MAS signing, eventually after some time of tweaking for a better workflow. |
|
@sethlu Are you sure that I shouldn't open a new issue for this?
Sorry, I meant to at-mention @thomastuts because he said that he'd give it another try that week :)
I tried that today, without much success. However I didn't manage to put the signed AS files into Electron's asar archive and pass them to I'm not sure if it's even possible to get a file path that leads into an asar archive and then give that path to a command line script. But it might be something to try in the future. Other than that I spend most of the day trying to find other ways to solve the AppleScript signing. The previous random number example wasn't that useful. While the console does complain about the random number AppleScript, it allows executing it. Probably because the script couldn't do much harm. In an Apple documentation I read that it's possible to get permission to send events to specific apps, so sending messages to System Events should be possible. The only thing that wouldn't work is getting permission to send events to all possible apps (which isn't really necessary, because System Events handles a lot of stuff).
Does provisioning profiles mean entitlement files? |
Actually I'm also thinking about opening another thread for this issue 😹 The AppleScript may be addressed under a better title. (A closed issue like this is quite hard to search for in GitHub directly.) On packaging with
Provisioning profiles are quite different from entitlement files in the way that they bear signing identities and mark machines UDID for development/testing. It describes a development team in short. They were discussed slightly in #59 and were proved useful avoiding some Sandbox issues with application group (recommended starting Electron v1.1.1) to allow better threading of system and graphics. Performance/graphic glitches were observed prior to the introduction of application group. I have drafted a workflow for manually embedding provisioning profiles in https://github.com/sethlu/electron-distribution-guide, following which a branch of |
|
@florian @sethlu Sorry for the late reply! I've been doing some testing and concluded that running the AppleScript itself is not the problem. In a signed app, I can run a debug The privilege error only occurs when you start scripting other applications (in our case, that's Keynote). Apple has some documentation on the entitlements you need. You can find out the access groups by using |
Sorry in advance if I overlooked something obvious. I've tried to make this work for some hours now, and I'm out of ideas.
I developed a Mac app using electron and everything works as expected after packaging with electron-packager. Now I want to submit the app to the mac app store.
After packaging I'm signing the app using
electron-osx-sign --identity="xyz" name.appand then I'm flattening it withelectron-osx-flat --identity="xyz" name.app(it doesn't work without me specifying the identity, although this is the first app that I'm signing) and submit the created .pkg file to Application Loader.The first problem is that the signed .app file doesn't work correctly anymore. If I try to execute it, the app starts with a window it usually doesn't have and doesn't respond at all:
I'm not sure if I'm still supposed to be able to execute apps that were signed for the MAS, so maybe this is just expected behaviour? Otherwise this may hint to something going wrong when signing.
The second problem: Application Loader accepts the .pkg file without any errors and uploads it to iTunes, but afterwards I get an email stating this error:
I do have those two certs and when signing/flattening several certs were requested, so I'm not sure what's going wrong. I'm not calling
productbuildmyself,electron-osx-flatis doing that right?Do you guys have any idea what I might do wrong?
(The
xyzin--identity="xyz"from above is the string in the parentheses of"3rd Party Mac Developer Installer: myname (xyz)".)The text was updated successfully, but these errors were encountered: