What entitlement for LiveCode macOS non-AppStore apps to pass notarization?

I’m a bit confused by your question. Notarisation does not require that your app be sandboxed, and thus a notarised app can do pretty much anything any non-notarised app can do.

The only security enhancement required by notarisation is the hardened runtime. That opts you in to a bunch of default security enhancements but there are entitlements to opt you out of them if necessary. See Hardened Runtime Entitlements.

These entitlements are like App Sandbox entitlements: You do not need to whitelist them via a provisioning profile from Apple. Rather, you can just add them to your

.entitlements

Is that insufficient? If not, can you explain what your app needs to do and is being blocked?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

This is probably something you should ask the LiveCode people about. There is a page describing signing and uploading apps to the Mac App Store. So if LiveCode can generate sandboxed apps, it should be able to do Notarized apps. I'm not sure you you would get LiveCode to request the hardened runtime. That's why I suggest you ask them. That is the downside of using those 3rd party tools. You become dependent on them in situations like this.

Once you do get it linked with the hardened runtime, it should be pretty easy to test it. You'll know right away if you need an entitlement.

As far as Notarization goes, think of it like soccer. You know how those world-class, professional athletes will sometimes fall over writhing in pain after an opponent brushes up against them? That is pretty much how some Mac developers are reacting to Notarization. Don't fall for the hype. It is easy and makes a lot of sense for you and your customers.

Love it! I wrote and maintain the page describing signing and uploading apps to the Mac App Store (just because it took me and others forever to figure it out). Trying to write one for Notarized apps that don't go into the App Store and so far, I've been unsuccessful in getting it to work. But it is totally amusing (I am chuckling about it) to be referred to my own page.

Let me see if I am understanding.

An app in the App Store with a generic sandbox=true entitlements file is allowed to do a limited number of things. Want to open files to read and write, you need to add an entitlement. With each capability, an entitlement might need to be added.

An app that is not in the App Store, sandbox=false, can do anything except for the stuff prohibited by Hardening. Opening and writing to a file does not require an extra entitlement as long as the app is Notarized and not distributed via the App Store. There are a small number of things that Hardening prevents and to do those in an app not distributed through the App Store, one must add those entitlements to bypass generic hardening.

So if I understand correctly, a hardened non-App Store app that includes the codesign terminal command "--option=runtime", can read and write to any disk files with an entitlements file of:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>com.apple.security.app-sandbox</key>

<false/>

</dict>

</plist>

Is this correct?

(Still voting for a flag in the entitlements.plist to tell the system to log entitlement violations as they occur and detail what exact entitlement is missing.)

(BTW, Is there a shorthand way of referring to "apps that are distributed through the App Store apps" and "apps that are not distributed through the App Store"?)

Perhaps you shouldn't find it so funny. If you are the one having to write that support document, then perhaps LiveCode is not giving you the support you need. I know nothing about that product. Using the hardened runtime is just a flag for the codesign tool. But I have no idea how you would configure LiveCode to issue that flag. I saw something on that page (that you wrote) about using Application Loader. I have no idea how Application Loader works. I use Xcode and it does everying. I have one button to click.

I suggest creating an app in Xcode and looking at the Hardened Runtime settings in the Capability tab. That will give you a better idea of just what entitlements are necessary under which conditions. For my app, the only entitlement I need is Apple Events. Given LiveCode's description on the web site, you might need some of those more esoteric Hardened Runtime entitlements. There is no way for me to tell.

Keep in mind that all of this is over and above any built-in Mojave security restrictions. In no case will you EVER be able to "read and write to any disk files".

The hardened runtime will allow you to Notarize your app to pass Gatekeeper. That's all. You will have to figure out which entitements you need to make your app functional. Your app will then be able to read and write to any safe, user-accessible locations. Some locations are restricted by both Mojave security settings and UNIX security settings. If your app wants to access private user information, you will have to ask the user to allow Full Disk Access. If your app wants full access to certain system directories, then it may need to run as the root user or have some safer option to enable some form of root access. But even with all of that, some locations will still be restricted in some ways. If that is a problem for you, then you should probably choose a different platform. At least LiveCode would make that easier to do.

Is there a shorthand way of referring to "apps that are distributed through the App Store apps"

Mac App Store apps.

and "apps that are not distributed through the App Store"?

Developer ID apps.

Still voting for a flag in the entitlements.plist to tell the system to log entitlement violations as they occur and detail what exact entitlement is missing.

Voting with Radar? Or voting here? Because the former is more likely to receive the attention of the engineering team responsible.

Having said that, there is already a fairly comprehensive sandbox violation reporting mechanism. To see such violations, run the Console app and set up a search for log entries with the subsystem of

com.apple.sandbox.reporting

violation

This isn’t exactly what you want, for a couple of reasons:

• It just reports the violation and doesn’t tell you exactly what entitlement you need.

• It only reports sandbox violations, which won’t help if your app is not sandboxed. Hardened runtime violations are also reported in the system log, but they are harder to spot.

Reporting the entitlement is tricky because of the interaction between layers in the system. However, it’s still reasonable to file an enhancement request for the features you’d like to see. I encourage you to include specific examples in your bug report, that is, create a test project that deliberately violates these restrictions, show how that’s reflected in the system log, and then explain how you’d like to see that improved.

Please post any bug numbers here, just for the record.

Let me see if I am understanding.

You’re statements are essentially correct but there are some points I’d like to clarify:

• You wrote:

  sandbox=false

  You would never do this. If you want to create an app that’s not sandboxed, you would simply not include the

  com.apple.security.app-sandbox

  entitlement at all. Including it, but set to false, should work but it’s definitely not the well-trodden path and it’s possible there might be some pitfalls on the way.

• Your analysis assumes that there are only two possibilities, Mac App Store apps, which are sandboxed, and Developer ID apps, which are not. The other two options also exist

  • It’s possible to have a Mac App Store app that’s not sandboxed. App Review requires that all new apps be sandboxed, but there’s still a bunch of non-sandboxed apps in the store.

  • It’s also possible, indeed recommended, for a Developer ID app to opt in to sandboxing. Most Developer ID apps don’t do this, but there are some exceptions.

So if I understand correctly, a hardened [Developer ID] app that includes the codesign terminal command

--option=runtime

, can read and write to any disk files with an entitlements file of:

Yes. However, per my first bullet above, I would leave off the

com.apple.security.app-sandbox

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you for your assistance. Literally could not have figured this out without your insights.

I've documented the steps that successfully got my macOS app, built using LiveCode, notarized for distribution outside of the Mac App Store as a Developer ID App. http://lessons.livecode.com/a/1088036-signing-and-notarizing-macos-apps-for-gatekeeper

Basically it is all the steps required to notarize an app not written in Objective-C or Swift, one that doesn't use Xcode as the Interactive Development Environment.

Alternatively, Late Night Software's SD Notary https://latenightsw.com/sd-notary-1-0-1-released/ can be used. Late Night Software produces Script Debugger for AppleScripts and they needed a way to Notarize AppleScripts turned into standalone apps. SD Notary is a general purpose tool whereas my lesson is composed of Terminal commands and is focused on LiveCode apps.