Fix macOS Catalina error when running the binary the first time

[tanis2000]

I've added macOS entitlements to avoid the application being blocked by Catalina when you run it the first time.

[Gargaj]

@alkama

[alkama]

I'm not sure that it's required (but I dont have Catalina on any of my macs).

From the documentation, it looks like this entitlement is only necessary when using the "Hardened Runtime" capability (which we dont rely on, since we dont notarise the app).

For the old good non notarised way in 10.14+, we already have code handling the request of that access. https://github.com/Gargaj/Bonzomatic/blob/master/src/platform_osx/Misc.mm#L80

@tanis2000 can you try not to enable hardened runtime and build the oldschool way?

[sacredbanana]

Wouldn’t notorising the macOS app actually be a good idea anyway?

[sacredbanana]

It’s a quick automated process where an Apple server does a quick scan for malicious code

[alkama]

I'm not sure GargaJ is willing to pay 100 euros per year to get an Apple developer certificate.
I dont know what happens if you stop paying for it. For now it doesn't seem to require a same developer to submit update of an app, but cant bet on the future.
It disables ability to debug the application in case of issues (get-task-allow disabled).
It's a very painful process if you wish to do it in CI.
I dont know how retro-compatible the produced binary is (10.9 would become minimum?).
You never know what further restriction they will request your app to comply with in the future to have it notarised, and how having it notarised in the past disqualifies you from "stopping to notarise", in case what they mandate goes wild (ex: they could very well demand you to support whatever architecture they make their macs on, or forbid you to use whatever api they consider deprecated:D opengl?).

Anyway, imho notarisation smells like a trap that brings 0 value.

[tanis2000]

@alkama I understand your concerns, but it looks like Bonzomatic is already being distributed as a notarized app through a homebrew's cask. That's how I found out this issue.
Who is maintaining the cask? Is he someone from the dev team here?

[alkama]

Not that I know.
Lets cross fingers that Apple never introduces a "same developer origin" ala iOS then.

[tanis2000]

@alkama sorry, I was completely wrong. I thought I had it installed through a cask but no, the issue is with the latest release here on github, this one: https://github.com/Gargaj/Bonzomatic/releases/download/2019-03-26/Bonzomatic_MacOS_GLFW33.zip

Is that release created automatically?

[Gargaj]

@alkama I understand your concerns, but it looks like Bonzomatic is already being distributed as a notarized app through a homebrew's cask. That's how I found out this issue.
Who is maintaining the cask? Is he someone from the dev team here?

First time I've heard of that. Gotta love opensource.

[alkama]

@tanis2000 Yes, I compiled that one.
It's not notarised so it indeed will refuse to launch the first time and you need to "right click > open" to disable gatekeeper on it.
It's also compiled on 10.14.
It'll be the same behavior as all the other apps that are not notarised :D So my bet is that users will just learn how to bypass it, like UAC on Windows Vista.

[tanis2000]

@alkama ok I get it. But would it make sense to keep those entitlements? I mean, they do no harm and they do not enable hardened mode by themselves.
We can also add com.apple.security-get-task-allow to allow debugging of the process if someone decides to compile it with hardened mode on.
Some popular products have this kind of entitlements to be able to distribute the app in hardened mode and still retain some control over what happens:

<?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.cs.allow-jit</key>
	<true/>
	<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
	<true/>
	<key>com.apple.security.cs.disable-library-validation</key>
	<true/>
	<key>com.apple.security.device.audio-input</key>
	<true/>
	<key>com.apple.security.personal-information.addressbook</key>
	<true/>
	<key>com.apple.security.get-task-allow</key>
	<true/>
</dict>
</plist>

We don't need all those, but the audio-input, get-task-allow and allow-unsigned-executable-memory look like good candidates.

[alkama]

I dont mind an added file that is unused/at rest. Apart from the fact that it's useless. The audio capability should work on Catalina since it's requested at runtime, and the one you list is only there for hardened runtime usage.

But the thing to investigate first is to know if the use of XCODE_ATTRIBUTE_CODE_SIGN_ENTITLEMENTS does impact the project generation, automatically enabling things we dont want enabled.

