Codesigning and notarizing your LC standalone for distribution outside the Mac Appstore -
This tutorial describes the necessary tasks to get your app code signed and notarized for distribution outside the Mac Appstore.
- Codesigning your app (including some necessary preparations)
- creating and code signing package installer (.pkg)
- creating and code signing a DMG using DropDMG or hdiutil (optional)
- Notarizing and stapling your app, pkg or dmg
Most is done with shell commands.
Files
An overview how to notarize an app:
This lesson as PDF:
A Livecode stack which should do all needed steps for you. See chapter 10.
It is strongly recommended that you read at least chapter 9 before using the stack.
1. Prerequisites
Please make sure that you fullfil the following requirements before you continue
1.1. Apple ID
If you do not already own an Apple ID, you can create one here: https://appleid.apple.com
1.2. Enable two factor authentication for your Apple ID
You need to have 2 factor authentication (2FA) enabled for your Apple ID. You can do this in your Apple ID Account at https://appleid.apple.com
1.3. App-specific password
You´ll need an app-specific password. You can create one at https://appleid.apple.com
There is a blue link Generate Password...
In my given examples below I will use tic-tac-toe in places of app-specific password.
1.4. Developer ID
You´ll need a Developer ID. Therefore you´ll need to be a member in the Apple Developer Programm. Join here https://developer.apple.com
In my examples i use [email protected] as Developer ID.
1.5. Creating Developer ID Application and Installer certificates
1.5.1. Create Developer ID Application certificate using Developer account
The certificate types for distribution outside the Apple "App Store” for Mac OS are:
- Developer ID Application <- this is needed for signing .app and .dmg
This certificate is used to code sign your app for distribution outside of the Mac App Store.
- Developer ID Installer <- this is needed for signing package installers (.pkg)
This certificate is used to sign your app’s "Installer Package" for distribution outside of the Mac App Store.
Note: If you are not distributing “Installer Packages”, the only certificate you need is “Developer ID Application”
You can create the certificates either in your Apple Developer account, see screenshot.
After you´ve created the certificate you can download the certificate. You can now add it to your Keychain by double clicking on the downloaded file.
1.5.2. CreateDeveloper ID Application certificate using Xcode
or directly in Xcode -> Preferences -> Accounts
1. press Manage Certificates -> a window pops up
2. press + sign
3. select the certificate you want to create
The certificate will automatically added to the Keychain.
1.5.3. Create a Developer ID Installer certificate
You'll need a Developer ID Installer certificate, if you plan to distribute your app as a package installer.
To create that certificate, follow steps 1.5.1 and 1.5.2, but select Developer ID Installer instead of Developer ID Application
1.6. Xcode 10.2
For this tutorial Xcode 10.2.1 command line tools were used for code signing, notarzing and stapling. Xcode 11 should work as well.
1.7. Standalone with correct bundle identifier
The bundle identifier is set in the standalone settings -> Mac tab
You should use the following form for the bundle identifier com.<YourCompany>.YourAppname
or if you own a domain use <YourDomain>.YourAppname e.g. tk.rebbe.dropuploadx
Note: In my given examples below I will use tk.rebbe.dropuploadx in places of bundle identifier.
1.8. Some notes about how to add additional files or folders
It is important or better said mandatory that additional files and folders are copied to the standalone using the Copy Files tab in the standalone settings. Please do not add those files or folders to the app bundle manually after standalone creation.
You have to use the Copy Files tab in the standalone settings!
2. Preparations for code signing
Before code signing an LC app, some changes must be done to the standalone (bundle)
2.1. Removing the extended attributes
Run the following command in terminal
sudo xattr -cr "<path_to_app_bundle>"Replace <path_to_app_bundle> with the path to your standalone.
Put the path in quotes, this would avoid problems when the path contains spaces.
Or just drag and drop the standalone on terminal window. This will take care of spaces etc. as well
Example
sudo xattr -cr "/Users/matthias/Downloads/DropUpload/DropUpload.app"To make sure all attributes are removed, run the following command in terminal
sudo xattr -lr "<path_to_app_bundle>"Replace <path_to_app_bundle> with the path to your standalone.
Put the path in quotes, this would avoid problems when the path contains spaces.
Or just drag and drop the standalone on terminal window. This will take care of spaces etc. as well
Example
sudo xattr -lr "/Users/matthias/Downloads/DropUpload/DropUpload.app"If you see your prompt and no other output, then all is fine and you can continue
2.2. Renaming the localization folders
Right click on your app bundle and select "show package content".
open the folder Contens/Resources
you'll see .lproj folders. The names of all .lproj folders have to be iso country codes. So
rename those folders that do not have the iso country code in their names.
For example rename German.lproj to de.lproj, Dutch.lproj to nl.lproj and so on.
2.3. changing permissions
To make sure that you are the owner of all externals and other stuff you´ve included in your app bundle we need to change the permissions.
Run the following command in terminal
sudo chmod -R u+rw "<path_to_standalone_app_bundle>"Example
sudo chmod -R u+rw "/Users/matthias/Downloads/DropUpload/DropUpload.app"
Put the path in quotes, this would avoid problems when the path contains spaces.
Or just drag and drop standalone on terminal window. This will take care of spaces etc. as well
3. Codesigning
To codesign .app, a .pkg or a .dmg you need your Developer ID certificates (see steep 1.4)
Signing .app and .dmg is done with the tool sign and the Developer ID Application certificate.
.pkg installers are signed using the tool productsign and the Developer ID Installer certificate
More detailed information comes here...
3.1. Codesigning standalone - get the exact name of your Developer ID for signing
To codesign your app and later the dmg you´ll need the exact name of your Developer ID application.
Open Keychain Access
The name of the Developer ID begins with Developer ID Application: followed by your name and you your ID. See the yellow highlighted entry.
Remember: the Developer ID Installer is needed for signing a package installer .pkg. See the green highlighted entry
3.1.1. Codesigning standalone - now codesign
Run the following command in Terminal
codesign --deep --force --verify --verbose --sign "<your_developer_ID>" --options runtime "<path_to_app_bundle>"Replace <your_developer_id_application> with the name you investigated in the previous step. Keep the quotes.
Replace <path_to_app_bundle> with the path to your standalone. Put the path in quotes, this would avoid problems when the path contains spaces. Or just drag and drop the standalone on terminal window. This will take care of spaces etc. as well
Example
codesign --deep --force --verify --verbose --sign "Developer ID Application: Matthias Rebbe (386687PEUL)" --options runtime "/Users/matthias/Downloads/DropUpload/DropUpload.app"
If code signing was successfull then you should see something like this
A special note about entitlements
If you want to include an entitlements file, then please use this syntax
codesign --deep --force --verify --verbose --sign "<your_developer_ID>" --options runtime --entitlements "<path/to/entitlements.plist>" "<path_to_app_bundle>"Please see also lesson Entitlements for signed and notarized apps for more information
Important Note:
If you are using LC 9.6.1 or higher and make use of the revZip external in your standalone then it is currently mandatory to include an entitlements file with at least the com.apple.security.cs.disable-library-validation entitlement set to true.
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
4. Verifying the signed app (optional)
As the command in the previous step returned signed app bundle with Mach-0 universal (x86_64) [tk.rebbe.dropuploadx] there is no need to run this step. But you can, if you want. ;)
To verify we could enter the following command in Terminal
codesign --verify --verbose "<path_to_app_bundle>"Replace <path_to_app_bundle> with the path to your standalone.
Put the path in quotes, this would avoid problems when the path contains spaces. Or just drag and drop the standalone on terminal window. This will take care of spaces etc. as well
Example
codesign --verify --verbose "/Users/matthias/Downloads/DropUpload/DropUpload.app"
This command is also usefull to find out if any app or DMG, not only yours, is codesigned or not.
It the app is code signed, then you should see something like this
5. Create and codesign a package installer .pkg (optional)
Create a signed package installer in one step:
To create and sign a package installer from the standalone in just one step please run the following command in Terminal
productbuild --sign "your_Developer_ID_installer" --component "<path_to_app>" /applications "<path_to_signed_pkg>" The above command creates a package installer from your app and signs it automatically after creation.
Replace <path_to_app> with the path of the signed app
Replace <path_to_signed_pkg> with the path where the signed .pkg shall be written
Put the path in quotes, this would avoid problems when the path contains spaces. Or just drag and drop the PKG on terminal window. This will take care of spaces etc. as well
When running the above command macOS will show 2 dialogs asking for the password to get access the keychain.
If the creation/signing was successful, you should see similar messages like the following ones:
productbuild: Adding component at /users/matthias/test.app
productbuild: Using timestamp authority for signature
productbuild: Signing product with identity "Developer ID Installer: Matthias Rebbe (xxxxxx)" from keychain /Users/matthias/Library/Keychains/login.keychain-db
productbuild: Adding certificate "Developer ID Certification Authority"
productbuild: Adding certificate "Apple Root CA"
productbuild: Wrote product to /Users/matthias/test.pkg
productbuild: Supported OS versions: [10.9, )
Create an unsigned package installer:
If you just want to create an unsigned package installer then run the following command in Terminal
productbuild --component "<path_to_app>" /applications "<path_to_signed_pkg>" The above command creates just the package installer without signing it. Please follow step 5.1 to manually sign it.
5.1. Codesigning the package installer
This step is only needed, if you 've created an unsigned package installer
Please note: To sign a package installer the tool productsign is needed, not codesign.
Run the following command in Terminal
productsign --sign "<your_developer_id_installer>" "<path_to_pgk>" "<path_to_signed_pkg>"Replace <path_to_pkg> with the path of the newly created .pkg.
Replace <path_to_signed_pkg> with the path where the signed .pkg shall be written
Put the path in quotes, this would avoid problems when the path contains spaces. Or just drag and drop the PKG on terminal window. This will take care of spaces etc. as well
Example
productsign --sign "Developer ID Installer: Matthias Rebbe (386687PEUL)" "/users/matthias/name.pkg""/users/matthias/name_signed.pkg"If code signing was successful, then you should see something like this:
productsign: using timestamp authority for signature
productsign: signing product with identity "Developer ID Installer: Matthias Rebbe (386687PEUL)" from keychain /Users/matthias/Library/Keychains/login.keychain-db
productsign: adding certificate "Developer ID Certification Authority"
productsign: adding certificate "Apple Root CA"
productsign: Wrote signed product archive to /users/matthias/name_signed.pkg
If you want to distribute the package installer directly, then go to step 7.2 Notarizing app (DMG/PKG method)
6. Creating DMG (optional)
If you want to distribute your app or package installer on DMG then follow the next steps.
Run the following command in Terminal to create the DMG
hdiutil create -volname "<Name_of_Volume>" -srcfolder "<path_to_your_app_or_pkg>" -ov -format UDZO "<Name_of_the_DMG>"Replace <Name_of_Volumes> with the name the DMG volume shall show up with, when mounted. Keep the quotes.
Replace <path_to_your_app_or_pkg> with the path to your standalone or .pkg
Put the path in quotes, this would avoid problems when the path contains spaces. Or just drag and drop the standalone on terminal window. This will take care of spaces etc. as well
Replace <Name_of_the_DMG> with the filename the DMG file shall have, for example DropUpload.dmg. Keep the quotes
Example for creating a .dmg from an .app
hdiutil create -volname "DropUpload" -srcfolder "/Users/matthias/Downloads/DropUpload/DropUpload.app" -ov -format UDZO "DropUpload.dmg"
Example for creating a .dmg from an .pkg
hdiutil create -volname "DropUpload" -srcfolder "/Users/matthias/Downloads/DropUpload/DropUpload.pkg" -ov -format UDZO "DropUpload.dmg"
The above commands would create a DMG with the name DropUpload.dmg and the volumename DropUpload, so when the DMG is mounted the volume name would be DropUpload.
6.1. Codesigning the DMG
Run the following command in Terminal
codesign --deep --force --verify --verbose --sign "<your_developer_id_application>" --options runtime "<path_to_dmg>"Replace <path_to_DMG> with the path of the newly created DMG.
Put the path in quotes, this would avoid problems when the path contains spaces. Or just drag and drop the DMG on terminal window. This will take care of spaces etc. as well
Example
codesign --deep --force --verify --verbose --sign "Developer ID Application: Matthias Rebbe (386687PEUL)" --options runtime "/users/matthias/name.dmg"
If code signing was successful, then you should see something like this
6.2. Verifying the codesigning (optional)
As the command in the previous step returned "signed" there is no need to run this step.
However,if you want to check, if a DMG is code signed, run the following command in Terminal
codesign --verify --verbose "<path_to_dmg>"Replace <path_to_DMG> with the path of the newly created DMG.
Put the path in quotes, this would avoid problems when the path contains spaces. Or just drag and drop the DMG on terminal window. This will take care of spaces etc. as well
Example
codesign --verify --verbose "/users/matthias/name.dmg"
7. Notarizing your App, Package Installer (.pkg) or DMG
To get our app notarized by Apple we need to upload it to Apple. Apple does not allow an app to be uploaded directly. Only zip files, Installer packages or DMGs can be uploaded.
Please go to step 7.2, if you want to notarize a PKG or DMG, otherwise continue with the following step to notarize the app using the zip method.
7.1. Notarizing an app (zip method)
7.1.1. creating a zip file from app
Therefore we need to create a zip file from our app first.
The easiest way to do this is to right click on our app and select compress. After the zip file was created we can upload it to Apple.
7.1.2. Uploading the zip file to Apple for Notarization / Analysis
Run the following command in Terminal
xcrun altool -type osx --notarize-app --primary-bundle-id "<primary-bundle-id>" --username "<your_AppleID>" --password "<yourAppSpecificPassword>" --file "<path_to_zip>" [--asc-provider "<ascProvider>"]<primary-bundle-id> = specify an identifier that helps you keep track of automated correspondence from the notarization service. This is for your own use and does not have to be the bundle identifier. In my example i am using the bundle-id tk.rebbe.dropuploadx . Please put the bundle identifier in quotes.
<your_AppleID> = Your AppleID you´ve used for registering your Apple deverloper account. Put the AppleID in quotes
<yourAppSpecificPassword> = The password you´ve created at https://appleid.apple.com For details see chapter 1.3. Put the password in quotes.
Note: See chapter 7 on how to reference to a password stored in Keychain Access instead of using your app specific password directly.
<path_to_zip> = the path to the zip. Put the path in quotes. This will avoid problems when the path contains spaces or any of the following characters \`!$
Or just drag and drop the zip file on terminal window. This will take care of spaces etc. as well
<ascProvider> = shortname of the TeamID (optional)
If you are a member of multiple development teams and your e-mail adress is attached to more than one development team, then you´ll need to add the shortname of your team id, otherwise Apple´s notarization service does not know for which team you are doing the notarization or request. (see chapter Addendum 2 - the asc provider)
Example
xcrun altool -type osx --notarize-app --primary-bundle-id "tk.rebbe.dropuploadx" --username "[email protected]" --password "tic-tac-toe" --file "/users/matthias/name.zip"
If the upload was successful and the file was accepted for notariziation you should see something like the output in the screenshot below
*** Please make a record of the returned RequestUUID (either by copying it to the clipboard, making a screenshot or just by writing it down). You will need it later. ***
Apple is now analysing your uploaded file. If all is well, you´ll get an email from Apple confirming that your app is ready for distribution.
The analysis process could take a while. The fastest here was about 2 minutes, the longest so far 35 minutes.
If you don´t want to wait for the Apple confirmation e-mail and want to check the notarization status see step 7.3.
7.1.3. Delete the zip file again
As the zip file was only needed to upload the app for notarization we can now delete the zip file again. We do not need it anymore.
7.2. Notarizing app (DMG/PKG method)
To get our DMG and the containing pkg or app notarized by Apple we need to upload it to Apple.
7.2.1. Uploading the PKG or DMG to Apple for Notarization / Analysis
Run the following command in Terminal
xcrun altool -type osx --notarize-app --primary-bundle-id "<bundle-id>" --username "<your_AppleID>" --password "<yourAppSpecificPassword>" --file "<path_to_dmg_or_pkg>" [--asc-provider "<ascProvider>"]<bundle-id> = specify an identifier that helps you keep track of automated correspondence from the notarization service. This is for your own use and does not have to be the bundle identifier. In my example i am using the bundle-id tk.rebbe.dropuploadx . Please put the bundle identifier in quotes.
<your_AppleID> = Your AppleID you´ve used for registering your Apple deverloper account. Please put it in quotes
<yourAppSpecificPassword> = The password you´ve created at https://appleid.apple.com For details see chapter 1.3. Put the password in quotes.
Note: See chapter 7 on how to reference to a password stored in Keychain Access instead of using your app specific password directly.
<path_to_dmg_or_pkg> = the path to the DMG or PKG.
Put the path in quotes. This will avoid problems when the path contains spaces or any of the following characters \`!$
Or just drag and drop the DMG/PKG on terminal window. This will take care of spaces etc. as well
<ascProvider> = shortname of the TeamID (optional)
If you are a member of multiple development teams and your e-mail adress is attached to more than one development team, then you´ll need to add the shortname of your team id, otherwise Apple´s notarization service does not know for which team you are doing the notarization or request. (see chapter Addendum 2 - the asc provider)
Example - uploading a dmg
xcrun altool -type osx --notarize-app --primary-bundle-id "tk.rebbe.dropuploadx" --username "[email protected]" --password "tic-tac-toe" --file "/users/matthias/name.dmg" Example - uploading a pkg
xcrun altool -type osx --notarize-app --primary-bundle-id "tk.rebbe.dropuploadx" --username "[email protected]" --password "tic-tac-toe" --file "/users/matthias/name.pkg"
If the upload was successful and the file was accepted for notarization you should see something like the output in the screenshot below
*** Please make a record of the returned RequestUUID (either by copying it to the clipboard, making a screenshot or just by writing it down). You will need it later. ***
Apple is now analysing your uploaded file. If all is well, you'll get an email from Apple confirming that your app is ready for distribution.
The analysis process could take a while. The fastest here was about 2 minutes, the longest so far 35 minutes.
If you don't want to wait for the Apple confirmation e-mail and want to check the notarization status see step 7.3.
7.3. Check the status of analysis
Run the following command in Terminal
xcrun altool --notarization-info <requestUUID> --username "<your_AppleID>" --password "<yourAppSpecificPassword>" [--asc-Provider <"ascProvider>"]<requestUUID> = the ID which was returned after successful upload (see 7.2.1)
<your_AppleID> = Your AppleID you´ve used to join Apple´s deverloper program. Put your AppleID in quotes.
<yourAppSpecificPassword> = The password you´ve created at https://appleid.apple.com. Put the password in quotes.
<ascProvider> = shortname of the TeamID (optional)
If you are a member of multiple development teams and your e-mail adress is attached to more than one development team, then you´ll need to add the shortname of your team id, otherwise Apple´s notarization service does not know for which team you are doing the notarization or request. (see chapter Addendum 2 - the asc Provider)
Example
xcrun altool --notarization-info 8a741234-12b4-1d34-12a4-74abcde2e93c --username "[email protected]" --password "tic-tac-toe"
7.3.1. Check the status of analysis - ...in progress
If the analysis process is not finished, then you see something like this
7.3.2. Check the status of analysis - ...Success
If the anaylsis process was successfull you should see something like this
with Status Message: Package Approved
7.3.3. Check the status of analysis - ...invalid
There might be other messages like Status: invalid
This could come up, if you´ve forgot to do the preparations listed step 2
7.4. confirmation e-mail from Apple
You will also receive an e-mail from Apple informing you about the result of the notarization/analysis.
7.5. staple the app, DMG or PKG. Optional, but recommended.
Stapling means the notarization ticket is added to the app/DMG.
This step is not mandatory, but recommended. It ensures that Gatekeekper can find the notarization ticket even when a network connection (internet connection) isn't available.
Without this step every time an app, dmg or pkg is launched Gatekeeper has to check online if the PKG/DMG/App was notarized or not.
Stapling ensures that Gatekeeper can approve the notarization even when an internet connection isn't available.
7.5.1. staple the app. Optional, but recommended.
To staple it run the following from Terminal
xcrun stapler staple -v "<path_to_app>"Replace <path_to_app> with the path of the standalone.
Put the path in quotes. This will avoid problems when the path contains spaces or any of the following characters \`!$
Or just drag and drop the app on terminal window. This will take care of spaces etc. as well
Examples
xcrun stapler staple -v "/Users/matthias/Downloads/DropUpload/DropUpload.app"If the staple was successfull then you should see The staple and validate action worked!
Instead of stapling the original standalone on the harddisk for distribution, you could just copy the app from the mounted DMG and use that for distribution as zip.
But at least i wanted to show that you also can staple the app. ;)
7.5.2. staple the DMG/PKG. Optional, but recommended.
To staple the DMG run the following from Terminal
xcrun stapler staple -v "<path_to_dmg_or_pkg>"Replace <path_to_DMG> with the path of the DMG or PKG.
Put the path in quotes. This will avoid problems when the path contains spaces or any of the following characters \`!$
Or just drag and drop the DMG/PKG on terminal window. This will take care of spaces etc. as well
Example stapling a dmg
xcrun stapler staple -v "/users/matthias/name.dmg"Example stapling a pkg
xcrun stapler staple -v "/users/matthias/name.pkg"
If you see The staple and validate action worked!, then your DMG/PKG was successfully stapled and is ready for distribution.
8. Addendum 1 - reference to a password stored in keychain
Instead of using your password directly in the Terminal commands you can use a reference to the saved password in keychain. Therefore you have to store your password in Keychain Access.
8.1. Use Terminal to store password in keychain.
Enter the following command in Terminal
security add-generic-password -a "<apple_id>" -w "<app_specific_password>" -s "<keychain_item_name>"Replace <apple_id> with the your Apple ID you´ve use to join the Apple Developer Program. Put it in quotes
Replace <app_specific_password> with the the app-specific password you´ve created at https://appleid.apple.com. (See chapter 1.3). Put it in quotes.
Replace <keychain_item_name> with the name you want the password be saved under in Keychain. This will be the Keychain Item Name. Put it in quotes.
Example
security add-generic-password -a "[email protected]" -w "tic-tac-toe" -s "Notarizing"The above example would add the password tic-tac-toe for account [email protected] to Keychain and would name it Notarizing.
8.2. Use Keychain Access to store password in Keychain
- Select File->New Password Item (cmd+N)
- Enter the desired name example Notarizing in the field Keychain Item Name
- Enter your developer email example [email protected] in the field Account Name
- Enter your app specific password example tiac-tac-toe in the field Password
The screenshot shows the German GUI of the Keychain Access.app. See red translations.
8.3. How to reference to a Keychain password?
In Step 8 the password parameter was
--password "<yourAppSpecificPassword>"Example
--password "tic-tac-toe"
To reference to a password in keychain the parameter would be
--password "@keychain:<name_of_pw_in_keychain>"Replace <name_of_pw_in_keychain> with the Keychain Item Name you´ve use when adding the password to the Keychain
Example
--password "@keychain:Notarizing"
Importan Note: The first time you run altool, you get a security confirmation dialog asking you whether to allow altool to read the password from the keychain. Enter your (Mac) user password and click on Always allow.
9. Addendum 2 - the asc provider
If you are a member of multiple development teams and your e-mail adress is attached to more than one development team, then you´ll need to add the shortname of your team id, otherwise Apple´s notarization service does not know for which team you are doing the notarization or request.
To get a list of all development teams (it seems Apple call them provider) your e-mailadress is attached to run this shell command in Terminal:
For Xcode 10
/Applications/Xcode.app/Contents/Applications/Application\ Loader.app/Contents/itms/bin/iTMSTransporter -m provider -u "<your_AppleID>" -p "<yourAppSpecificPassword>"For Xcode 11
/Applications/Xcode.app/Contents/Developer/usr/bin/iTMSTransporter -m provider -u "<your_AppleID>" -p "<yourAppSpecificPassword>"Note: iTMSTransporter only allows the password parameter as plain password . --password "<yourAppSpecificPassword>"
or as a reference to a file, which has your app-specific password stored. --password "@file:<pathToYourPasswordFile>"
for example --password "@file:/users/matthias/documents/mr.txt". In this example the file mr.txt must contain the app-specific password.
You cannot use the parameter @keychain with the iTMSTransporter!
After running the above command you´ll should see a long output of information. At the end of the output you´ll should see something like this:
In the above screenshot the e-mailadress is attached to two teams (providers). We need the short name of the provider we want to do the notarization/request for.
Let´s say we want to do the request for Multitronic Vertrieb, then the password parameter for the altool commad would look like this
--asc-provider "Multitronic"
10. Addendum 3 - Livecode stack
Using author´s Livecode stack to automate the above steps .
10.1. The Livecode Stack
There´s a Livecode stack available which does all the steps required for Notarization and Stapling.
For creating DMGs the stack uses hdiutil or the command line tool of DropDMG.
DropDMG is more powerful and allows to add layouts, licenses and much more to the DMG.
10.2. Overview
This chapter is just a quick overview. More detailed information about settings can be found in chapters 8.3 to 8.6
If you want, you can test right away following steps
1 - go to settings and enter fill out all fields with appropriate values.
2 - drag your app bundle you want to codesign¬arize to this field
Note: If your standalone is currently stored in a folder which is synchronised with Dropbox, iCloud Drive or any other Cloud Drive, then please move the standalone to a folder that is not synchronised. There was feedback from users who encountered problems when trying to notarize a standalone which was stored on a folder which was synchronised.
3 - enter the Primary bundle id.
According to Apple´s documentation you can enter what you want as the primary bundle id. Specify an identifier that helps you keep track of automated correspondence from the notarization service. The value you give doesn’t need to match the bundle identifier of the submitted app or have any particular value. It only needs to make sense to you. The notarization service includes the value whenever it emails you regarding the given altool submission. If you don´t enter a primary bundle id then the stack uses the bundle identifier of the app.
Allowed characters are a-z,A-z, 0-9 and the period (.)
4 - Select the desired action
5 - Press START
6 - The status field shows information including encountered errors during the codesigning and notarization process. If an error is detected then an answer dialog will popup and the process is aborted.
7 - Debug mode - This will create a list of all shell commands to the clipboard as far as this is possible
8 - Select an action
9 - Press to start the selected action
The image below shows a successful notarization.
10.3. The Main Window
1 - empty all fields
2 - go to settings
3 - drag your app bundle into this field. The app bundle is your standalone you´ve created with Livecode.
Note: If your standalone is currently stored in a folder which is synchronised with Dropbox, iCloud Drive or any other Cloud Drive, then please move the standalone to a folder that is not synchronised. There was feedback from users who encountered problems when trying to notarize a standalone which was stored on a folder which was synchronised.
4 - enter Primary Bundle ID here
According to Apple´s docoumentation you can enter what you want as the primary bundle id. Specify an identifier that helps you keep track of automated correspondence from the notarization service. The value you give doesn’t need to match the bundle identifier of the submitted app or have any particular value. It only needs to make sense to you. The notarization service includes the value whenever it emails you regarding the given altool submission. If you don´t enter a primary bundle id then the stack uses the bundle identifier of the app. Allowed characters are a-z,A-z, 0-9 and the period (.)
5 - the RequestUUID which is returned after successful upload. This field will be automatically filled and is not editable.
6 - The status field shows information including encountered errors during the codesigning and notarization process. If an error is detected then an answer dialog will popup and the process is aborted.
7 - enable this to just create the shell commands without executing them. This will option will be removed in future versions
8 - select the desired action. Currently you can decide between
- signing,creating and signing DMG, notarizing and stapling
- signing, notarizing and stapling App
- list all recent notarization requests -> See chapter 5
9 - push this button to start the desired action
10.4. The Settings
10.4.1. General Settings
1 - Close settings stack
2 - empty all fields
3 - enter your sudo password. This is needed for some tasks. See https://support.apple.com/en-us/HT202035 for additional information about the sudo password.
4 - Your AppleID - please enter the Apple ID you´ve used for the Apple Developer Membership
5 - Keychain item name of your app-specific password. Please see chapter Addendum 1 - reference to a password stored in keychain.
6 - Mark if your Apple ID is attached to multiple iTunes providers
7 - press to retrieve from Apple a list of all iTunes providers your AppleID is attached to
8 - select the iTunes provider you want to use for your tasks
9 - Your Apple Developer ID Application. This contains your name and a number. e.g Developer ID Application: Matthias Rebbe (123456GEUL)
10 - Your Apple Developer ID Installer. This contains your name and a number. e.g Developer ID Installer: Matthias Rebbe (123456GEUL)
11 - Select if you want to overwrite existing Package Installers (.pgk)
12 - select if you have installed DropDMG and want use that tool for creating DMG
13 - click to open settings for DropDMG
14 - select if you want to overwrite existing DMG (this setting will be ignored if DropDMG is used)
15 - select if you want to include an entitlements file for code signing an app
16 - click to open entitlements settings
17 - save settings
10.4.2. DropDMG settings
1 - Close settings
2 - empty all fields
3 - save settings
4 - default path to DropDMG´s command line tool
5 - press to select an other path
6 - Configuration to be used for DMG creation.
7 - press to select DropDMG configurations.
8 - Layout to be used for DMG creation
9 - press to select a DropDMG Layout
10 - License to be add to the DMG
11 - press to select a DropDMG License
12 - check to overwrite existing DMG. Otherwise DropDMG adds a counter to the name e.g. MyDMG-1.dmg
this is automatically handled by DropDMG´s command line tool
13 - go back to general settings
10.4.3. Entitlements settings
1 - Close settings
2 - empty all fields
3 - save settings
4 - the available entitlements - press the ones you want to be included in the entitlements plist file
5 - press to select all entitlements
6 - press to unselect all entitlements
7 - go back to general settings
This dialog contains all the entitlements that Livecode uses. To allow some features of LiveCode to work correctly in signed and notarized apps you need to include the relevant entitlements in an entitlements file. The permissions are then incorporated into the code signature when you build the app.
Or according to lesson Entitlements for signed and notarized apps an option is to sign your app using all the entitlements that LiveCode uses. This will ensure that no features will break because the proper entitlement was not used.
10.5. Show all recent notarization requests (sucessful, failed or in progress ones)
1 - close stack
2- Refresh the list
3 - empty the table
4 - Retrieves information for the selected request from Apple´s Notarization service.
5 - Open the Logfile URL for the selected request.
Note: Fetching the list of all recent notarization requests from Apple´s servers may take some time, so please be patient.
10.5.1. Show detailed information for selected request
1 - close field
2 - information for a request looks like this
3 - this is the Logfile URL you can open directly using the the other option
Note: Fetching the detailed information from Apple´s servers may take some time (approx. 5-10 seconds).
10.5.2. Show logfile for selected request
The field shows the logfile content for the selected notarization request. The logfile is fetched from Apple servers.
Note: Fetching the logfile data from Apple´s servers may take some time (approx. 5-10 seconds).
The following screenshot shows the logfile content of a successful notarization
The following screenshot shows the logfile content of an unsuccessful notarization.
11. Troubleshooting
It can happen that your app will not be approved and the notarization fails. This can have several reasons. But how do you get to know what the reason was?
You can either use the stack mentioned in chapter 9 to find out or you use the shell and run several command to find out.
This chapter explains how to find out using shell commands.
11.1. How to get detailed information about a notarizatian request
11.1.1. Get a list of all recent requests
To list all recent notarization request run the following command in Terminal
xcrun altool --notarize-history 0 --username "<your_AppleID>" --password "<yourAppSpecificPassword>" [--asc-provider "<ascProvider>"]<your_AppleID> = Your AppleID you´ve used for registering your Apple deverloper account. Please put it in quotes
<yourAppSpecificPassword> = The password you´ve created at https://appleid.apple.com For details see chapter 1.3. Put the password in quotes.
Note: See chapter 7 to see how to reference to a password stored in Keychain Access instead of using your plain app specific password
<ascProvider> = shortname of the TeamID (optional)
If you are a member of multiple development teams and your e-mail adress is attached to more than one development team, then you´ll need to add the shortname of your team id, otherwise Apple´s notarization service does not know for which team you are doing the notarization or request. (see chapter Addendum 2 - the asc provider)
The screenshot below is an example and shows a list of recent notarization request i´ve done. The column status shows the status of the notarization requests. The latest requests are always
at the top of the list. So our failed request is the first one. We need the requestUUID of that request. Copy the id to the clipboard. We need it in the next step.
11.1.2. Get information for a single request
In the previous step we´ve copied the requestUUID of the failed notarization to the clipboard.
Now run the following shell command in Terminal:
xcrun altool --notarization-info <requestUUID> -u "[email protected]" -p "@keychain:Notarizing"<requestUUID> = the requestUUID for which we want more information. In our case this is the id we´ve copied to the clipboard
The screenshot below shows the information for our failed notarization. But we still don´t see any reason, but a URL.
Copy the complete URL to your clipboard and open it then in your webbrowser.
You should see something like this.
In our example the reason for the failed notarization was that the binary used an SDK older than the 10.9 SDK. In this example the app i tried to notarize was created with on older version of Livecode. So creating the standalone using a current version of LC should solve the notarization problem.
Jerry Janson
This is an outstanding and very worked-out lesson with great detail. Thank you!
simon schvartzman
Hi team, the Stack provided in this lessons seems to be exactly what I was looking for but I'm having troubles to identify where to get the contents of the fields. I understand this is due to my poor knowledge on the subject and would really appreciate any help to learn:
1 - from where to "Drag the App bundle"
2 - is the "sudo password" created in this step or it is coming from another place (where?)
3 - "Keychain item name of your app-specific password. Please see chapter 7 of the following livecode lesson:" don't know where the "following lesson" is
With answer to the previous questions I guess I would be able to move forward, hopefully till the end.
Many thanks in advance
Matthias Rebbe
@Simon Schwartzman
Hi Simon,
I am the author of the lesson and the stack, so please allow me to answer your questions
1. You drag the Mac OS standalone you´ve created with Liveode, from the Finder to the field. This will enter the path of the app into the field.
2. If your Mac user account has admin rights, then enter here your user account password. See https://support.apple.com/en-us/HT202035 for additional information about the sudo password.
3. Thanks for pointing this out. This should be " See "Please see chapter 7". This has been corrected now.
I´ve also made some adjustments to the lesson regarding your questions 1 and 2, in case others will also have the same questions.
Regards,
Matthias
simon
Hi Matthias, many thanks for your prompt answer and for sharing this useful tool.
I have made some progress but getting an error, please see below the log of the process (I have put XXXX on the passwords):
Removing extended attributes...
executing:
pw=XXXXXXX; echo $pw | sudo -S xattr -cr "/Users/simonschvartzman/Desktop/LuckroSpotNS/LuckroSpotNS/LuckroSpotNS.app"
checking if all ext. attributes were removed
renaming localization folders...
Adjusting permissions...
executing: pw=XXXXXX; echo $pw | sudo -S chmod -R u+rw "/Users/simonschvartzman/Desktop/LuckroSpotNS/LuckroSpotNS/LuckroSpotNS.app"
will wait 3 seconds
Codesigning app...
executing: codesign --deep --force --verify --verbose --sign "Simon Schvartzman - Y5MN66BY780 --options runtime "/Users/simonschvartzman/Desktop/LuckroSpotNS/LuckroSpotNS/LuckroSpotNS.app"
Simon Schvartzman(Y5MN66BY780): no identity found
process aborted
What am I doing wrong?
Matthias Rebbe
Hi Simon, there is somethin wrong with you developer id. Is it possible by any chance that you´ve forgot a space between Simon Schvartzman and (Y5MN66BY780). At least in my developer id there is a space between my name and the (.....) part.
Matthias Rebbe
And another thing i just noticed. The developer id should also contain 'Developer ID Application: ' So in your case it should be
Developer ID Application: Schvartzman (Y5MN66BY780)
David Kesler
I'm getting an aborted process at the code signing phase, here is the status:
Codesigning app...
executing: codesign --deep --force --verify --verbose --sign "Developer ID Application: David Kesler (2FY45R2CL9)" --options runtime "/Users/djkesler/Desktop/launcher/FCLauncher.app"
error: The specified item could not be found in the keychain.
process aborted
I copied my developer id directly from my certificate in the key chain.
Can you think of a reason it couldn't find it, or is the "specified item" something other than the developer ID entry?
Thanks for writing this program! Am am hopeful to get my app notarized soon.
DK
Matthias Rebbe
Hi David,
to be honest, i have no clue.
The error message indicates, as far as i understand, that your certificate "Developer ID Application" could not be found in the keychain. But as you stated, you´ve copied it from directly from the keychain. So that could not be the case.
Did you already try to enter the Developer ID manually into the appropriate field? Maybe there was a hidden character when copying it from the keychain.app.
Regards,
Matthias
David Kesler
Matthias, I work my way through the problem. I was initially running the notarization app on a "High Sierra" machine, the first time I ran it on my "Mojave" machine it work! There was a slight difference in the way the certificate was presented between the OSs and that is what gave me the idea that that may be the problem. I am now waiting for apple to analyze my app.
Thanks again so much for doing this.
DK
Matthias Rebbe
Great to hear that you´ve found out what was causing it.
Thanks for letting us know.
All the best.
Regards,
Matthias
David Kesler
At the end of a "Codesign App, then notarize and staple" there is a dialog that ask "Open Output Folder?". I have looked to see if there is anything written into the folder that contained the original app, but the time stamp did not seem to indicate that anything had been written to that folder, unless it was the two log files. Is that all that the question is asking, "OK to write the log files?"
Thanks,
DK
Matthias Rebbe
Hi David,
no, the logfiles are written regardless what you are selecting in the answer dialog. This dialog shall, in case the user closed the window where the original file was stored, open that window again to show the modified files and the logs.
Now to your question about modification date. Although the app bundle still shows the date when the standalone was created, it definitely has something new in it. In the app bundle in Contents there is now a new file called "CodeResources". And this file shows definitely a modification/creation date that is newer than the date when the standalone was created.
To verify you could right click on the app bundle and select "show package content".( I am not sure if this is the correct english expression. I am working with a German Mac OS).
Now open the folder contents and you will see that new file.
Regards,
Matthias
BJ
Flawless instructions and everything worked until the final step of trying to staple the dmg. I received this error:
Codesign offset 0x19b1ffb length: 9501
Stored Codesign length: 9501 number of blobs: 3
Total Length: 9501 Found blobs: 3
Although we wrote the ticket, the written data did not validate. Please restore /Users/BJ/Desktop/mycoolapp.dmg from backup to try again.
The staple and validate action failed! Error 73.
Thoughts?
Matthias Rebbe
Hi BJ,
just a shot in the dark, but is it possible that you´ve enabled iCloud drive/desktop synchronization? If so, could you try to store your standalone in a folder which is not synchronized with iCloud drive and run the complete notarization process from start?
Could you also tell what version of MacOS, Xcode and LC you are using.
If just the staple action fails, then it would mean, notarization went through and your Standalone at least could be distributed.
It would only mean, that every time the standalone is opened, Mac OS tries to check with Apple if the standalone is notarized or not.
Regards,
Matthias
BJ
LC 9.5.1, High Sierra 10.13.6, Xcode Version 10.0 (10A255). Still no luck. Moved files to /users/BJ/ and tried it from there vs being on the desktop. Also, iCloud is not sync'n desktop. Staple of mycoolapp.app is successful but it just fails when attempting to staple the mycoolapp.dmg file.
Also, in step 6.2.1. you reference needing to save the result but I didn't see any place after this step where it was needed? Not sure if it matters, but I thought I'd ask.
*** Please make a record of the returned RequestUUID (either by copying it to the clipboard, making a screenshot or just by writing it down). You will need it later. ***
Matthias Rebbe
The RequestUUID can be used to check the status of the notarization process as described in step 6.3. This normally makes no sense when doing all steps manually. But it could even help there. Just imagine the notarization process is finished, but for whatever reason the Apple email does not arrive or did not arrive yet. Checking the status would give you the needed information.
I am not sure, what went wrong on your side. Did you run through all steps manually?
If so, could you try the NotarizationHelper stack which is included in the lesson?
If not, could you try to manually staple the DMG using the command in Terminal as described in Step 6.5.2?
Devin Asay
Matthias,
Thanks for these great instructions. It saved my life when the new version of App Wrapper failed on notarization. Following your instructions I was able to do it from the command line. I have a question: I distribute my app on a DMG. Is it necessary to staple both the app and the DMG? I did the notarization with the DMG method, and only stapled the DMG. Will it work alright?
Regards,
Devin
Matthias Rebbe
Devin,
as far as i've have understood the guidelines, there is no need to notarize and staple both the app and the disk image which contains the app. It's sufficient to put the unnotarized app on the disk image and notarize and staple just the DMG.
If you want to notarize software inside a .zip file. then you've to notarize/staple the app, because the notarization result cannot be attached onto the archive.
Regards,
Matthias
Matthias Rebbe
Devin,
one question i've forgotten to ask. Why did yo do the notarization using command line? Didn't you try the attached stack, which should be able to do all the needed steps automatically?
Or did you try and it didn´t work? I am very interested in any feedback about using that stack.
Regards,
Matthias
simon
Matthias, I've been using the attached stack for a while and it works like a charm. It is indeed of great help!
Regards, Simon
Matthias Rebbe
Simon,
thanks for your feedback.
Devin Asay
Matthias,
I had purchased App Wrapper to do code-signing and notarization, and to be honest, it didn't even occur to me to try your stack! App Wrapper just wraps terminal commands in a GUI, and when it failed the log noted which command had failed, so I copied it out of the log and pasted it into the command line. The problem was (I guess) that the altool command wasn't in my PATH file, so I just provided the full file path to altool on the command line, and it worked.
I may try to use your stack next time and see how it works.
Cheers,
Devin
Martin Koob
Hi Matthias. I just want to let you know of a problem I had with an app that used the CameraControl to record Video and Audio that I resolved with the help of LiveCode's Ian MacPhail and Panos Merakos.
I followed your instructions in this lesson doing each step manually and my app was successfully signed and notarized. Then when I tested out the app on a Mac with Catalina the app would crash as soon as I opened the camera.
I read the crash report andI found the thread that crashed:
Thread 10 Crashed:: Dispatch queue: com.apple.root.default-qos
0 libsystem_kernel.dylib 0x00007fff6e696a76 __terminate_with_payload + 10
1 libsystem_kernel.dylib 0x00007fff6e6b0406 abort_with_payload_wrapper_internal + 119
2 libsystem_kernel.dylib 0x00007fff6e6b0411 abort_with_payload + 9
3 com.apple.TCC 0x00007fff64d9e59f __CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 163
4 com.apple.TCC 0x00007fff64d9c531 __TCCAccessRequest_block_invoke.114 + 500
5 com.apple.TCC 0x00007fff64d9ca58 __tccd_send_message_block_invoke + 231
Also I noticed that the app did not ask for permission to open the Camera and Microphone as it should
have.
Ian referred me to a bug report where others had experienced this same issue with entitlements where Panos explained that entitlements needed to be included in the codesigning command and explained how to do that. https://quality.livecode.com/show_bug.cgi?id=22660#c4
So to include the entitlements for camera and audio input you need to create a file called 'entitlements.plist' with just the following text.
com.apple.security.device.audio-input
com.apple.security.device.camera
I was having trouble implementing the suggestions in the bug report so I got a clearer explanation from Panos that I am including here.
The entitlements.plist file can be saved anywhere as long as the "" is valid.
Then the entitlements are added to the codesign command as follows:
codesign --options runtime --verbose --deep --force --sign "myCertificateName" --entitlements "" ""
You need to do this if your app needs any of the entitlements that LiveCode can ask for. Panos gave me the complete list here. You would only include the ones your app needs to use in your entitlements.plist file.
com.apple.security.cs.allow-jit
com.apple.security.cs.allow-unsigned-executable-memory
com.apple.security.cs.allow-dyld-environment-variables
com.apple.security.cs.disable-library-validation
com.apple.security.cs.disable-executable-page-protection
com.apple.security.device.audio-input
com.apple.security.device.camera
com.apple.security.personal-information.location
com.apple.security.personal-information.addressbook
com.apple.security.personal-information.photos-library
com.apple.security.automation.apple-events
Perhaps this can be added to this lesson to prevent future LC users from running into this.
Also it would be good to have this function included in your app, a checklist of the available entitlements that the user could check off and then the app would add those to the codesign command.
Anyway thanks for this lesson. It really helped me to understand the codesigning, notarizing and stapling process.
Martin Koob
OH no. The plist is in XML format but all the XML tags got eaten in the page rendering. I don't know how to escape them in the comments here.
Look at the bug report that is linked here to see how the entitlements.plist should be formatted.
Martin Koob
A comment about the SIgn'n'Notarize helper stack. I tried using that at first but it would fail at different points. I ended up using it in debug mode to output the list of commands and then entering them manually. I can't remember what was going wrong. It was probably one of the General Settings that I had entered incorrectly as I didn't fully understand the process. Now that I have a handle on it I will go back and see if I can get your helper stack to work.
Thanks.
Martin
Panos Merakos
Hello all,
The "codesign" command that includes the entitlements file is the following, as Martin said:
codesign --options runtime --verbose --deep --force --sign "myCertificateName" --entitlements "path/to/entitlements.plist" "path/to/standalone.app"
(I post it again, because some parts were lost in page rendering)
Craig McArthur
Thanks Matthias, a great piece of work. I can see why Apple implemented the new security protocol, but wow it's difficult to figure out. I finally got there thanks to you.
Cheers
Craig
Russell
Dear Matthias, I have followed your marvellous instructions and have produced a notarized and stapled app with a log that says success in all externals and entitlements (i.e. revBrowser). I have also checked in Terminal with "spctl --assess --type open --context context:primary-signature --verbose", "spctl -a -vvv" and "xcrun stapler validate" and all cases received a positive response. Only when I now try to run the app on my desktop it no longer runs and I get the message "Application Not Responding". I have trawled through a lot of Livecode and Apple fora to no satisfaction. Any thoughts/solutions very happily accepted. Regards Russell
Elanor Buchanan
Hi Russell
I wonder if there are any entitlements that you might need to include in the entitlements file. Have you had a look at the "Entitlements for signed and notarized apps" lesson?
https://runrev.screenstepslive.com/admin/v2/sites/14751/toc/manuals/4071/chapters/246840?showCurrentArticle=1293515
Kind regards
Elanor
Matthias Rebbe
Hi Russel, the correct link to that lesson is
http://lessons.livecode.com/m/4071/l/1293515-entitlements-for-signed-and-notarized-apps
Matthias Rebbe
@Martin Koob
Thanks for your useful information. Seems i have to either enhance my lesson or at least should mention the entitlements stuff lesson. I will see, if i even get my NotarizeHelper stack updated. So that one can define an entitlement.plist file before code signing.
Russell
Thanks Both. Just got an all round success response with following entitlements:
com.apple.security.files.bookmarks.app-scope
com.apple.security.files.bookmarks.document-scope
com.apple.security.network.client
com.apple.security.network.server
I am using Browser only - I assumed these would be the required entitlements. There is nothing added in the Externals folder and the app works great before the notarizing process. As mentioned I have gone through the entire process including stapling and at every stage I've got a "success" response. However, the app is not working anymore. I tried making a simple app without a Browser and without entitlements which also got the success response and will work in the Applications folder. Is there anything else that should be in the entitlements? Please advise.
Matthias Rebbe
Did you already try to add all the entitlements as described in the lesson Elanor mentioned?
Matthias Rebbe
@Russell What happens when you just code sign the app. Does it still works then?
Matthias Rebbe
@Russell On what macOS version are you getting the "Application not responding" message?
Matthias Rebbe
@Russell Any chance that you are on Mojave and have installed the Security Update 2020-005 10.14.6? If so, did you install it in September or October. If in September then could you check. Apple re-released the Security Update 2020-005 because it was causing problems. Maybe this is also the cause for your problems.
Russell
Interesting Matthias and worth a try in that I am using Mojave and I have just installed the updated update before I started these app builds. I have checked for further updates and I am up to date. Not sure that helps?
Russell
I'll add the other entitlements and check the code sign app over the next couple of days. Thanks again both.
Matthias Rebbe
@Russell Okay, then it seems you've updated in October. Apple re-released fixed versions on the 1st or 2nd of October.
Russell
On other projects today. I'll put the other entitlements in as suggested by Elanor and check the code signing stage over the next couple of days. Thanks again for your help.
Elanor Buchanan
Sorry for including the wrong link in my comment, I was logged in as an admin and I should have noticed. Thank you for providing the correct link Matthias.
Elanor
Russell
Hmmmmm. Well I added the "Elanor entitlements" to the ones I mention above and the app worked when code signed and when I notarized it! Not completely convinced what has sorted this. But it works. Thanks very much to you both.
Regards
Russell
Matthias Rebbe
I am glad to hear that it finally worked for you. I am currently reworking this lesson. I will add the Entitlements stuff. The NotarizeHelperStack was also enhanced so it allows now to select the needed entitlements for Code Signing. It is not yet online. I want to finish the lesson update first.
Russell
Further to: I came across these two helpers on the Apple "Ensure Properly Formatted Entitlements"
Correctly formats the entitlements file: plutil -convert xml1
Verifies the formatting: plutil -lint
That is useful because it removes any line gaps in the file etc.
Regards
Russell
Matthias Rebbe
Hi all,
the lesson and the NotarizeHelper stack were updated. The stack now allows code signing with entitlements.
Peter Bogdanoff
Hi Matthias, thanks for your work on this!
I'm getting an error after the upload for notarization:
Status Code: 2
Status Message: Package Invalid
Which shows on the web page:
"severity": "error",
"code": null,
"path": "MITA.zip/MITA.app/Contents/MacOS/MITA",
"message": "The signature of the binary is invalid.",
"docUrl": null,
"architecture": "x86_64"
I used both the mrSign stack and individuals commands in Terminal to try this with the same result.
I've rechecked to confirm that my Apple ID, Developer ID Application are both correct. The Developer ID Application is in the format: Developer ID Application: Peter Bogdanoff (XXXXXX)
I set the Primary bundle id into the Mac page of the Standalone Application settings and that is loaded into Primary bundle id field: com.artsinteractiveinc.mita
In Terminal I ran codesign --verify and I get: satisfies its Designated Requirement
Do you have any idea why this fails?
Does my App ID (from my Apple Dev account: Certificates, Identifiers & Profiles/Identifiers) have anything to do with the Primary bundle id? Those two things are different. Is that App ID needed for any of this?
Matthias Rebbe
Hi Peter,
to be honest i have no clue what is wrong.
The lines
"path": "MITA.zip/MITA.app/Contents/MacOS/MITA",
"message": "The signature of the binary is invalid.",
shows the reason why it is rejected.
Could you please try the following command
codesign -verify -verbose.
Matthias Rebbe
Peter,
or for a more detailed result
codesign -dv -verbose
Peter Bogdanoff
The result in Terminal for those two commands--
codesign --verify --verbose: 'valid on disk' (and) 'satisfies its Designated Requirement'
codesign -dv -verbose: 'edited signature app bundle with Mach-O universal (x86_64) [com.artsinteractiveinc.mita]'
Should the last one NOT say "edited'?
Matthias Rebbe
Peter, my fault.
Could you please just run
codesign -dv
Btw. On what macOS are you and what Xcode are you using? I could try to notarize one of my app in a VM with that configuration, just to make sure that this is not someting related to the Xcode version.
Peter Bogdanoff
codesign -dv returns:
Format=app bundle with Mach-O universal (x86_64)
CodeDirectory v=20500 size=180071 flags=0x10000(runtime) hashes=5620+3 location=embedded
Signature size=9012
Timestamp=Nov 21, 2020 at 1:26:19 AM
Info.plist entries=30
TeamIdentifier=U768M256PT
Runtime Version=10.9.0
Sealed Resources version=2 rules=13 files=113
Internal requirements count=1 size=188
In on macOS 10.14.8
Xcode: 10.3
Matthias Rebbe
Peter,
please excuse my late answer.
1. You mean 10.14.6 and not 10.14.8, right?
2. Which LC are you using. If LC 9.6x, you should use Xcode 11.3.
Unfortunately i do not get Xcode 10.3 installed on macOS 10.14.6 for whatever reason.
Peter Bogdanoff
Matthias, yes macOS 10.14.6. I moved to another machine with Catalina + xCode 11.7. I still got the same error.
Since I was getting the error description, "the signature of the binary is invalid" I then tried removing a folder of stack files and JPG files from the MacOS folder inside the package (they were all in a folder named "Data") and the process was successful, "Your Mac software has been notarized."
Is the script supposed to sign each of these files? These are files that I need to run my program.
Peter Bogdanoff
Matthias -- I got it to work. I needed to change the files that I needed in the package to be set by the LiveCode Standalone Application Settings. I added them to the stacks and files tabs in the Standalone Application Settings and LIveCode moved them to new locations in the package, and this worked properly for codesigning and notarizing. I'll now have to change my IDE paths to access the files, but this is minor.
Incidentally, I used macOS 10.14.6, LC 9.6.1, and Xcode 10.3 to do this successfully.
I'm now trying to get dropDMG to create the DMG automatically. I gave dropDMG access in macOS privacy settings... I'll continue to tweak the settings to get it right.
Thanks very much!!!
Matthias Rebbe
Peter,
good to know that it works now.
I have one question:
How did you add the files before? Did you create the standalone and added them manually afterwards to the MacOS folder?
Anyway. It's working now. That's the main thing.
Peter Bogdanoff
Yes, I did that -- create the standalone, then added the files manually. I used scripting to sign everything in that folder, as well as the EXE. It worked for pre-Catalina.
Matthias Rebbe
Hi Peter,
...as well as the EXE... ?? Did you add an .exe file to your app bundle?
Anyway,
maybe i should mention in the lesson, that additional files have to be added using the 'Copy Files' section in the standalone builder.
Peter Bogdanoff
Sorry, no I was referring to the executable.
Yes, to mention the stacks and files tabs would be very helpful.
Matthias Rebbe
Good to know. I was a little bit confused. ;)
I've added now a note about how to add additional files and folders to the standalone. It's in section 1.9.
Thanks for bringing this up, Peter.
Mark
"For creating DMGs the stack uses hdiutil or the command line tool of DropDMG." Hi Matthias, is this something I need to download and install or does the stack do this for me? Thanks
Mark
Hi Matthias, just a quick note. On the settings page you have flagged some fields as req'd (with an *) but not the sudo password (which I don't know so left out). When I run the app it asks me for a sudo password and says it's req'd? Thanks
Mark
Ok, signing was successful, notarizing failed with this message "Failed to get the password for the keychain item 'spyc-jdam-qssb-bbda'.". At some point it asked for my keychain password and I gave it my login password (since I don't know what my keychain pw would be). Is that why this failed? How do I rectify this? I looked at my keychain and it's not locked, so if should have been able to gain access just fine?? In fact I closed it and opened it and it didn't ask for a pw. Not sure what this all means. Thanks
Matthias Rebbe
Hi Mark, instead of entering your app specific password you need to add the name under where the app specific password was stored in the key chain. Please see chapter 7 on how to add you app specific password to the key chain.
Matthias Rebbe
@Mark
Regarding "For creating DMGs the stack uses hdiutil or the command line tool of DropDMG." Hi Matthias, is this something I need to download and install or does the stack do this for me?
hdiutil is a macOS system tool and is already available. DropDMG is a commercial tool from https://www.c-command.com and must be downloaded.
Russell
@DavidKesler You mention in your post: "I work my way through the problem. I was initially running the notarization app on a "High Sierra" machine, the first time I ran it on my "Mojave" machine it work! There was a slight difference in the way the certificate was presented between the OSs and that is what gave me the idea that that may be the problem. I am now waiting for apple to analyze my app."
I have the same problem with certificates in Big Sur i.e: "The specified item could not be found in the keychain." even though I have checked that the wording is correct. Could you let me know what was different between the certificates on High Sierra and Mojave?
Or @Matthias/@Elanor any thoughts in this regard gratefully received.
Thanks.
Russell
Elanor Buchanan
Hi Russell
Have a look at your Certificates in Keychain Access and see if everything looks ok, nothing has expired and the private keys are all in place etc.
Elanor
David Kesler
Russell,
I never actually found out why it started working, I was just ecstatic it did.
I can say that whenever I have had a problem since, it has been down to making sure everything is exactly the same as the keychain, without doing a copy and paste. If you read Matthias’ comment just before I had the successful notarization on Oct 09, 2019 he suggested that copying from the keychain can introduce problems, so I retype my Apple Developer ID Application and the application specific password.
Also, if you change the label you gave to the app specific password, there are two places in the keychain that must match for it to work.
I have to say since the Matthias put out the new version that included the entitlements, I have had problems only with typographical errors that I have made.
I am SO thankful to Matthias for this program!
jeff k
Matthias,
I agree with your commenters that you've been a light in the wilderness with respect to code-signing. I've had no success to date, but I can share a few things I've learned so far -- apart from the obvious lesson I've learned (the hard way) that typos can be fatal when using your stack.
The first problem I encountered was an error when LiveCode improperly included tsNet in an automatic search for inclusions. (The solution was to select the inclusions manually.)
A second problem was an error message that "altool" could not be found. Hoping to avoid having to download the entire XCode, I had installed only the Command-Line-Tools. A web search indicated that CLT did not include "altool" -- heads up to others who've made the same mistake -- so I spent a day downloading XCode, hoping that this would resolve the problem. Apparently, everyone needs XCode.
Sadly, I'm now getting an error message "Failed to get the password for the keychain item..." In ignorance, I probably just screwed up my keychain (and maybe my developer account) over previous failed attempts.
Curiously, when I misinterpreted your General Settings item "Name of app-specific password*" as meaning the actual password and not its Keychain name, I actually got a few steps closer before the process aborted.
Obviously, I've got to persist until this works, but you've given us a great start. Thanks!
jeff k
Update:
Using Matthias' livecode stack, I was able to code-sign both my app and a DMG that employed the very nice design options available via the third-party DropDMG app. (Both were confirmed using the terminal commands that Matthias provided.)
However, in order to circumvent the problem experienced with accessing the keychain password item, I then resorted to using the Terminal to include the actual app-specific password. From there, using Matthias' examples, I was able to notarize and staple my dmg successfully.
Although Matthias' livecode stack probably works fine from start to finish, in my experience this strategy is what got this to work.
jeff k
The instructions for Matthias' livecode stack include the warning that when revZip external is employed, a that references this must must be included in an entitlements file. Because this is apparently not among the externals included in the default entitlements file created by that stack, am I correct to assume that I should *instead* create an entitlements file manually that includes this line (along with one for the Internet external that also is not included in the default)?
I don't use these externals in my own code, but these are required as inclusions in order to employ Curry Kenworthy's third-party extension "WordReport" to generate MSWD-compatible documents. (That extension currently breaks in macOS Catalina and possibly even in Windows 10, but hopefully will be fixed by its author some time soon.)
Thanks!
Matthias Rebbe
Jeff,
if i recall it correctly then the warning about revZip and the needed entitlement is within the lesson and not exclusively as a comment for the attached stack. The stack already has a feature to include that entitilement or even all entitlements that are recommended by Livecode.
Matthias Rebbe
@Jeff
Regarding Curry's Wordreport.
I did not use it currently in a standalone, but what i can say is, that Wordreport defintely works here in the LC IDE under Catalina and Big Sur. The only thing what is breaking it, is if you use non ascii characters. But this is not OS dependet. There is a workaround for that. If you like, we could talk about that in the use list.
jeff k
Thanks for your incredibly quick reply! Obviously this is not the place to discuss third-party providers. Although I've been using LC since 2014, I've just now subscribed to that use-list -- which apparently differs from the LC forums whose incredibly generous contributors have helped save my butt more than a few times since 2017.
If/when I am approved to join, perhaps we can pursue this issue there -- wherever "there" is. Curry recently confirmed that WordReport does break in Catalina+ standalones -- as I'd reported to him over a year ago -- but promises to fix this some time in the future. One of my apps remains on hold until then.
jeff k
jeff k
Just in case anyone needs to include the (not always) optional "asc provider" when notarizing via Terminal, I've found that in order to avoid an error, a hyphen is required in the command: --asc-provider "". (The instructions in Sections 7.x instead read: --ascprovider "")
Also, as regards Section 9 Addendum 2, the instructions illustrate references to Xcode in order to identify one's development team. I can't vouch that this works for everyone, but the following did for me:
xcrun altool --list-providers -u "" -p ""
In my case, it turned out that the short name needed was just the ten-character string associated with my Developer ID.
Matthias Rebbe
Thank you very much for pointing the typo out. It's corrected now.
Regarding your comment regarding Section 9Add2 i do not fully understand. Did you had problems with the example code? If so, could please you tell me which version of Xcode you are using?
Regards
Matthias
jeff k
As regards Section 9Add2, my point was simply that the examples apparently assume that one has installed the entire 40GB Xcode package. Last year I opted to install only the lightweight (1.2GB) command line developer tools, which are sufficient to perform the codesigning/notarizing/stapling when following your detailed instructions. Hence, the simpler command line that I found worked for me.
Still, your explanation that asc provider might be needed proved very helpful. I'd been stymied for over a week when Apple suddenly began rejecting my attempts to submit a .dmg for notarization, until Dev Support informed me that I had (unintentionally ) created an unneeded Podcast account using my same Apple ID some time before the first notarization failure occurred. Including asc-provider resolved the problem.