Demystify code signing and its importance in app development. Get help troubleshooting code signing issues and ensure your app is properly signed for distribution.

Posts under General subtopic

Post

Replies

Boosts

Views

Activity

Offline App
Hello, I'm new at developing an ios app, but I have created a basic app, I plan to use just for me using xcode and the language swift. I intend to use this app, to display a video and images on ipads that will be used as KIOS on a trade show. I don't need this app to be published on the app store as I intend to use it solely for my use. Is there a way I can do something like this that won't be restricted with the 10 days restriction? I learned xcode/swift as little as I could to create the app, but now I'm limited to the 10 days, and only 3 devices. Is there a way I can create an offline app, that doesn't have the all the restrictions? I plan to use these ipads over and over again on tradeshows to display my work.
Topic: Code Signing SubTopic: General
1
0
566
Dec ’24
Testing a Notarised Product
To ship a product outside of the Mac App Store, you must notarise it. The notary service issues a notarised ticket, and the ultimate consumer of that ticket is Gatekeeper. However, Gatekeeper does not just check the ticket; it also applies a variety of other checks, and it’s possible for those checks to fail even if your notarised ticket is just fine. To avoid such problems showing up in the field, test your product’s compatibility with Gatekeeper before shipping it. To do this: Set up a fresh machine, one that’s never seen your product before. If your product supports macOS 10.15.x, x < 4, the best OS version to test with is 10.15.3 [1]. Download your product in a way that quarantines it (for example, using Safari). Disconnect the machine from the network. It might make sense to skip this step. See the discussion below. Install and use your product as your users would. If the product is signed, notarised, and stapled correctly, everything should work. If not, you’ll need to investigate what’s making Gatekeeper unhappy, fix that, and then retest. For detailed advice on that topic, see Resolving Trusted Execution Problems. Run this test on a fresh machine each time. This is necessary because Gatekeeper caches information about your product and it’s not easy to reset that cache. Your best option is to do this testing on a virtual machine (VM). Take a snapshot of the VM before the first test, and then restore to that snapshot when you want to retest. Also, by using a VM you can disable networking in step 3 without disrupting other work on your machine. The reason why you should disable networking in step 3 is to test that you’ve correctly stapled the notarised ticket on to your product. If, for some reason, you’re unable to do that stapling, it’s fine to skip step 3. However, be aware that this may cause problems for a user if they try to deploy your product to a Mac that does not have access to the wider Internet. For more background on this, see The Pros and Cons of Stapling. [1] macOS 10.15.4 fixes a bug that made Gatekeeper unnecessarily strict (r. 57278824), so by testing on 10.15.3 you’re exercising the worst case. The process described above is by far the best way to test your Gatekeeper compatibility because it accurately tests how your users run your product. However, you can also run a quick, albeit less accurate test, using various command-line tools. The exact process depends on the type of product you’re trying to check: App — Run syspolicy_check like this: % syspolicy_check distribution WaffleVarnish.app This tool was introduced in macOS 14. On older systems, use the older spctl tool. Run it like this: % spctl -a -t exec -vvv WaffleVarnish.app Be aware, however, that this check is much less accurate. Disk image — Run spctl like this: % spctl -a -t open -vvv --context context:primary-signature WaffleVarnish.dmg Installer package — Run spctl like this: % spctl -a -t install -vvv WaffleVarnish.pkg Other code — Run codesign like this: % codesign -vvvv -R="notarized" --check-notarization WaffleVarnish.bundle This command requires macOS 10.15 or later. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2024-12-05 Added instructions for using syspolicy_check. Made other minor editorial changes. 2023-10-20 Added links to Resolving Trusted Execution Problems and The Pros and Cons of Stapling. Made other minor editorial changes. 2021-02-26 Fixed the formatting. 2020-04-17 Added the section discussing spctl. 2020-03-25 First version.
0
0
6.5k
Dec ’24
Can an application signed with "com.apple.security.cs.disable-library-validation" be published as trusted?
I am working on releasing my macOS arm64 app. My problem is that after the user downloads the dmg, double-clicking my.app in the dmg, a Gatekeeper pop-up box will appear with a warning that the developer cannot be verified. Question: Can an application signed with "com.apple.security.cs.disable-library-validation" be published as trusted? If yes, what steps have I missed? If not, can I get an official response from Apple? (Because I referred to this post, it seems to mention that it is possible to publish trusted software.I have looked up similar questions on the forum and tried many things, but nothing works. ) Here are my steps: Use the codesign to sign my.app. Because my app needs to access third-party dynamic libraries, entitlements.plist contains a "com.apple.security.cs.disable-library-validation". After the "codesign -dvvv" check, the signature was successful.✅ Use the "xcrun notarytool" command to notarize my app, and the status is displayed as accepted.✅ Use "xcrun stapler staple" to attach the notarization to my app, and it returns success.✅ Use the "spctl -a -v " command to verify whether my app has passed Gatekeeper, and it returns that it has passed.✅ Then I packaged my.app into a dmg, and then attached the notarization mark to the dmg, which was successful.✅ I completed the above steps and distributed the dmg. When I downloaded the dmg as a user test and double-clicked my.app in it, the Gatekeeper pop-up box still appeared, and the developer cannot be verified.❌
3
0
704
Dec ’24
New application certificate fails to codesign binary file with error: "Warning: unable to build chain to self-signed root for signer <certificate> <filepath>: errSecInternalComponent"
Platforms: Ventura and Big Sur Steps to Reproduce: Create new application and installer CSRs with keypairs Generate new certificates in Apple web portal Repackage certificates as .p12 using exported private keys since they are not referenced in keychain app by default. Import certificates into MacOS Keychain Set certificate access to "Always Trust" for all certificate uses Sign binary fails using "codesign --force --sign " Sign installer package succeeds using "productsign --sign Additional Info: The private keys ware initially not recognized by the Keychain application resulting a certificate without a private key "leaf" beneath them. To resolve it I exported the private key and repackaged certificate as a .p12 file. Both certificates appear "good" when evaluated for code signing The installer certificate shows an intermediate and root while the application certificate does not Repackaging as .p12 with expected intermediate and root did not resolve the issue Installing all available intermediates and roots from Apple did not resolve the issue Signing a test app with XCode succeeds In production, we sign using CMake so we need to be able to sign code from the command line with codesign.
1
0
805
Dec ’24
Unable to Write Files Within App Bundle After Codesigning and Notarization
I have already posted asking about this: [quote='768005021, CynthiaSun, /thread/768005, /profile/CynthiaSun'] Codesigned and notarized app cannot directly write files inside the app bundle... [/quote] But there are still some doubts that have not been answered. We use Qt to develop an application on the macOS platform, and we are attempting to perform code signing and notarization to ensure our the application is trusted by Apple. However, there are a few things that seem weird regarding this statement: "App bundles are read-only by design." Let me provide more details. Currently, when our application starts, it needs to create folder (e.g. Temp) in the root directory of the executable For example: Myapp.app/Contents/MacOS/Myapp ---> Myapp.app/Contents/MacOS/Temp The folder is designed for storing runtime logs or config files for our application. In the past, users may also modify the settings inside target folder if needed. However, the strange thing is that after the application is codesigned and notarized. When we double-click the application Myapp (a.k.a Myapp.app) in Finder, it could successfully launch and create the Temp folder inside the Myapp.app/Contents/MacOS folder. However, when we navigate and attempt to run the main application executable in command line mode (as our application supports this command line execution) $ cd Myapp.app/Contents/MacOS $ ./Myapp -h As our application will check if the root folder has write permission before starting (i.e., check if Myapp.app/Contents/MacOS is writable because we require to create Temp folder in the following steps) It pop up the error that folder does not have write permission. The aforementioned scenarios seems to conflict with this statement: "App bundles are read-only by design" (because when the application is launched directly by clicking in Finder, the Temp folder can be created successfully, but via the console command line, it cannot). I would like to confirm again if writing files in the notarized application MacOS directory is not allowed? If not, have any recommended approaches? (e.g., changing the folder to another directory). What causes the different results in these running scenarios? We are not concerned about breaking the signature after application launched, as it seems that macOS will add it to system trust list after first time successfully launch. (Download the app from internet --> System: it is an app downloaded from the internet. Are you sure want to open it...? OK --> Although our application creates the Temp folder after first launch, when we click the application second time, it could directly open the app)
2
0
616
Nov ’24