App Wrapper 3.9 and Harden Runtime

Targets macOS
1

Folks, I need some help. I’ve been working on adding support for this to App Wrapper, while it works, there’s a huge gray area and that’s the effects of this option. Please read this and if you have the time, try out the current App Wrapper beta with your Xojo made application and report any failures.

What is a Hardened Runtime?

My assumption is that it’s an App Sandbox Lite, now don’t get too upset, it’s not as restrictive as a full App Sandbox, but it still comes with restrictions.

What’s required?
Contrary to my earlier assumptions, it appears that all you need to make a “Hardened Runtime” is macOS 10.13.6 or newer.

What I need your help with
Because this new option does apply restrictions to your application, and I can not find any clear documentation to state exactly what restrictions it applies, the only way we can know for sure is to test applications with this option.

@Christophe de vocht found two issues.

  1. Decalres (and I assume plugins also) that interact with OS API MUST reference the correct framework, referencing the dylib directly fails.
  2. AppleScript is dead.

Assumption 2 maybe a little too harsh, as I would like to believe that it’s not dead, instead what I think you need to do is to add the correct entitlements. In the “Capabilities” section of App Wrapper, switch “App Sandbox” to “Entitlements Only” and then fill in the Apple Script details.

I was able to create a “Hardened” version of App Wrapper, which was still able to code sign applications. This is something that can not be done when App Wrapper is Sandboxed.

App Wrapper 3.9 Beta
Please download and test the beta of App Wrapper 3.9, it includes the following changes.

  • 64-Bit; it’s made with the latest Xojo and fully 64-Bit compatible.
  • Usage Descriptions; it includes support for usage descriptions (also required for 10.14). Apple’s documentation list 18 possibilities, with only 4 marked as macOS, yet I’ve added support for the ones that macOS developers have received rejections for not including.
  • “Hardended Runtime”; please note this currently only works when NOT using “Apple Temporary Engine”. If you run into problems when not using this, please let me know as I’m trying to remove support for Apple’s temp engine.

https://www.ohanaware.com/appwrapper/appWrapper3update39Beta.dmg

What about Notarization?
It will come, my primary focus at this point is to work on “Hardened Runtime” option, understand what the restrictions are, and to try to ensure that App Wrapper makes this transition as easy as possible. So for the week (at time of writing), I am only looking at this. I will look into Notarizing next week or after we have a better understanding.

Thank you for helping.

2

I did several tests and I was able to notarise with the new beta after code signing with the latest AppWrapper beta.
As Sam said, do not use the ‘Apple Temporary Engine’ which does not add the –option runtime.

3

It’s been quite a while since I had a look at AppWrapper. The app likes to confuse me. What is the problem:

Code signing works fine on the computer. The dmg should be signed. Should AppWrapper tell me this? Should I make a fresh dmg?

4

[quote=411257:@Beatrix Willius]It’s been quite a while since I had a look at AppWrapper. The app likes to confuse me. What is the problem:
[/quote]

Looks like one or more certificates are missing the private key. Those are essential for correct code signing (although you can do without it - but it will introduce issues).
Try to reinstall all your dev certs and make sure you have your private key (which is mandatory) for the certs.
If you do not have a back up of the private keys, you will need to request new certs, which is by no means funny to do, trust me.

I ones had this too and made several backups of the private keys. Ones bitten twice … :slight_smile:

5

Yes, the code sign diagnostics in AppWrapper tells me the same. I hate this signing sugar. Those certs should be somewhere. I just need to remember what to do with them.

6

The private keys can found in the Keychain. The below certs should have a private key attached.
Developer ID Application, Developer ID installer, 3rd Party Mac Developer Installer, 3rd Party Mac Developer Application.
If one is missing, your are in trouble and need to provide the private key.
As said, if you do not have it anymore, you will need to provoke the current installed certs and request new.

After doing this, backup backup backup, backup, … :slight_smile:

7

That explanation is way too short for my old brain. I’ll check later.

8

Two things;

  1. As @Christophe De Vocht says, your installer certificate is missing it’s private key. Please read the following article about purging and re-installing your certificates. https://ohanaware.com/support/index.php?article=purge_and_reinstall_codesigning_identities.html

  2. So the DMG signer is running into an error, something is claiming there is an error, but there’s no message. Please can you post the DMG online somewhere (unsigned is fine) and then use the e-mail support function on the App Wrapper menu to create a support e-mail and include the link to the unsigned DMG. I can then download it and attempt to sign it here and hopefully figure out what went wrong.

9

Signed my app with AW 3.9 on Mojave. Ran the resulting signed version. could see no problems with the signed app.
A couple of questions from the AW Diagnosis…

I selected the “hardened” option but this seems to be saying it was not used

I don’t understand what this is telling me. This is only 1 of several plugins in the Plugins Folder of Xojo. Don’t know why its path would be wrong.

10

On the general pane, next to the code signature selector, do you have “Apple’s Temp engine” selected? If so, please try with out it enabled.

Because the path points to a file that doesn’t exist. Apple have gotten more and more restrictive over the years, and this is one reason that you can get an App Store rejection. @Christian Schmitz should be able to help you out here.