Hardened runtime with .pkg

Targets macOS
1

One of our existing apps is not working with Catalina. I think it’s failing now because Apple have enforced hardened runtime requirements.

Currently our release steps are
1, Build with xojo

2, Create an installer in Packagemaker filename.pkg (as we have to include a kext file and scripts)

3, Sign app.pkg in terminal with code
productsign --sign “Developer ID Installer: xxxx (xxx)” /Users/xxx/Documents/Link/filename.pkg
/Users/xxx/Documents/Link/signedfilename.pkg

4, Notorize with appwrapper

This was all working until the last couple of weeks.

I understand I need to an entitlements.plist file with contents

<?xml version="1.0" encoding="UTF-8"?> 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

but I am not sure how to “bake” this into the app. Can I simply add this to the installer before creating the package?

Unfortunately the Mac we have is not able to be upgraded to Catalina (oh we do hate it when Apple do this), do I have to build the xojo app in Catalina or can I still do it in High Sierra?
Any thoughts?

2

If you work with AppWrapper anyways you can do steps 2-4 in AppWrapper, too.

I build in High Sierra and the app runs fine in Catalina. You really really should get a computer that can run Catalina.

3

Thanks Beatrix, unfortunately App wrapper doesn’t have support for kext installation so I can’t use it for everything.
I think I worked it out with help from https://forum.lazarus.freepascal.org/index.php?topic=46256.0

1, codesign
codesign -f -o runtime --timestamp -s “Developer ID Application: xxx” /linkto app/filename.app
codesign -f -o runtime --timestamp -s “Developer ID Application: xxx” /linkto app/filename.app/Contents/MacOS/*
codesign -f -o runtime --timestamp -s “Developer ID Application: xxx” /linkto app/filename.appContents/Frameworks/*

2, embed entitlements
codesign -f -o runtime–timestamp --entitlements /linkto/entitlements.plist -s “Developer ID Application: xxx” /linkto app/filename.app

3, now build .pkg

4, productsign .pkg
productsign --sign “Developer ID Installer: xxx” /linkto app/filename.pkg
/linkto app/signedfilename.pkg

5, notarize with appwrapper

Hope it helps someone

4

The reason it is not working is more than likely the amnesty apple had for non hardened runtime apps being notarized has ended. This was meant to run out around August last year but they extended until Jan this year. Basically you need to build with a version of Xojo with the hardened runtime, 2018rSomething and later, and then do a deep codesign after all your builds.

I build and release many apps through a pkg file without using the app wrapper, but I use Packages instead to build.
This is also not for app store either.
I build on Xojo 2019r1.1 on 10.14.6 and this works on Catalina just fine.

Not sure about entitlements, as I dont use them.

This is the process for my manual code sign process.

  1. Add a code script after build and add the follow logic
  • Run script “xattr -rc PATH_TO_APP” to clean out existing codesigning
  • Run script “codesign --force --options runtime --deep --sign ‘Developer ID Application: YOURNAMEHERE’ PATH_TO_APP/Contents/Frameworks/*.dylib” codesign any librarys, mbs etc
  • Run script “codesign --force --options runtime --deep --sign ‘Developer ID Application: YOURNAMEHERE’ PATH_TO_APP”
  1. Validate code signing using “spctl -a -t exec -vv PATH_TO_APP”

NOTE: if your source code is on a exFat drive you cannot codesign on it. You have to manually compress, move to local drive, codesign, compress and move back. I have a shared drive i work off between mac and windows using bootcamp and found this issue. I tried using NTFS for mac but xojo could not work with it for some reason (always readonly)

If you have more than one app, eg helper apps, you need to do the above with all of them.

  1. Build Pkg, Packages has built in codesigning with productsign so your above script will work

  2. Notarize

If you have a single team against your apple ID then use

xcrun altool -t osx -f SHELL_PATH_TO_PKG --primary-bundle-id com.yourcompany.yourappname --notarize-app --username APPLE_ID@EMAIL.COM -p APPLE_PWD

If you have mulitple teams then find your itc_provider and use

xcrun altool -t osx -f SHELL_PATH_TO_PKG -itc_provider YOUR_ITC_PROVIDER --primary-bundle-id com.yourcompany.yourappname --notarize-app --username APPLE_ID@EMAIL.COM -p APPLE_PWD

This returns UID on success and you can check the status with

xcrun altool --notarization-info UID -u APPLE_ID@EMAIL.COM -p APPLE_PWD

If there is a problem it will return an url to a log

When successful staple together

xcrun stapler staple SHELL_PATH_TO_PKG

  1. Compress, rename and upload to server.
5

The kext apocalypse has already started in the latest beta of 10.15.4. At least there was a warning this time.

6

That software is 32 bits only (if I read correctly their web site).

Catalina is 64 Bits only.

At last, beware.

Edit:
Parts of their web site is outdated, they seems to have a 64Bits version.

7

I would advise, not relying on --deep as we’ve encountered many failures with this option in the last few years. Instead if you’re going to sign with a script, explicitly sign each file and in reverse order of loading, i.e. the last executable to get loaded need to be signed first.

It’s why I spent almost 9 months building a (fast) code signing engine, but as OP points out, App Wrapper isn’t designed to work with ktexts, mind you they’re on life support for the moment, and soon to have the plug pulled.

8

Not to hyjack this thread, but what is happening with kext’s? I assume we’re talking about kernel extensions? I use a couple in one app that allow the HID system to recognize a couple of USB devices. There is no code in them or any executable in them at all, it is just a plist file with the manufacturer and decice ID’s in them so that the system will expose them to the standard USB HID functions. Is this going away now? Whats the new cruelness for defining such a thing? If not applicable to this thread feel free to message me or something even just a link to info at Apple would be welcome as my initial searching was a fail. Too many “hackintosh” articles out there to find the actual info I was looking for!

9

I think it’s point 1 from here: https://www.sentinelone.com/blog/7-big-security-surprises-coming-to-macos-10-15-catalina/ .