Why are you using a Xojoscript? Is scripting considered harmful now? What happens if you try without the Xojoscript? It doesn’t matter if you app doesn’t do anything as you only want to test Notarization.
Okay, I deleted the startup XojoScript from my app and then it starts without further error message. However, as soon as I try to run a XojoScript, then the notarized app is terminating with an errorlog similar to the one I posted above.
My app is sandboxed and is running stable since some years.
But when I add notarization to the sandboxed app, then it crashes as soon as a XojoScript is executed.
*** EDIT: removed Apple rant
Remember, report problems to Apple.
It’s a great data point to know that XojoScript causes an issue on this beta. Thank you for investigating.
You have codesigned RBScript.dylib (current signature overwritten with yours)?
And have you tried allowing everything possible in Entitlements (and CodeSigned using Entitlements)? Should it then work, you can restrict them again one after another to figure out which one you need.
It wouldnt surprise me if XojoScripts needs one or more Entitlements, as it allows custom code to be executed… which the hardened runtime now enforces when using Notarization.
Sandboxing is independent of hardened runtime, or not?
Is it because of Notarization?
I guess it will fail because of Hardened Runtime.
You can test that independently. Just codesign with hardened runtime. If it fails, no need to notarize. I only add that step when ive tested possible effects when enabling the hardened runtime.
[quote=440986:@Jürg Otter]Is it because of Notarization?
I guess it will fail because of Hardened Runtime.
You can test that independently. Just codesign with hardened runtime. If it fails, no need to notarize. I only add that step when ive tested possible effects when enabling the hardened runtime.[/quote]
I was thinking, that this goes together? No notarization without hardened runtime, right?
So am I. That’s why I tend to do it step by step. First get hardened runtime to work without issues.
Here is one example Xojo Project: CubeSQLPlugin using SSL Connection (this example .app uses CubeSQLPlugin to load a custom OpenSSL Library, which is bundled within the .app)
You need the current CubeSQLPlugin for that. Oops - no, you don’t - The example contains a pre-built .app 
- Download and extract
- edit “
codesign.sh” and replace “Developer ID Application: Juerg Otter” with your own Developer ID name - change all values in
Entitlements.plisttofalse - run
./codesign.sh
Note: This Script first forces CodeSign to executable and all Frameworks and .dylibs. Then signs the whole .app with hardened runtime.
See the second Label → CubeSQLPlugin can’t load the OpenSSL Library.
Run the .app without codesigning → CubeSQLPlugin can load the OpenSSL library.
So obviously enabling the Hardened Runtime requires something for CubeSQLPlugin to be able to load the custom OpenSSL Library…
In this case:
So:
- change all values in
Entitlements.plisttotrue - run
./codesign.sh
See - the second Label now shows → CubeSQLPlugin can now load the OpenSSL Library.
Since you don’t want all Entitlements, disable one-by one and figure out which one you need.
Note: The Entitlements.plist in this example don’t contain all the possible Entitlement keys. I’ve just added those that I’ve suspected could be an issue to CubeSQLPlugin and loading an external (non system) Library.
Back to your situation:
XojoScript might need some other of the possible Entitlement keys
But maybe this example gives an idea what you could try to figure these kind of situation(s) out… And I just hope it works for XojoScript, too.
And again: first just try enabled Hardened Runtime to work flawlessly… only then do the next step with Notarization (otherwise you’re just wasting time for Apple’s Servers to check and respond, while you haven’t even tested if the .app is working for you).
Another side note:
If you don’t CodeSign everything with your own certificate, you will need the Disable Library Validation Entitlement
XojoScript is generating and then executing executable code. You might have to add one or both of these entitlements:
[quote]com.apple.security.cs.allow-unsigned-executable-memory
com.apple.security.cs.allow-jit[/quote]
That’s what I have suspected, too - but haven’t had the chance to test 
Here you are: An “XojoScript example project” (just the one from Xojo’s examples) with codesign.sh and Entitlements.plist.
Same procedure as above
- Download and extract
- edit “
codesign.sh” and replace “Developer ID Application: Juerg Otter” with your own Developer ID name - change all values in
Entitlements.plistto false - run
./codesign.sh
The codesigned (with hardened runtime) .app will launch, but crash when trying to execute XojoScript.
Then change just this Entitlement:
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
- change
Entitlements.plisttocom.apple.security.cs.allow-unsigned-executable-memory→true - run
./codesign.sh
And enjoy your CodeSigned app with hardened runtime that will now happily execute XojoScript.
Thanks for the hint, trying to log in, they ask me to renew the membership first.
Since my debit card has expired, I need another one first.
[quote]AppWrapper 3.9 claims that the account is already existing (of course it is) and is not allowing me to use it for notarizing my app:
[/quote]
Same issue.
What I have done to try and work around this so far:
Went to Apple site and agreed to everything. (Why dont they email to tell us that there is yet another thing to which we must agree?)
Obtained a new app-specific password. (Still dont know why it doesn’t ask what App it is specific TO…)
Went to Notarise section of App Wrapper. Can’t amend the existing user.
Added a new user and a dummy password.
Opened Keychain access and changed the details of the dummy item to be those of the existing user, including a freshly obtained app-specific password.
Opened App Wrapper.
Checked Codesign diagnostics… all fine.
Wrapped with harden runtime on
Tried to notarize… now I have two entries of the same name.
Using either of them to notarize, …still fails to do it because of the password.
How long does the notarization usually take?
Where would I see the password in AppWrapper? I just dropped my dmg to the Notarizer window and now I wait.
@Sam Rowlands: is there a description of the Notarizer window somewhere in the Help?
From everything weve seen, its dependent on how bug your upload is. Simple files take 20 seconds, the IDE takes 20-30 minutes.
@Greg O’Lone: it took 4 minutes.
@Sam Rowlands : Should AppWrapper show the final log file?
[quote]12.06.19 13:47:25 Has a remote log, requesting that now
12.06.19 13:47:25 StatusChanged: Package Invalid retrieving the remote log…[/quote]
How do I do the hardened runtime?
And of course, I first need to wait for a new Valentina release:
[quote] “path”: “MailArchiverX510b1.dmg/Mail Archiver X Installer.app/Contents/Resources/OS X 64 bit/Mail Archiver X.app/Contents/Frameworks/v4rb_cocoa_64.dylib”,
“message”: “The binary uses an SDK older than the 10.9 SDK.”,[/quote]
Notarizing with AppWrapper so far never worked for me. However, I am using AppWrapper to do the code signing, stripping 32bit, adding entitlement keys, help book, etc.
You can set a checkbox for the hardening (nomen est omen) on the same panel where you select the signing identity.
After that, I use the command line for notarization and then to staple the ticket to my distribution.
(But I still have not figured out how to make XojoScript work in my notarized app. Jürg Otters instructions are not quite working for me, yet.
Notarising works fine here with AppWrapper.
Well, I get the confirmation the DMG is successfully notarised (including receiving a mail from Apple it is ready for distribution).
Still, it does popup the ‘unidentified developer’ message. Fingers crossed it is a macOS10.15 beta 1 issue.
Thanks for the information, Oliver.
That’s bad because AppWrapper insists on moving the wrapped application. I have too many applications. I’ll need to do more investigations in the next days. Doesn’t AppWrapper have a CLI, too?
It’s 9 am here; I’ve been up since 5am. I’ve ripped out the Application Launcher account management system and replaced it with all new code to solve this issues. I’m just awaiting my Mojave machine to finish updating, and then I’ll test it and release an update.
Currently it doesn’t. This is something that I’d starting work on last year; but I’ve had to postpone it because of all the work I needed to do to bring everything else up to “potentially” Catalina compatible (which is not 100% in vain, but early tests shows that there’s problems with every single one of my apps).
So please try this version.
https://www.ohanaware.com/appwrapper/appWrapper3update39.dmg
Please Note:
- I was forced to create a new App-Specific password over at appleid.apple.com; when using the account that already had one set-up, it just kept telling me that I needed to use an App-Specific password. It’s either an incorrect error message (something else is wrong) or there’s problems at Apple’s end.
- It seems like there might be an issue with 10.4.5 as I’m not able to update any account info or remove it from the KeyChain via App Wrapper (even though it’s items that App Wrapper has created). I’ll continue to investigate, but I had to enter in the new App-Specific password in KeyChain Access.
- When stapling the Notarization tag to the DMG, it returns as a success and the DMG’s modification date is updated. So I assume right now that this part is working correctly.
- I have tested the Notarized DMG on macOS 10.14.5, the download app warning looks like below.
Off to get some chocolate and take a nap now.
10.4.5 ? typo is assume ?