@Jürg O That's what I have suspected, too - but haven't had the chance to test :)
Here you are: An "XojoScript example project " (just the one from Xojo's examples) with
Same procedure as above ;)
- Download and extract
- edit "
codesign.sh" and replace "Developer ID Application: Juerg Otter" with your own Developer ID name
- change all values in
The codesigned (with hardened runtime) .app will launch, but crash when trying to execute XojoScript. :(
Then change just this Entitlement:<key>com.apple.security.cs.allow-unsigned-executable-memory</key> <true/>
And enjoy your CodeSigned app with hardened runtime that will now happily execute XojoScript.
Can you share these files again? The dropbox links are broken. I am having trouble codesigning an app using XojoScript and I'd like to see what you have done differently.
I'm trying to get one of my existing 3rd party (non-Mac App Store) Mac apps (call it, MyApp.app) ready for the day when notarization is required. (I think my existing 64-bit code signed Mac app is already grandfathered in and won't have trouble running even WITHOUT notarization when Catalina comes out, but I'm trying to get it ready for the day when presumably ALL apps must be notarized.) I'm trying to do this myself (without additional helper apps, just using Terminal) but am having trouble. I hope someone can see what I'm doing wrong.
(sorry to be so verbose, but I do want to make sure I can make plain what I did or didn't do)
I'm running the latest Xojo on a Mac with the latest Mac OS, and trying to notarize a 64-bit mac app. Though I never really use XCode, I've read that you need to have that installed. So, I installed the latest XCode, and on starting it up, it wanted to install additional utilities, so I did that too.
I moved my Xojo-built 64-bit Mac app to its own folder for such testing, and CD'd (change directory) of Terminal to that directory, so I don't think I have to worry about path problems.
1 - The first thing I did in Terminal was to "remove the detritus"...
xattr -cr MyApp.app
Terminal returned without error.
2 - The next thing I did in Terminal was to code sign and harden my app...
codesign -f -s "Developer ID Application: MyCertName" --options runtime MyApp.app
Terminal returned without error.
3 - I've read that you are supposed to remove detritus, code sign and harden your app, but you want to notarize the distribution file. In my case, I've always distributed my apps as a ZIP file. So, I zipped up (using Finder's Compress item in the File Menu) my now detritus-removed, code signed and hardened app...and renamed the resulting zip file as MyApp.zip, as I distribute my program as MyApp.zip, not MyApp.app.zip.
4 - Now, time to notarize it, so in Terminal I typed this (substituting my real companyname, apple email and password of course):
xcrun altool -t osx -f "MyApp.zip" –-primary-bundle-id com.mycompanyname.myapp --notarize-app -u myappleidemailaddress -p myappleidpassword
This time, it objected to my password. I thought it wanted the password that I use with my AppleID all over the place, but it appears it wanted an "app-specific password"...so I went to appleid.apple.com , and got a new app-specific password for "MyApp". (I never actually heard of this, but I think I did it all correctly. I now have an app-specific password for MyApp).
5 - So, I did the above command again, in Terminal, with my new app-specific password...
xcrun altool -t osx -f "MyApp.zip" –-primary-bundle-id com.mycompanyname.myapp --notarize-app -u myappleidemailaddress -p myappspecificpassword
But, this time Terminal returned with a ton of (mostly totally un-understandable information)...but the Summary at the end of the info returned was this:
1 package(s) were not uploaded because they had problems:
To use this application, you must first sign in to iTunes Connect and sign the relevant contracts. (1048)
6 - I'm not exactly sure what contracts it's talking about, but I went to itunesconnect.apple.com and it immediately popped up an agreement which I had to AGREE TO, and I DID. (Was this the contract that needed signing? I don't know?) But, when I tried the xcrun command line again, I got the same error.
BUT...immediately after OK'ing the agreement, Apple reminded me that the my Developer Program Membership has expired (they are correct). So, I am now also wondering if THAT is the cause of the problem I am having?
MyApp.app is distributed as a 3rd party app, it is NOT available on the Mac App Store. Must I still be a current Apple Developer in order to notarize my 3rd party app? (And, in case it matters, I was in the past an official Apple Developer even though my membership has lapsed now, but my certificate which I successfully just used to code sign the app is still valid...and I have a few years still until that expires.)
So, do you think Apple's message to me ("To use this application, you must first sign in to iTunes Connect and sign the relevant contracts. (1048)") is that I must be a current paid-up developer in order to notarize my app? (I'd hope, if so, their message would actually say that!) Or is there another problem you can see that I've been overlooking? What contracts are they talking about? What's the "1048" all about?
Thanks for any help...
Also, make sure you have gone into your itunesconnect account and signed and agreed to everything. I'm pretty sure your account needs to be paid up and current.
codesign --force --options runtime --deep --entitlements /path/to/myapp_entitlements.plist --sign 'Developer ID Application: my company' /path/to/myapp.app
Michael...I'm still learning about entitlements. From other messages, I had thought that an entitlement plist must be added to the app itself, but in your code snippet above, it appears to me that you are just pointing the codesign command to the location of your plist file on your drive just as you point to the location of your app itself. Does this mean my entitlement plist lives on its own, and is NOT built-in to your app, but just needs to be pointed to when you code sign? Thanks.
@Ken W Michael...I'm still learning about entitlements. From other messages, I had thought that an entitlement plist must be added to the app itself, but in your code snippet above, it appears to me that you are just pointing the codesign command to the location of your plist file on your drive just as you point to the location of your app itself. Does this mean my entitlement plist lives on its own, and is NOT built-in to your app, but just needs to be pointed to when you code sign? Thanks.
Correct - entitlments are not part of the app's Info.plist, but rather something that get baked into the app (presumably into the codeSignature resource) during code-signing. You can demonstrate this to yourself easily by running these commands in terminal:
cat /Applications/Chess.app/Contents/Info.plist # look for any com.apple.security.* entitlements - you won't see any codesign -d --entitlements :- /Applications/Chess.app/ # now you will see the com.apple.security.* entitlements
I'm working on coming up with an Entitlement plist for MyApp so that I can properly code sign and notarize MyApp. I've been reviewing this list of possible entitlements:
...and, at first glance, none of them seem particularly appropriate for my app (MyApp doesn't need to connect to the Contact List, or AppleTV, or Game Center, etc, etc.) But, it's been suggested to me one reason my first attempt at notarization failed was that I did not (yet!) have an Entitlement plist during the code signing process. Is there a document somewhere that details what a minimum Entitlement plist for a simple mac app must include? I'm guessing some of the items in the entitlement list URL mentioned just above are required, but it doesn't specify which? Thanks for any thoughts...
These are the entitlements for hardening: https://developer.apple.com/documentation/security/hardened_runtime_entitlements . Add them to a plist with no and you are good to go.
Thanks Beatrix. Sorry to be so dense, but you said "add them to a plist with no and you are good to go." With NO?
Also, I imagine you are suggesting to use an entitlements plist such as the one offered by @Jürg Otter above...such as this:
<?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">
A mostly hypothetical question on notarizing, grandfathering, etc...
Let's say I have an already released Mac 64-bit properly code signed but NOT notarized application called MyApp-v1, that was released early in 2019 (prior to that grandfathering date which I believe was June 1). I've come to understand that this program is somehow grandfathered in, and even though it's NOT notarized, that when Catalina comes out it should be allowed to run just fine. Other programs from new developers or existing developers with new programs will have to be notarized, but my v1 app will be just fine, at least for now. (Or such is my understanding.)
But, now, let's say I want to get ready for the day (maybe when a yet new Mac OS is released) when there's likely no more grandfathering and all apps must be notarized, so I create a MyApp-v2 which is just like v1 but is now notarized...but NOT released to the world.
Does the fact that Apple knows about v2 of MyApp having been notarized (even though not released) affect the current status of those who might still try v1, before v2 is released?
[What I'm worried about is that when I notarize v2 (but don't yet release it to the world), the program was sent to Apple to authenticate it so Apple knows that the program called MyApp has been notarized...so what happens when someone new with Catalina downloads MyApp-v1 now...that was originally grandfathered to be OK, is it still OK? Or, does Apple "phone home" (to its home!) and determine "we know MyApp was notarized (v2), and this v1 app is NOT notarized, so don't allow it to run"...even though v2 is not yet publicly available. I guess I'm asking does Apple (Gatekeeper) just look at the program that is actually being asked to run and look internally at that particular downloaded file to determine whether it's codesigned, notarized, grandfathered...or does it look to its own cloud database of whether that program has been notarized? I'm not really worried, more just curious.]
Thanks for any thoughts...
SUCCESS! At least I hope so. I finally got one of my apps to be successfully notarized by hand (using Terminal). And, I could not have done it without timidly requesting and gleefully accepting (ok, stealing!) suggested Terminal commands and lots of ideas and examples and help from many Xojo forum members...including Tim, Thom, Beatrix, Edwin, Detlef, Jürg, Michael, among many others on this thread and elsewhere. THANK YOU ALL!
A couple things I've learned...
1 - This will be no surprise to many, but it DOES appear that you DO indeed have to be a current Apple Developer in order to properly notarize an app. My Apple Developer status had lapsed. I had thought that since my ability to code sign using my NOT expired Developer certificates was still intact, I might get away without having to renew my Apple Developer status, especially since I distribute my apps as a 3rd party developer, and NOT as part of the official Mac App Store. But, my attempts at notarization failed until I renewed my Apple Developer status, and signed agreements, etc.
2 - Using many of the suggested Terminal commands, I was able to remove the detritus from my app, harden my code, include entitlements and code sign it...but I was surprised that I was NOT immediately able to notarize my app. When I tried to do so, I got an error saying "Is a directory". Rather cryptic. I think what it means is that it sees my application as a folder, with all sorts of various contents. I guess the idea is that you do NOT Notarize an application, but you notarize the distribution file that includes the app. So, instead I tried to Notarize a zipped up version of my app. That seemed to work. I waited for the email from Apple (which I happily received a short time later) saying my program had been notarized, and then I tried to do the Staple magic. And, I found I could NOT Staple my notarization success onto my ZIP file.
On this page:
...I found that:
"You can notarize using a zip file, but it does mean you need to separately staple each of the things in the zip since there is no ticket generated for the zip file itself (it's not something that can be code-signed)."
...so I think (PLEASE correct me if I'm wrong!)...that instead of using the Staple command on the ZIP file, I used the STAPLE command on the contents of my zip file, which is my hardened, code-signed, entitled app. Of course, that makes my existing ZIP file invalid because it does not include the stapled version of my app....so I THINK (???) after Stapling my application, I then ZIP it up again, and THAT's my distribution file.
I guess ZIP files are handled differently than Packages...apparently you can Staple a PKG but not a ZIP...with a ZIP you have to Staple the contents of the zip (my app) and then zip that up again for distribution?
Jeeez, this is sure confusing. Funny thing is, Apple thinks I was successful, but I'm still at a loss to explain everything I did, and if it's really all OK.