sctl -a reports Rejected even Notarization Status reports Approved

I am creating a plug-in package written in objc/swift to a third-party macOS app (both are distributed outside of the App Store).


1. I managed to get the package signed up with a Developer ID Application certificate and have it timestampted.

codesign -dv --verbose=4


reports


Authority=Developer ID Application:  ()
Timestamp=


and


codesign --verify --deep --strict --verbose=2


reports "--validated" on each swift library (the main plug-in executable is not listed) and ends the output with


--prepared:<bundled swift libraries>
--validated:<bundled swift libraries>
valid on disk
satisfies its Designated Requirement


2. I have zipped the package, sent it to notarization and got an e-mail that the notarization succeeeded.


xcrun altool --notarization-history 0


reports


  success 0           Package Approved


3. However, if I try to assess the package via a sctl tool, it reports Rejected.


spctl --assess --verbose=4 --type install


reports


: rejected
source=Unnotarized Developer ID

Any ideas what is wrong / how to fix it?


macOS 10.14.6

Xcode 11.3.1

Replies

As some parts where removed by the forum engine, I am provided the result of the certificate results again:


Authority=Developer ID Application: <Team Name> (<Team Id>)

Timestamp=<Date and Time>

I am creating a plug-in package

Just to be clear about terms here, in the context of notarisation we usually use the word package to refer to an installer package. Later on you made it clear that you’re notarising a zip archive, so I figured this out eventually, but it’s probably best to avoid that word in the future. If you want to talk about your software as a whole, try product instead (-:

3. However, if I try to assess the package via a sctl tool, it reports Rejected.

spctl
can do assessments on:
  • Apps

    % spctl -a -t exec -v ***.app

    .

  • Installer packages (see, told you that terminology was important :-)

    % spctl -a -t install -v ***.pkg

    .

  • Disk images

    % spctl -a -t open --context context:primary-signature -v ***.dmg

    .

You can’t use it to assess a generic bundle. You can use the following instead:

% codesign -vvvv -R="notarized" --check-notarization ***

but my general advice is that you do test this properly per the Test the launch behavior instructions in Xcode Help. It’s the only way to be sure.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi,


heh, so you are reusing the same word "package" for different purposis even when their cotext is overlapping, right? It's even a "package" (a directory looking like a file) or a package (*.pkg).


Am I understand correctly, that the plug-in package (directory) is considered as a (generic) bundle? So spctl is of no help?


It seems that the codesign's --check-notarization argument is not available on 10.14 I'm running.


I've copied the (signed and notarized) files to a virtualized 10.15 and got the following:


./<pluginpath>: valid on disk

./<pluginpath>: satisfies its Designated Requirement

./<pluginpath>: explicit requirement satisfied


Does that mean its correctly code-signed and notarized or not? I'm not sure.


What does the "noratized" value in the R argument mean? I've checked man pages but they was of no help (it neither lists possible values nor it hints where to find and learn them).


I have uploaded the zip sent to the notarization service to web and downloaded it on 10.15 via Safari to the folder the host app expects plug-ins. I started the third-party host app I got an error when the host app tries to load the plug-in:
“<pluginpath>” can’t be opened because Apple cannot check it for malicious software.

This software needs to be updated. Contact the developer for more information.


What does that exactly mean? I've tried (?) button but it gives "The selected content is currently unavailable." in macOS User Guid window. I expect the wording is supposed for generic user, its not designed to be helpful to the developer.

Why macOS complains? I've tried to get it code signed and notarized but it still complains. Have I missed anything?


Thanks.

It seems that the …

--check-notarization
argument is not available on 10.14 I'm running.

Correct. It was added in 10.15. Sorry I didn’t mention that. I kinda assume that folks are running 10.15 these days.

What does the "noratized" value in the R argument mean?

-R
is that way that you supply an explicit requirement for
codesign
to check. That requirement is expressed in the requirements language, which is documented in the Code Signing Requirement Language section of the Code Signing Guide. Alas, that doc isn’t being updated, so it doesn’t cover the new
notarized
term.

I expect the wording is supposed for generic user, its not designed to be helpful to the developer.

Correct. The expectation here is that developers will test their software before shipping it, and thus users only see this is something has gone horribly wrong.

As to what it means, the simple answer is that it didn’t pass the Gatekeeper check. Alas, Gatekeeper could be better about telling you (via the system log) why it rejected a program. I posted some hints on how to investigate such problems here.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi,


I've found these two sets of messages in Console which sounds relevant. I've get no hit when search for parts of them over the web.


syspolicyd MacOS error: 3

syspolicyd Error checking with notarization daemon: 3

syspolicyd Error Domain=GatekeeperPolicyScanError Code=-67018 "Code did not match any currently allowed policy" UserInfo={NSURL=<private>, NSLocalizedDescription=Code did not match any currently allowed policy}


syspolicyd MacOS error: 3

syspolicyd Error checking with notarization daemon: 3

syspolicyd rule 13 applies - allow=0


I've trierd to find a way how to enable showing private info in logs but the page has no word nor link stating how to actually use it (moreover it states that System has a Enable-Private-Data property but when I show the System specific documentation it's not there). Based on this and this sounds like the option is no longer available to set on 10.15 and no workaround nor no substitute is known.


Thanks.

Based on this and this sounds like the option is no longer available to set on 10.15 …

It’s true that setting this via

log config
no longer works on 10.15 (that was, btw, never a documented option). The system profile mechanism still works on 10.15. You need to build a configuration profile with the a
com.apple.system.logging
payload and add the property to a
System
dictionary within the profile. I generally do this using Apple Configurator. Unfortunately it doesn’t know anything about the
com.apple.system.logging
payload, so I use Configurator to create a profile with a dumy payload to it, save that to disk, and then tweak that dummy payload based on the docs.

moreover it states that System has a

Enable-Private-Data
property but when I show the
System
specific documentation it's not there

Indeed. But if you click the

SystemLogging.Subsystems
link it also shows nothing useful. What we have here is a documentation failure, and you should feel free to file a bug about that.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I'll check. Any ideas from the log messages what might be the cause and how to address it?

It seems that the Swift's dylib files in Contents/Frameworks/ are triggering the issue. If I remove all Swift code so there is no longer a Frameworks folder in the product, the Gatekeeper allows the code to run.


How to properly codesign and notarize a product containing the Swift's dylib files?

This is odd. Have you tried creating a dummy Swift project (choose one of Xcode's starter template projects that uses Swift) then code-sign and notarize it using the same pipeline that you use for your "normal" app? This is to eliminate the issues coming from your developer account or your system. A sample project should get notarized just fine and run without gatekeeper issues.


Furthermore I see that you're using a .zip file as your end product. As these can't be stapled (i.e. have embedded notarization results), is it possible to switch to either .dmg or .pkg distribution instead? Then staple the notarization results before you validate it using spctl.


It is also possible that the notarization result was not yet available to Gatekeeper when you run spctl. That is, notarization talks to server A whereas Gatekeeper talks to server B. In turn A haven't told B of your just-notarized package. If you staple the notarization results into your redistributable product, Gatekeeper won't need to make a network request to validate notarization of the product.

I believe that MCCZ got to the bottom of this on their other thread:

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"