10.14 Hardened Runtime and App Notarization

Apple’s introducing a new higher level of code-signing for apps. See https://help.apple.com/xcode/mac/current/#/dev88332a81e

I’m assuming this is something we can not do with Xojo apps as it requires one to build using the “Hardened Runtime” in Xcode?

This is what I have found out so far about the hardened runtime…

  1. The app must be built using the macOS 10.14 SDK. Not sure if that would apply to the executable, the Xojo Framework and / or 3rd party plugins.

  2. All dynamically loaded modules (plugins) have to be signed and by the same authority or Apple.

  3. JIT executable code must have the mmap flag MAP_JIT set. This could affect XojoScript.

  4. The app must have a set of entitlements.

As for notarising the app I found some information here:
https://twitter.com/rosyna/status/1004418504408252416
The only step that appears to be missing is downloading the notarised app afterwards via the command line.

I used to be a big security advocate, but this is not security. It just defines an additional, yet indirect effort by Apple to lock other players out of the app game. The only good news is that they have still provided a mechanism for the end user to turn the requirement of that “feature” off.

11 of our largest clients are seriously examining Windows and Linux for large scale Mac replacements for FY 19 just because of things like this compounding the issues that heir IT teams had to deal with in the moves to 10.11 and 10.13 already.

  1. AFAIK this applies to the Xojo framework and the plugins. Since Xojo and the plugin authors want at least some backward compatibility this alone will make problems.

  2. Sigh, that stupidity again.

The workflow from Twitter seems very painful. I still have a Radar issue open for using XCode. For all my other issues I have had some communication. On this one there was only silence.

Do I understand it correctly Xojo compiled apps cannot Notarized?
If yes, this is about the end for Xojo macOS.

If we need to tell out customers to disable things in macOS to run our apps, we are going to loose a lot of customers for sure.

Not good…

You can’t notarize your apps in XCode. The process described in the Twitter messages is horrible.

And you can’t notarize your apps anyways, because all of us need at least some time of backwards compatibility with older versions of macOS. You would need a special version of Xojo and of the plugins that use system functionality AFAIK. I’m not very deep into these topics but this is my understanding.

I thought this is all optional for now, so not a reason to worry for now?
And later we probably get someone to write a tool to do all the steps for Xojo apps without Xcode, e.g. using command line.

Yes and no. Yes, it’s “optional” right now. But with the 64bit warning we have seen again that Apple likes to scare users. Who knows what stupid message Apple will show to the users when the app is not notarized?

A task for App Wrapper by @Sam Rowlands ? :slight_smile:

Sam -> “Monetarizer” application?

I’ve been paying attention from the sidelines on this new “security” mechanism, I don’t see that it will be enforced soon, I actually expected the App Sandbox to be enforced outside of the App Store by now.

Once the dust has settled and the complete process has been revealed, then I attempt to implement it into App Wrapper.

Here is what seems to have worked for me for a Xojo app distributed via a signed DMG.

  1. Open the Application Loader developer tool in Xcode. Log in to your developer account and check the box to remember the login so a keychain entry is created. This allows you to skip entering your password in subsequent steps.

  2. Code sign your app with the hardened runtime option (you may need entitlements if you are accessing any protected resources). For example:

$ codesign --force --options runtime --deep --sign "Developer ID Application: COMPANYNAME" MYAPP.app
  1. Bundle the app into a signed DMG for distribution. Steps omitted.

  2. Upload the signed DMG for notarization:

$ xcrun altool --notarize-app -f MYAPP.dmg --primary-bundle-id MYBUNDLEID -u MYAPPLEID -p @keychain:"Application Loader: MYAPPLEID"
  1. A RequestUUID is returned. Periodically check the status of the notarization until it has completed:
$ xcrun altool --notarization-info REQUESTUUID -u MYAPPLEID -p @keychain:"Application Loader: MYAPPLEID"
  1. When the notarization is complete, staple the ticket to the DMG:
$ xcrun stapler staple -v MYAPP.dmg
  1. After installing your app, verify that it is notarized:

$ spctl -a -v /Applications/MYAPP.app MYAPP.app: accepted source=Notarized Developer ID

[quote=400988:@Christian Schmitz]I thought this is all optional for now, so not a reason to worry for now?
And later we probably get someone to write a tool to do all the steps for Xojo apps without Xcode, e.g. using command line.[/quote]
Probably becoming required sooner than expected: https://www.idownloadblog.com/2018/10/19/gatekeeper-future-macos-notarized/

[quote=400940:@Tim Jones]I used to be a big security advocate, but this is not security. It just defines an additional, yet indirect effort by Apple to lock other players out of the app game. The only good news is that they have still provided a mechanism for the end user to turn the requirement of that “feature” off.

11 of our largest clients are seriously examining Windows and Linux for large scale Mac replacements for FY 19 just because of things like this compounding the issues that heir IT teams had to deal with in the moves to 10.11 and 10.13 already.[/quote]
I know this is a necro’d thread, but here’s the deal with notarization. When you distribute through the app store, Apple scans your app for certain behaviors and automatically rejects before going to a human for review. The Developer ID program is good, but has no such protection. Malware can be signed and distributed outside the app store. Notarization combines the two. Users get the benefit of binaries that have been pre-scanned by Apple, while developers don’t have to distribute via the app store.

It’s not about locking anybody out. Well… except for malware developers.

Yeah, I also read it somewhere else. This is rumoured for macOS 10.14.1 , but my guess it will be for 10.14.2

Guess Sam has some work to do with AppWrapper. :wink: :wink: :wink:

[quote=410599:@Christoph De Vocht]Yeah, I also read it somewhere else. This is rumoured for macOS 10.14.1 , but my guess it will be for 10.14.2

Guess Sam has some work to do with AppWrapper. :wink: :wink: ;-)[/quote]
I don’t think that soon. 10.15 or 10.16 is more likely. There’s too many legacy apps to make the switch that quickly. You should start preparing your apps for the possibility, but it’s not “sound the alarm” stage yet.

Sounds like a lot of work. :frowning:
I have several commercial apps.
One comes in 3 flavours and a demo
I have been known to release an update per month.

7 notarisation sessions a month?
Ewww

[quote=410605:@Jeff Tullin]Sounds like a lot of work. :frowning:
I have several commercial apps.
One comes in 3 flavours and a demo
I have been known to release an update per month.

7 notarisation sessions a month?
Ewww[/quote]
Only you can best decide how to adapt your strategy, but maybe it makes sense to consolidate where possible? Rather than that one app coming in 4 editions, maybe the differences get handled by licensing so you only need to make a single build per update? Just an idea.

If Apple is going down this path, then we have to adapt. That’ll be easier for some than others.

email from Apple as of 3:30pm 19-Oct-2018

That’s exactly the email referenced in the iDownloadBlog story from above.