My uninformed bet is that it goes hand in hand with XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY or will default to the compiling machine's resident macOS Developer, and could very well make some "automatically sign" box checked (which might become a headache for people compiling Bonzomatic for themselves in Release).

[sacredbanana]

I don’t see harm in releasing both a notorised and non notorised binary to give people the option. And one of the Bonzomatic contributors with an Apple dev cert can be responsible for providing a notorised version shortly after each non notorised version is released. Id he happy to do it for example. I will be renewing my Apple dev certificate indefinitely since I have iOS apps in the AppStore and so is one of my sources on income

[alkama]

My take would more be to keep this PR handy for the day Apple forces all apps to be notarised.

@sacredbanana i wouldn't call any signing process quick and automated. Especially when it's asynchronous and has important results containing future deprecation messages that are meant to be analysed by a human being. But maybe it's just me :D

[alkama]

@sacredbanana Can you assure that doing so would not result in non-notarised version being instantly flagged as malware, today, and in the future?

[sacredbanana]

Pretty sure Apple wouldn’t flag something as malware for being a non notorised version because that would be straight up lying

[tanis2000]

@alkama the good news is that XCODE_ATTRIBUTE_CODE_SIGN_ENTITLEMENTS works in a way that it only creates an entry called CODE_SIGN_ENTITLEMENTS in the project's settings. This is how CMake is designed regarding XCODE_ATTRIBUTE_* stuff.
It doesn't enable anything else, no other changes in the project.

[alkama]

@sacredbanana Well, you're SIGNING, so somehow you're establishing an official channel. They could decide that if an app is notarised it means it can be, so all versions should be too. At minimum it means all devs would then need a developer ID, worst case it makes all other version suspicious by default.

So the question is funnier: "Once you join that process, do you know or have clear informations about what Apple will demand in the future, because from now on you're bound and could very well be binding everybody else along".
And it has no solutions because both parties are only speculating :D

So a better question would be: Why is it desirable, does it bring value (or enough value to cover for the present and worst case future cost).

[alkama]

@tanis2000 question is more to know if the presence of such "CODE_SIGN_ENTITLEMENTS" in the build settings in XCode, upon first opening of the project, makes it default to having signing enabled. Which would then require a readme step to uncheck that for the people that dont have a dev certificate and build a release version (and might require us to change some CI setup to unselect that).

[sacredbanana]

I’ve never made a macOS app (only iOS experience) so correct me if I’m wrong with my following statement. Surely you can make the notorised app have a different bundle identifier from the non notorised one to make the apps appear as different apps

[sacredbanana]

Well I added features to bonzo for Mac but didn’t pay attention to the build settings

[alkama]

The bundle identifier of Bonzomatic is the the project name, so Bonzomatic.
You would need to never forget changing it to something else when you notarize it. The day you forget and notarise the default one we're back to speculations.

[sacredbanana]

Perhaps cmake could spit out both versions each in their own “notorised” and “non notorised”folders making it straight up impossible for the person responsible for notorising to be too negligent and uploading the wrong binary to Apple

[alkama]

Frankly, this all is recipe for future catastrophy.
As long as this all is not absolutely required and Apple dont clearly communicate their plans and purpose behind notarisation, I recommend we stay away from it.
It brings nothing but constraints.
And non notarised apps vs notarised apps dont even have cuter Gatekeeper dialog box :D

[sacredbanana]

I don’t mind either way at this point. Just as long as macOS keeps allowing you to run non notorised binaries. Let’s see how long until Apple says actually nope

[alkama]

Well, the day they enforce it, we can probably make Bonzomatic a command-line tool :D
Those escape gatekeeper (they cant force all homebrew binaries to be signed).
And if they go that route, then the whole platform is really in trouble anyway.

[sacredbanana]

There’s nothing stopping a Mac user running Bonzomatic in bootcamp windows or even in a Linux VM in Parallels anyway

[Gargaj]

There’s nothing stopping a Mac user running Bonzomatic in bootcamp windows or even in a Linux VM in Parallels anyway

I agree, we should deprecate the OSX version.

[tanis2000]

@Gargaj I hope you’re kidding. Running any application in Parallels isn’t anywhere close to running it natively, especially for gfx apps ;)
It’s good to have a macOS version.