Hello,
For once, my question is short: on Mac 10.14/10.15, must console applications be signed or notarised?
[quote=472020:@Arnaud Nicolet]Hello,
For once, my question is short: on Mac 10.14/10.15, must console applications be signed or notarised?[/quote]
Yes to both. All executables now need to be signed and notarised.
But how do you Sign and Notarize and app that is not a “Package” that includes a “Contents” and the other sub-folders etc?
The path that you pass to the codesign tool is the path of your Console app. There’s an example here: macos - Mac OS app, sandbox with command line tool? - Stack Overflow
For distribution, Apple say you don’t have to sign the DMG, but I’d advise doing it anyway. It doesn’t hurt.
OK, thank you. I’ll try whether App Wrapper handles console apps.
I thought notarisation was (or will be) required for dmg files (and several distribution methods). IIRC, I read that on this forum. Strange to read the opposite here
I’ve been signing my DMGs for a while now but this is Apple’s most recent clarification on this process so it seems it’s not entirely required. I’ll continue to sign them to be sure though, no reason not to.
Indeed. Better doing more than the bare minimum.
Thanks.
On macOS 10.12, 10.13 and 10.14 a signed DMG prevents App Translocation.
According to my notes on the Notarization process (made a while ago, Ill give you that) says that a signed DMG is required for Notarization.
It also worth noting that there are several inaccuracies with Apples recent developer documentation (especially security) to which Ive requested clarifications on (as they contradict previous documentation statements). If the updated documentation is correct; the App Sandbox just got a whole lot more restrictive and incapable, which is the opposite of the direction it should be going in.
App Wrapper doesnt currently handle console apps outside of a bundle; this is something I intend to address in the upcoming redesign.
Can you clarify “apps outside of a bundle” in the above? Do you mean things within a dmg but not within the appropriate subfolders of the main *.app? Or does this include console apps which are embedded in the *.app and launched from the subfolder?
If the latter, is the solution to Notarize the console app separately, then merge the notarized console app into the main app?
Edit: I don’t think what I wrote was helpful enough.
FWIW, I distribute as a notarized app with absolutely no problems.
[quote=472247:@Douglas Handy]Can you clarify “apps outside of a bundle” in the above? Do you mean things within a dmg but not within the appropriate subfolders of the main *.app? Or does this include console apps which are embedded in the *.app and launched from the subfolder?
If the latter, is the solution to Notarize the console app separately, then merge the notarized console app into the main app?[/quote]
App Wrapper was designed to ONLY work with “.app” bundles, so it doesn’t know how to handle a Mach-O executable on it’s own (typical of a Console style application).
I have experimented in the past, but I hit a roadblock because I wasn’t able to figure out a way to safely inject a “Info.plist” into the Mach-O executable. Everything I’ve read regarding this matter talks about embedding the “Info.plist” at build time. I was able to inject after build for some Mach-O files, but it requires that there is enough FREE space within the Mach-O for this, otherwise I have to pragmatically read every single block, adjust it’s position, and shift every single offset within the binary to match. It’s doable, but I wasn’t able to complete it in a reasonable time frame. Some of the “blocks” are well documented, and could be adjusted, some of them are not meaning I don’t understand the data, therefore the resulting application died.
I intend to go back into it at some point, but I have a lot to do between then now and then.
And that is fine by me if it also automatically (or at least optionally) handles additional apps that are copied into the appropriate subfolders to use as helper apps. Some wording in another post in this thread (not by you) made me question if we needed to first notarize any helper app, then embed that copy in the main *.app package. Since it sounds like that is not the case, then I don’t also have the need to notarize separate apps.
If a helper app is an *.app bundle – even if not Xojo based – should App Wrapper be able to Notarize it while processing the main Xojo *.app?
If the helper is included as part of the .app bundle, then App Wrapper will treat it as part of the bundle and sign, Notarize accordingly.
By default however; the console application is code signed as part of the bundle, therfore the security settings applied to the helper may not permit it to be operated from the command line. If you Sandbox your application, then the helper cannot be called from the commandline (or Xojo Shell class).
There are options in App Wrapper to change this behaviour.[quote=472385:@Norman Palardy]sounds like you need the same thing the case requests
Feedback Case #55258[/quote]
Thanks Norman, Ill take a look on the puter when I can. Am at the in-laws for CNY, so lots of eating with various family member and friends of the family, not much time to sit in front of puter at the moment.
Isn’t that doable using file steps? Or including an info.plist file in the IDE?
That looks promising!
In the meantime, it’s since the 1st of February that Apple will require all executables to be notarised, right? What are alternative ways until App Wrapper does it?
[quote=472385:@Norman Palardy]sounds like you need the same thing the case requests
<https://xojo.com/issue/55258>[/quote]
Sadly, this report is in reviewed state since nearly one year.
A countless of times I’ve seen that happening, the report is kept reviewed until, perhaps 10 years later, it’s too late because something else changed (in this case, perhaps Apple will move away to Mach-o headers, or anything, rendering the report useless
) and the report gets closed. An alternate way to deal with reports
According to this, the plist is no longer required: Notarization made a bit simpler – The Eclectic Light Company
Gong hei fat choy
I trust Howard and all the people he mentioned in the article, it’s just disappointing, that there no official documentation from Apple on how the process should work today, most of the their documentation was archived in 2016, and the new docs are missing a lot of information, so we assume in that case to resort to the archived docs, which in this case is just wrong.
I shouldn’t have to read a 3rd party blog (no matter how respected the author is) to get information that should be on the Apple documentation site.
[quote=472462:@Norman Palardy]Gong hei fat choy[/quote] ???????So true. They choose the path to require notarisation, yet they don’t say clearly how to do it. And this requirement is for next week
First time I’m in the Apple developer membership; hoping it’s sometimes more clear