I’m doing my first tests at notarization, thanks to many others on the forums who have provided help.
My first test is to notarize an app file, for distribution as .app.zip
The procedure I’m using:
code-sign the app (with --options runtime)
zip it
upload the zip file using xcrun altool for notarization
(wait for notarization to finish)
staple : Note - I’m stapling the .app file, not the .zip file - this is different than DMG distribution where you staple the DMG
zip the complete stapled .app file
upload the .app.zip file to a webserver
download on a different mac and try to open
What’s weird is that it works - but only sort of? I’m testing on Catalina dev beta 5. The zip file downloads and I can launch the app just fine (suggesting the code-signing with hardened runtime works) but I’m not seeing any evidence of notarization (I’m not seeing the “apple has checked your software for malware” type messages).
For example, I’m NOT seeing anything like this:
Instead what I see looks like the old behavior
"MyApp.app" is an app downloaded from the internet. Are you sure you want to open it. Safari downloaded this file ... from mycompany.com. " with the yellow Caution icon.
My question:
if we are using .app.zip distribution, do we get the nicer “checked for malicious software” dialog? Or is that only seen with DMG?
Sorry if I wasn’t clear: I don’t think the application name matters.
My question: does this “nice” behavior (an example of which is shown in yourscreenshot) only occur with DMG files? The screenshot from Apple implies to me that it might be seen using Zip files too, but that’s not what I’m seeing.
I also did another test with the same app signed (with hardened runtime, but not notarized) vs. signed + notarized, and the two downloads are behaving identically. I thought Apple had said that “all apps post June 1st must be notarzied” so why does it seem like notarization doesn’t matter.
If your app isn’t notarized you will see an awful message like “your app can’t be checked for malicious code by Apple” and you need to open the app with a right context menu click. So you message indicates that the notarization is okay.
Didn’t you get an email from Apple that the notarization was done?
I’ve never seen the message including that sentence “Apple checked it for malicious software” in Catalina (only in Mojave).
Since this is the new expectation (Apps have to be notarized), Beatrix is probably right: if it’s ok - it’s just that “downloaded message”. if not ok, then it’s that “can’t be checked for malicious ” sentence - again: current behavior in in Catalina-Beta.
If you want to double check if the downloaded .app is notarized, do so such as Thom showed.
[quote=448938:@Thom McGrath]Check that your app is notarized, as you expect:
spctl -v -a /path/to/your/bundle.app
It will say something like
/path/to/your/bundle.app: accepted
source=Notarized Developer ID
If you see the “Notarized Developer ID” then you’re ok.[/quote]
Be careful. It appears that running the spctl command on some versions of macOS does not return that string even when notarized.
Oh if thats the direction youre thinking, I believe older then 10.13.? is the answer. Thats the version required to notarize, so it makes sense that older versions wouldnt recognize the notarization at all. I just dont recall the specific bug version.
In my limited testing; it appears there’s no sure way of testing to see if the application has been correctly Notarized or not. The code signature doesn’t appear to contain this information (so I can’t appear to find it using the API, hardening I can).
Also reading Apple’s docs suggests that if the ticket is not stapled to the download or application directly; it’s downloaded from Apple’s servers. Again my quick testing of the code sign attributes doesn’t immediately indicate any change. Which suggests to me that the codesign terminal command is splicing in some internal data when it’s reading the code signature.
Which means it’s totally possible to have a valid Notarized application, but because the OS hasn’t obtained this information yet; display an incorrect result.
Also AFAIK, macOS 10.13.6 is the minimum OS required for Notarization.
Per Apple, unlike a DMG, you can’t notarize the Zip file itself. Apple says you notarize the app, then zip it afterwards.
Indeed, 10.14.5 and 10.15 (beta 5) are behaving differntly. On Mojave, I do see the “checked for malicious software” string :
However, oddly, the same exact app which was code-signed (with hardened runtime) but was never notarized, is showing the same thing (also on 10.14.5):
This suggests:
the OS you are testing on matters
the OS seems to be doing some sort of caching of ‘notarization state’ - perhaps it is IDing apps (by bundle ID? by checksum?) so that notarizing an app can apply to non-notarized copies of the same app.
I’m currently running 10.14.5, I’ll update to 10.14.6 and report back.
That is what it is doing. This is from the Apple documentation…
[quote]Notarization produces a ticket that tells Gatekeeper that your app is notarized. After notarization completes successfully, the next time any user attempts to run your app on macOS 10.14 or later, Gatekeeper finds the ticket online. This includes users who downloaded your app before notarization.
You should also attach the ticket to your software using the stapler tool, so that future distributions include the ticket. This ensures that Gatekeeper can find the ticket even when a network connection isnt available. To attach a ticket to your app, use the stapler tool:[/quote]
10.14.5 and 10.15 (beta 5) are behaving differntly.
On 10.14 Mojave, I do see the “checked for malicious software” string
on 10.15, I do not, I don’t see that message, instead I see the more generic message which looks like this:
Second, the OS caches notarization info which can be confusing:
if you notarize one copy of an app, another copy (which was never explicitely notarized) will be treated as notarized.
This is different than the past: for example, if you downloaded two copies of an older signed (but not notarized) app, that OS treats both the same and will quarantine both
