Installer Application Not Proceeding After Codesigning with Hardened Runtime Enabled

I'm encountering a peculiar issue with my macOS installer application when hardened runtime is enabled (--options runtime) during code signing, and I'm hoping to get some guidance on how to resolve it.

Issue Description: My installer application is designed to prompt users for system credentials upon launch. After entering the correct credentials and clicking "OK", users should see the next screen to proceed with the installation process. However, with hardened runtime enabled, the application stops responding after the credential entry step. The next screen, where users should proceed with installation, does not appear. If I codesign without using hardened runtime, my installer works fine. However it fails during notarization.

What I've Tried:

  1. I have reviewed Apple's documentation on hardened runtime and notarization to ensure I'm following best practices.
  2. I've checked the Console logs for any relevant error messages or warnings, but haven't found any conclusive information.

Additional Information:

  • The application is an installer built using bitrock installbuilder.
  • It relies on prompting users for system credentials using standard macOS authentication mechanisms.
  • Initially the installer is in tar.gz format which I extract to get .app file. This file is codesigned. Next I create a .DMG of the codesigned .app file and codesign the DMG before sending it for notarization.

Request for Assistance: I'm seeking guidance on how to address this issue with my installer application not proceeding after credential entry when hardened runtime is enabled. Are there any specific configurations, entitlements, or best practices that I might be missing? Or are there alternative approaches I should consider to ensure compatibility while still meeting Apple's security requirements for notarization?

Any insights or advice from your experiences would be greatly appreciated. Thank you in advance for your help!

Up vote post of DungenMaster Down vote post of DungenMaster
148 views
Posted by
DungenMaster
Reply
Add a Comment

Replies

The application is an installer built using bitrock installbuilder.

That makes things tricky. In the general case there’s no way to debug and fix hardened runtime incompatibilities in other folks’ code. Normally I bounce questions like this to the tool vendor’s support channel.

However, before I do that, I have a simple diagnostic I’d like you to run. If you run sample against your UI at the point that it’s stuck, what does the main thread backtrace look like?

Note You should be able to attach the sample output to your reply as a .txt file. Click on the paperclip icon and then choose Add File.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo

  • Tried some solutions I found online. The issue got fixed after using entitlements file during code signing process. The entitlements used were to disable the library validation. I tried looking system logs in console.app, tried 'log show' to look for error with my app name, tried using dynamic linker (dyld) but I am completely new to these things so I have no idea from where to start.

    How can I find the exact error? How can I figure out which library is causing the error?

    —
    DungenMaster
Add a Comment

I tried some solutions I found online and was able to fix the issue. The problem was resolved when I used entitlements to disable library validation.

 <dict>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
</dict>

However, I have no clue what the actual error was. I don't want to disable library validation without getting proper knowlegde of what I am doing; I want to understand why my installer (an .app file created using a Java project) doesn't work after being code-signed with hardened runtime. I want to identify the error.

Some solutions and documentation suggest that the dynamic linker can be used to obtain detailed error messages when library validation fails. According to the "Disable Library Validation Entitlement" documentation, "The macOS dynamic linker (dyld) provides a detailed error message when the system prevents code from loading due to library validation." Does this also apply to the app file or is it applicable for other type of files like jar? (I have posted another question related to this)

I'm completely new to these concepts. Could you please provide a detailed process on how I can retrieve error logs using the dynamic linker when the installer (.app) fails to open?

Can I use direct commands? Modifying the bundle to invoke dynamic linker will be extremely tedious task.

Posted by
DungenMaster
Up vote reply of DungenMaster Down vote reply of DungenMaster
Add a Comment