A cross-platform QT application is built for macOS. This app works if I test this on the same machine. When I create a .dmg file, this also works on my machine. When I test this on another machine, I get the error:
You do not have permission to open the application "MYAPP".
How can I debug this to see what the problem is?
Steps I do to create the .dmg file:
Run qmake and make until I have MYAPP.app (release build)
binarycreator -c config/config.xml -p packages/ setup_MYAPP
This creates setup_MYAPP.app
codesign -s "Full common name of my Apple Distribution profile" setup_MYAPP.app
When I provide a meaningless name between quotes it throws an error, so I assume this went fine.
hdiutil create -format UDZO -srcfolder setup_MYAPP.app MYAPP.dmg
This creates MYAPP.dmg, and the installer refuses to run on another macbook.
Alternatively:
Run qmake and make until I have MYAPP.app (release build)
codesign -s "Full common name of my Apple Distribution profile" MYAPP.app
macdeployqt MYAPP.app/ -dmg -codesign="Full common name of my Apple Distribution profile" -appstore-compliant
This creates MYAPP.dmg, and the app refuses to run on another macbook.
OK, it seems the correct answer is "it's complicated".
I have not succeeded in creating an installer that I can share outside the MAC App Store. Apple has restricted this to the point at which I just give in to bureaucracy and to good looking but really extremely bad documentation.
Distribution outside the Mac App Store requires notarization since macOS 10.15.5: see https://developer.apple.com/news/?id=04102019a.
Notarization means signing the code and uploading it to Apple. Apple will perform some magic checks and list it in some internal database.
Notarization requires a Developer ID certificate: see https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721 This is different from a certificate you need for app development and App Store distribution (Why, Apple, why?)
To obtain a developer ID certificate you need to fill in the form at https://developer.apple.com/contact/kext, which is the same form used to be able to write kernel extensions. Kernel extensions. (Why, Apple, why?)
When Apple does not respond to your form submission, you need to poke them a few times. And after they denied your request, you can poke all you want, they likely have set up a vertical classification rule immediately thereafter.
But, should you have been able to get your hands on a precious developer ID certificate, these seem to be the steps to follow to successfully notarize your app:
> security unlock-keychain -p PASSWORD !/Library/Keychains/login.keychain-db
> codesign --timestamp="http://timestamp.apple.com/ts01" --options runtime --verbose=3 --force --deep --sign "NAME OF CERTIFICATE" PATH/TO/APP.app
> xcrun altool -u USER_EMAIL -p APP_SPECIFIC_PASSWORD -notarize-app -t osx --primary-bundle-id INVENT_YOUR_OWN_UNIQUE_ID -f PATH/TO/APP.app
The last run will return another ID, of the form abcdef01-2345-6789-abcd-ef0123456789 and you can use that ID to follow up on your notarization request:
> xcrun altool -u USER_EMAIL -p APP_SPECIFIC_PASSWORD --notarization-info abcdef01-2345-6789-abcd-ef0123456789
You will also get a mail with a link to the notarization results.
I didn't succeed in getting a go, and I'm giving in. I gave up. The next brave soul to run into this may be saved some time after reading this. Good luck, may you succeed where I failed!
Related
There is a professor at the university I work at that has developed a MacOS application he needs to get signed so that it doesn't get blocked by MacOS when users try to run it. I've gotten his CSR and gotten an Apple Developer cert created for him (using the 'ad hoc' distribution option, which created a cert file named 'distribution.cer').
I've searched the Apple Developer site for information on how to sign the application using XCode, but I can't quite grasp the instructions, not being an XCode user or Apple dev.
From what I can gather, you can also sign an app from a terminal, is that correct? If so, does it only work with .pkg installers, or also pre-compiled applications (.app files)?
Code signing
Apple Certificates
Developer ID Application Certificate - sign a macOS application for distribution outside of the Mac App Store.
Developer ID Installer Certificate - sign an application's Installer Package (if any) for distribution outside of the Mac App Store.
Signing an app
On the command line in a Terminal:
codesign -f -o runtime --timestamp -s "Developer ID Application: YOUR NAME (TEAM_ID)" /path/to/bundle.app
Notarization
Be aware that since macOS 10.14.5 (Mojave), software signed with a new Apple developer certificate must be notarized. Code signing is no longer sufficient to bypass Gatekeeper.
Apple's notary service requires you to:
Enable code-signing for all of the executables you distribute.
Enable the Hardened Runtime capability for your application and command line targets (include -o runtime option when running the codesign tool).
Use a “Developer ID” application, kernel extension, or installer certificate for your code-signing signature.
Include a secure timestamp with your code-signing signature (include the --timestamp option when running the codesign tool).
Don’t include the com.apple.security.get-task-allow entitlement with the value set to any variation of true.
Link against the macOS 10.9 or later SDK.
Step 1 - Create a disk image
Create a disk image of the app by opening a Terminal and running the following command:
hdiutil create -volname MyApp -srcfolder /path/to/MyApp.app -ov -format UDBZ MyApp.dmg
Step 2 - Code sign the disk image
Code sign the disk image by opening a Terminal and running the following command:
codesign -s "Developer ID Application: YOUR NAME (TEAM ID)" --timestamp MyApp.dmg
Step 3 - Generate an app-specific password
Generate an app-specific password, refer to this Apple Support article. Note: this is a password that will be specific to the notarization application (xcrun altool) and not to the application being notarized. You therefore only need to do this once, but make sure you copy the generated password and save it somewhere.
Step 4 - Upload disk image to notary service
Note: When you notarize the container disk image, altool also notarizes the application inside, so you can skip the step of notarizing the application itself.
Upload the disk image file to the Apple notary service by opening a Terminal and running the following command:
xcrun altool --notarize-app --primary-bundle-id "<your identifier>" -u "<your email>" -p "<app-specific pwd>" -t osx -f /path/to/MyApp.dmg
The primary-bundle-id 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 the upload is successful you should receive output similar to the following:
No errors uploading 'MyApp.dmg'.
RequestUUID = 3af4e56f-162b-75bc-827f-7233f92bf20c
Step 5 - Check the notarization process
The notarization process generally takes less than 15 minutes, so you may want to check its progress from time to time by opening a Terminal and running the following command:
xcrun altool --notarization-history 0 -u "<your email>" -p "<app-specific pwd>"
When the notarization process completes successfully the above command will return information similar to the following:
Notarization History - page 0
Date RequestUUID Status Status Code Status Message
------------------------- ------------------------------------ ------- ----------- ----------------
2019-12-08 06:24:03 +0000 3af4e56f-162b-75bc-827f-7233f92bf20c success 0 Package Approved
You should also receive an email from Apple similar to the following for a successful notarization:
Dear <First_Name>,
Your Mac software has been notarized. You can now export this software and distribute it directly to users.
Bundle Identifier: com.example.MyApp.001
Request Identifier: 3af4e56f-162b-75bc-827f-7233f92bf20c
For details on exporting a notarized app, visit Xcode Help or the notarization guide.
Best Regards,
Apple Developer Relations
Step 6 - Staple the ticket to the disk image
The notarization process produces a ticket that tells Gatekeeper that your application is notarized. After notarization completes successfully, the next time any user attempts to run your application on macOS 10.14 or later, Gatekeeper will find the ticket online. This includes users who downloaded your application before notarization.
After step 5 receives the "Package Approved" status message, you should also attach the ticket to the disk image file using the stapler tool, so that future distributions include the ticket. This ensures that Gatekeeper can find the ticket even when a network connection is not available.
To staple the ticket to the disk image file, open a Terminal and run the following command:
xcrun stapler staple /path/to/MyApp.dmg
If the command completes successfully, the output should be similar to:
Processing: /Path/to/MyApp.dmg
Processing: /Path/to/MyApp.dmg
The staple and validate action worked!
Step 7 - Verify notarization of the disk image
To verify the notarization of the disk image, open a Terminal and run the following command:
spctl -a -vv -t install MyApp.dmg
A successful verification of the notarization process should produce output similar to the following:
MyApp.dmg: accepted
source=Notarized Developer ID
origin=Developer ID Application: <Developer Name> (<TEAM_ID>)
Step 8 - Verify notarization of the application
To verify the notarization of the application, install the application, open a Terminal and run the following command:
spctl -a -vv /Applications/MyApp.app
A successful verification of the notarization process should produce output similar to the following:
/Applications/MyApp.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: <Developer Name> (<TEAM_ID>)
Important: test the application by putting it in the Applications directory. It's treated differently by the Gatekeeper when in the "installed" location.
Alternatively, the Apple-recommended way to verify the notarization of an application is to open a Terminal and run the following command:
xcrun stapler validate MyApp.app
A successful verification of the notarization process should produce output similar to the following:
Processing: MyApp.app
The validate action worked!
I'm trying to codesign my macOS screensaver project to get rid of the "unidentified developer" warning message. Both Apple's documentation and this person on Apple's forums say that you should use the "Developer ID Application" signing certificate to do it. But that doesn't appear to work for me.
When I follow Apple's instructions on how to test for proper signatures the response I get is as follows:
Screensaver.saver: rejected (the code is valid but does not seem to be an app)
My signing settings look like this:
I'm not sure what else I should try at this point. Mostly I'm worried about the rumor future mac apps will have to be signed/notarized and what does that means for screensavers?
Here are additional notarization notes:
You can’t notarize the .saver directly, but you can in a round-about-way notarize a ZIP file, which is how I distribute my screen saver. Here are the steps I use for my simple saver, your mileage will undoubtably vary:
/usr/bin/codesign -f -o runtime --timestamp --sign “insert Developer
ID Installer certificate identifier here” XYZZY.saver
compress the code signed .saver e.g. XYZZY.saver.zip
/usr/bin/xcrun altool --verbose --notarize-app --primary-bundle-id “insert identifier here" -u “xyzzy#plugh.com" -p “insert app-specific PW for your Apple ID here" -t osx -f XYZZY.saver.zip
Aside: store the App-specific password in your keychain and
reference it from the command line like this:
/usr/bin/xcrun altool
--store-password-in-keychain-item
"AC_PASSWORD" -u xyzzy#plugh.com -p “insert App-specific PW from Apple here”
wait for notarization, check status like this:
/usr/bin/xcrun altool --notarization-history 0 -u “xyzzy#plugh.com"
-p "#keychain:AC_PASSWORD”
While you can notarize a ZIP archive, you can’t staple the
notarization ticket to it directly. Instead, run stapler against
each individual item that you originally added to the archive. Then
create a new ZIP file containing the stapled items for distribution.
/usr/bin/xcrun stapler staple XYZZY.saver
Re-zip the saver and
distribute
Just in case someone else stumbles in here...
For now I've realized that a good way around this is to create an installer package and then sign that following Apple's instructions.
I ended up using some free software called Packages to create the installer. After building the installer, I copied it to another folder and used the following command to sign it.
/usr/bin/productsign --sign "<Name of Developer ID Installer Cert in Keychain>" source.pkg destination-signed.pkg
Hope this helps someone out there. As far as I can tell this gets around the unidentified developer warning.
I develop a Mac app with Qt5, so outside Xcode. I want GateKeeper to allow my app to run on clients' computers rather than issuing the "Can't be opened because the identity of the developer cannot be confirmed" warning.
I have successfully digitally signed the app but GateKeeper still comes with this complaint. I have an Apple developer certificate (I am the Team Agent) and my keychain says it is valid. I also have installed two Apple root certificates.
I use the command line utility codesign to digitally sign all the binaries inside the app folder and in addition I digitally sign the app folder itself. In all cases the response of codesign is informative and displays no error. With codesign I can check that indeed all the binaries are signed, running
$ codesign --verify --deep --verbose=2 MyApp.app
shows that all binaries are validated. And in addition it reports:
MyApp.app: valid on disk
MyApp.app: satisfies its Designated Requirement
Running:
$ codesign -v --verbose=4 --display MyApp.app
gives
Executable=/Users/xxx/trunk/yyy/deploy/release/MyApp.app/Contents/MacOS/MyApp
Identifier=aaaa.MyApp
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=12461 flags=0x0(none) hashes=616+3 location=embedded
Hash type=sha1 size=20
CDHash=d1c12c783dac0e8d9a2b749fb896b11558cec8b6
Signature size=8532
Authority=Developer ID Application: XXXXX
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=29 jul. 2015 12;04:40
Info.plist entries=8
TeamIdentifier=YYYYY
Sealed Resources version=2 rules=12 files=10
Internal requirements count=1 size=180
which seems OK.
Running
$ spctl -a -t exec -vv MyApp.app
on all binaries gives as result
MyApp.app: accepted
source=Developer ID
origin=Developer ID Application: XXXX
which also seems OK
Running the XCode command line tool check-signature
on the app or on the binaries inside the app folder:
$ ./check-signature /Users/xxx/trunk/yyy/release/MyApp.app
gives as result
(c) 2014 Apple Inc. All rights reserved.
YES
which in all cases is the desired result.
But GateKeeper still does not accept the app and complains about the fact that the developer cannot be confirmed.
[added by author on Friday July 17, 2015]
I think I have found the problem. I do not know whether it is a feature or an OSX bug. I was helped a lot by stackoverflow question 19551298.
Whenever a file is downloaded from the internet it gets an extended file attribute com.apple.quarantine associated with it. When double-clicking on this downloaded file in Finder, GateKeeper has two possibilities:
When the file is not signed it issues the "Unidentified developer etc" message
When the file is digitally signed it issues the "Developer cannot be confirmed etc" message
In both cases the MessageBox has only one button, an OK button. When this button is clicked nothing happens, apart from the MessageBox closing.
If the extended attribute is deleted (xattr -d) the applications runs, signed or not.
The behavior is different when the applications is started by right-mouse-button-clicking in Finder on the app and then click on the "open" menu action. Again one of the two messageboxes is shown, but now with an extra button to allow the user to open the app anyway. Again the only difference between signed and not signed is the "Unidentified" or the "Not confirmed" message. I do not expect my customers to be able to tell the differende. As a result signing the app is an exercise in futility.
On the basis of the Apple Support Documentation I expected another, much nicer behavior of GateKeeper when double clicking a downloaded app (perhaps the documentation is outdated, or I misread it):
if the app is signed GateKeeper should show a MessageBox with "Downloaded from the internet etc" and a button with "Proceed anyway?"
if the app is not signed a MessageBox with a single OK button and a text "Unidentified developer etc.."
Sorry for answering my own question, but I see no other way as editing the original question would lead to spaghetti text.
I finally solved my problem. First the credit: (i) The answer to my other stackoverflow question was very useful and (ii) I got very good (paid) advice from an official Apple developer, by filing a so-called Technical Support Incident (TSI).
On the basis of all this I am now able to give here a very concise recipe of how getting your Mac app successfully treated by GateKeeper. After detailing the recipe I will show what my original mistake was.
Goal: After having developed a Mac app outside Xcode to have GateKeeper issuing the warning "Downloaded from the Internet ..." with three buttons, one of which is "open".
Failure: When GateKeeper issues a warning with either the text ".. unidentified developer.." or the text ".. unconfirmed developer .. " with - in both cases - a messagebox with a single OK button.
Getting your app GateKeeper-ready involves three steps:
Make your app standalone with no unacceptable external dependencies. The only acceptable external dependences are system libraries. All other dependencies should have been copied to your MyApp.app folder. GateKeeper rejects any app that has non-system external dependencies
Binaries should not be located at illegal positions inside the MyApp.app folder. Libraries go into MyApp/Contents/Frameworks and the executable goes into MyApp/Contents/MacOS
All binaries inside MyApp should be digitally signed. Then the MyApp.app folder should be signed. For this signing an Apple "Developer ID Application ..." certificate is necessary
Our recipe is automatic. All the work is done by one script. In case of Qt Creator we use a qmake script where we access the system shell through the $$system command. When using either of the (Xcode) system commands codesign, spctl or check-signature we assume you have redirected stderr to stdout as outlined in answer to question . Otherwise you will not be able to catch the system response when running these utilities. In the following we will not explicitly show this redirection.
HERE IS OUR RECIPE
A. Making the app stand-alone:
copy (with a script) all the needed binaries to the MyApp.folder
run (with a script) install_name_tool -change and install_name_tool -id such that all dependences inside the app are of the relative type #executable_path/../MacOS.. or #executable_path/../Frameworks
run (with a script) otool -L on all binaries inside the MyApp.app folder and flag any illegal dependence, like "#rpath..." or absolute file paths not being system paths. Note that otool -L is not guaranteed to find all dependencies. Plugins are often beyond the horizon of otool. That is why you need the next check.
start a terminal at the location "MyApp.app/Contents/MacOS". Run export DYLD_PRINT_LIBRARIES=1. Then run inside the same terminal window ./MyApp. Your terminal will fill up with over hundred loaded libraries. Check this list again for forbidden libraries (libraries present on your computer, but not on the computer of your customers).
proof of the pudding is in the eating. We use the MacInCloud virtual machines and check whether or not our app runs there. Alternative solution could be the Mac of a relative who is not a developer. Or you could also create a new user ("test") on your own Mac and copy the app to its Download (or Desktop folder, or ...). In the latter case you must temporarily rename the root folder of your IDE as otherwise the user "test" will find the missing binaries there.
B Signing the app
Signing: With our script we run codesign --force --verify --verbose --sign \"Developer ID Application: ....\" \"/path/to/binary\" on all the binaries in the app and then on the app folder itself. In each case the system response is caught. It should contain in each case the string "signed Mach-O thin".
Verification: Run (with a script) command codesign --verify --verbose \"/path/to/binary\" on each binary in your app and on the app itself and catch the system response. It should in each case contain the strings "valid on disk" and "satisfies its Designated Requirement".
GateKeeper check: Run (with a script) spctl -a -t exec -vv /path/to/binary\" on each binary and on the app folder itself. The system response is caught. It should contain in all cases the string "accepted source".
check-signature: Run (with a script) check-signature \"/path/to/banary\" on each binary and on the app folder itself. The system response is caught. It should contain the string "YES" in each case.
C External check
zip your app into a single zip file. Upload to one of your cloud servers
GateKeepers keeps a long list (typically hundreds of items) of exceptions on its general gate-keeper role. Your app must not be in that list if you want to test GateKeeper. Rather than editing this list a much simpler trick is creating a new user on your Mac. Log in to that user and download the zip file from the Internet cloud server. Finder will automatically uncompress it. Click on it. If GateKeeper tells you that it can open the application but it warns you at the same time that it is downloaded from the Internet, it is time to grab a (white) beer.
Here the desired GateKeeper warning:
My mistake
I did much of the installing and signing without explicitly checking the result for each binary. After that I would use otool -L on a number of binaries but not on all. I missed the fact that upgrading to Qt 5.5 from an earlier Qt version the binary libqminimal.dylib has acquired an extra dependency, viz.: QtDBus. I had not noticed it, but GateKeeper did.
Qt developers might wonder why we not just use macdeployqt for deploying Qt application on a Mac. In the first place we do not like not to use ill-documented black-box utilities. On Internet fora there are quite a number of people reporting issues with macdeployqt. In addition the Qt libraries can have different install locations (as reported by otool-L) when comparing different Qt versions. When we have a new Qt version our script will immediately start to yell about forbidden dependencies. In this way we get information about what has changed in this new version.
adlag's question and self-answer was invaluable in helping me overcome the same issue. However, as good as his recipe is, some statements are not quite right, so I'd like to offer a few additional points.
It's not necessary to replace #rpath entries in your binaries and dynamic libraries with #executable_path statements. #rpath statements are fine so long as the actual rpath entries embedded in the binaries are not absolute. You can find plenty of valid Qt app bundles that use rpath. You can make it work doing what adlag said, but you may be making work for yourself.
See jil's comment above for how to use otool -l $file | grep -A2 LC_RPATH and install_name_tool -delete_rpath $path $file to inspect and remove the embedded paths in your binaries and libraries
See https://developer.apple.com/library/content/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG207 for a clear explanation of why GateKeeper complains about paths in your binaries, and how you can see the specific complaint in syslog.
If you have a problem with absolute paths, you should first try to fix your build, rather than use install_name_tool after the fact.
If you're using cmake, this is likely helpful: https://cmake.org/Wiki/CMake_RPATH_handling#Mac_OS_X_and_the_RPATH
Don't run spctl -a -t exec -vv /path/to/binary on dylib files. You will get errors about the resource envelope. This is expected, and not a problem.
In my experience, macdeployqt works fine. I solved the problem by changing my build, such that the absolute paths did not get into the offending dylib file (libquazip). I still used install_name_tool to remove the absolute paths to the Qt installation. I then used macdeployqt to create the bundle, sign the bundle and create the DMG file.
My two bits:
To really verify codesigning, I had to either upload my DMG to a
server and download it using a browser or set the quarantine attribute manually:
APP_PATH="Any.app"
xattr -w com.apple.quarantine '0081;5a37dc6a;Google Chrome;F15F7E1C-F894-4B7D-91B4-E110D11C4858' "$APP_PATH"
xattr -l "$APP_PATH" # You should see the quarantine attribute here
open "$APP_PATH"
If your app is correctly signed, you should see a system dialog with
an "Open" button.
I found the value of the quarantine attribute by looking at another
.app downloaded from the internet. I don't know what the value
means.
I don't really understand why the spctl command says "accepted" even
if the Gatekeeper service denies opening the app.
I had the "unidentified developer" message box because my Qt frameworks were referenced as "#rpath/QtCore.framework". Changing it to "#application_path/../Frameworks/QtCore.framework" using the install_name_tool fixed the issue in my app.
Figured out the problem after lot of tries.
In my case:
The Pop Message - damaged application came due to libraries were missing.
I Had created .app file using QT.
To generate dmg i was using deploymacqt command tool.
deploymacqt tool creates dynamic libraries inside .app, so basically if we codesign before creating dmg, this alter will manipulate code sign.
So the proper fix is.
# Create dmg using
deploymacqt <yourapp.app> -dmg
# Open resulted dmg file, copy <yourapp.app> to different folder(let's say /Documents/<yourapp.app>)
# Codesign the /Documents/<yourapp.app> using
codesign --deep --force --verify --verbose --sign "Developer ID Application: <developerid>" <yourapp.app>
# Verify using
codesign --verify --verbose=4 <yourapp.app>
* you should see something like this
<yourapp.app>: valid on disk
<yourapp.app>: satisfies its Designated Requirement
# Now create again the dmg file using dropdmg(https://c-command.com/dropdmg/) application, download, install dropdmg. set the cofiguration preferences with your developer id certificate in signing option.
# drag and drop <yourapp.app> to dropdmg app, wait for creation of dmg to complete. voila you have now successfully created dmg with proper developer id certification.
# verify resulted dmg again using
codesign --verify --verbose=4 <yourapp.dmg>
# you can also verify with gatekeeper
spctl -a -t exec -vv <yourapp.dmg>
once you are done with these, you will not see pop message saying app is damaged or broken or unidentified developer.
You need to verify all your rpath with command line otool -l of your executable and yours Frameworks. If you have a local rpath (ex: /user/name/Qt/) in your executable delete it (with this command install_name_tool -delete_rpath).
I am porting a .NET application to OS X using the Mono Framework. The application works fine, and we have everything done except for packaging. I am packaging a standalone Mono build inside the bundle to avoid dependencies, and using this tool for the job: https://github.com/OutOfOrder/MonoKickstart
The bundle structure we are using is like this:
OurApp.app
\-Contents
+-Info.plist
+-MacOS
| +-osx - native libraries for osx
| +-mono - mono config files
| \ ... - the OS X kickstart binaries, the .exe file, C# .dlls
\-Resources/
\-icon.icns
The bundle runs fine when OS X's Gatekeeper functionality is set off, but when trying to sign it to get it run always, I run into problems...
$ codesign -s "3rd Party Mac Developer Application: Our Certificate" --force --deep --verbose OurApp.app
OurApp.app: bundle format unrecognized, invalid, or unsuitable
In subcomponent: OurApp.app/Contents/MacOS/mono/4.0
All right, I'll remove the mono directory temporarily just to see if it proceeds then:
$ codesign -s "3rd Party Mac Developer Application: Our Certificate" --force --deep --verbose OurApp.app
OurApp.app: signed bundle with Mach-O universal (i386) [org.ourcompany.ourapp]
Success! Or so do I think, but when I'll try to run the app, it still says it's still blocked by Gatekeeper. And when I run
spctl -a -v OurApp.app
OurApp.app/: rejected
So what gives? It says it signed the bundle, and using the --deep parameter, it should've signed all the libraries and such, if I understood right. What should I do to make this work?
Update:
Tried to sign the files one by one with this.
codesign -s "3rd Party Mac Developer Application: Our Certificate" --force --verbose OurAppExecutable.bin
But it refused to do it, because of the "subcomponents" (Even if I'm not using --deep).
I finally got it to sign it by moving everything else but the actual binary file to Resources folder, and then signing the binary file, and then the app bundle.
But yet, it says:
spctl -a -v OurApp.app
OurApp.app/: rejected
source=No Matching Rule
Any further insights?
I'm not sure if --deep is supposed to work or not, but it's not what we use in Xamarin Studio when codesigning Xamarin.Mac projects. What we do is codesign each native library individually and then codesign the app bundle itself.
Hope that helps.
Update: This may be the problem:
OurApp.app: bundle format unrecognized, invalid, or unsuitable
In subcomponent: OurApp.app/Contents/MacOS/mono/4.0
The problem might be that MonoKickStart is not generating correct Mac executables?
I got this to work afterwards. The trick was to keep just the one and only executable file in the MacOS dir, and have everything else in the Resources dir. This way we didn't need to sign all the other things.
Another blunder - not the source of this problem, but of an another one - was that we were trying to sign it with a wrong kind of certificate. "3rd Party Mac Developer Application" is apparently used for App Store submissions. The name is kind of misleading, so it's easy to mess that up. More info: Difference between “Mac Developer” and “3rd Party Mac Developer Application”
I paid the $99 to get a developer license w/ Apple. Installed Xcode 4.3. Went to the Organizer and "Provisioning Profiles" and refreshed to download my code signing certificate. Checked my Keychain Access and confirmed that I have "3rd Party Mac Developer ", "Developer ID" and "Mac Developer *" certificates.
At this point the documentation from apple mentioned pulling up your project files. I'm using Wineskin to package my Windows application, so I don't have an Xcode project. I have a .app file produced my Wineskin. I'd like to codesign the .app file that Wineskin produced for me.
I tried:
codesign -s "certificate name" /path/to/my.app
I tried all the possible certificate names that had my name and the word "Application" in them from my Keychain Access.
Every time I get the error "/path/to/my.app: object file format unrecognized, invalid, or unsuitable"
Any idea on how to get past this error? Am I even attempting the proper command? Or is there a different way I should go?
To summarize the comments to my questions, here are the commands I run to sign my .app file for Gatekeeper:
export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/usr/bin/codesign_allocate"
codesign --force --sign "Developer ID Application: <my name>" /path/to/my.app
Thanks, Gordon Davisson and JWWalker!
(edit) If this fails, I realize that installing the "Command Line Tools" from within XCode was needed.
EDIT:
To verify
$ codesign -dv --verbose=4 my.app
In Apple ID account make sure you have few types of certificate?
Make sure you have a valid developer certificate and a private key in your keychain.
If you have some problems with it, the certificate should be revoked via developer.apple.com and generated from the scratch (XCode > Accounts > Manage Certificates).
Then you can use codesign:
codesign --force --deep --sign "Apple Development: FirstName LastName (XXXXXXXXXX)" /Applications/ApplicationName.app
Before using codesign command
Install Command line tool for Xcode from https://developer.apple.com/downloads/index.action section.
(You should have a developer account to download Additional Tools.)
Please check for any hidden file in Payload folder like (.DStore) and if there is one please remove it
Navigate to Payload folder via terminal using cd command
Type ls- a command on terminal
if there is any hidden file apart, delete it by rm -f .DStore
This solution worked for me so please give a try....