Mac: Create scripts to automate code signing process with notarization. Possibly sign and notarize PHP Desktop app bundle.

[cztomczak]

No description provided.

[cztomczak]

Enable hardened runtime required for notarisation in commit 72e75ea.

Useful links for notarization process:

1. https://www.magpcss.org/ceforum/viewtopic.php?f=6&t=16481&p=50934&hilit=+notarization#p50934
2. https://www.magpcss.org/ceforum/search.php?keywords=%2Bnotarization
3. https://github.com/search?q=repo%3Achromiumembedded%2Fcef+notarize&type=issues
4. https://developer.apple.com/documentation/security/resolving-common-notarization-issues#Ensure-a-valid-code-signature
5. https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution

I'm not sure if there is a point to notarize PHP Desktop default binaries. From what I understand, I notarise whole bundle, so if user tries to play with PHP Desktop and modify scripts in www/ directory, then that would break notarisation for the app bundle.

I could work on scripts to help automate the process of notarising PHP Desktop app. There is some complex stuff to do, because PHP Desktop includes CEF/Chromium framework, libraries and helper applications. These require special entitlements that need to be defined in some files.

Other issue that comes to my mind is that currently Chromium web cache directory configured via settings.json is set to be inside the app bundle. So it would need to be set to a path outside of bundle, because it changes during runtime. Same for the log file, also configured via settings.json and created next to main executable by default. A notarised app can't allow for creation or change of any files inside bundle, so these settings need to be changed from defaults.

It would be unsafe to configure PHP Desktop via settings.json to set www/ directory to be outside of app bundle. Because if done so, someone could overwrite PHP files that are outside of bundle and do malicious behaviour. The result would be that it's your notarised app that allows for this and could result in your app being banned by Apple or something. We need to make users aware of possible security issues.

[belbernard]

The only reason we need a "notarisation" is to avoid calling:

sudo xattr -dr com.apple.quarantine ./PHP\ Desktop.app

before running PHP Desktop.app for the first time. Would it be sufficient to notarise "MacOS/PHP Desktop" for this purpose?

As a user, when I customise PHP Desktop for my application, I don't change "PHP Desktop.app" or "MacOS/PHP Desktop". I only change the contents of the www folder and the attributes in settings.json. These changes shouldn't break the authentication.

If they do, I would change the name of "PHP Desktop.app" and notarise the changed version in my own name. Incidentally, I tried to change the name, but it did not work because of broken symbolic links like "Contents/MacOS/webcache/RunningChromeVersion". But that is a separate issue (#356).

Similarly, I have notarised a MacOS installer (a "pkg" file) for my application. It contains a script that imports data from my GitHub open source repository. This data (source files, etc.) changes almost every day without the need to re-notarise the installer. So I'm not sure that "a notarised application cannot allow the creation or modification of any files within the bundle". We should just try...

And, of course, warn users that if they change files in the "content", you have no responsibility to guarantee that those changes are secure.

As these are still open questions, it may be best to release the new version and take time to figure out the notarisation (or equivalent) process.

[cztomczak]

The only reason we need a "notarisation" is to avoid calling:

sudo xattr -dr com.apple.quarantine ./PHP\ Desktop.app

before running PHP Desktop.app for the first time. Would it be sufficient to notarise "MacOS/PHP Desktop" for this purpose?

Yes, that would be nice.

As a user, when I customise PHP Desktop for my application, I don't change "PHP Desktop.app" or "MacOS/PHP Desktop". I only change the contents of the www folder and the attributes in settings.json. These changes shouldn't break the authentication.

Any change in bundle will break notarization. You will also likely want to change a few other resources in the bundle: Info.plist with app name/id, icon, main menu.

If they do, I would change the name of "PHP Desktop.app" and notarise the changed version in my own name. Incidentally, I tried to change the name, but it did not work because of broken symbolic links like "Contents/MacOS/webcache/RunningChromeVersion". But that is a separate issue (#356).

I replied there with instructions.

Similarly, I have notarised a MacOS installer (a "pkg" file) for my application. It contains a script that imports data from my GitHub open source repository. This data (source files, etc.) changes almost every day without the need to re-notarise the installer. So I'm not sure that "a notarised application cannot allow the creation or modification of any files within the bundle". We should just try...

If it works then I guess it's fine.

And, of course, warn users that if they change files in the "content", you have no responsibility to guarantee that those changes are secure.

As these are still open questions, it may be best to release the new version and take time to figure out the notarisation (or equivalent) process.

Yes, sounds good.