Notarizing a loadable bundle

Hi


I'm trying to notarize a plug-in for Adobe Illustrator (project type: Mach-O Bundle).

I have signed it with a Developer Id certificate and have enabled hardened runtime. The bundle contains 2 binaries: the main binary and a helper tool. Both binaries are reported signed by codesign -d -vv, as well as the bundle itself is.

After a few attempts I finally managed to get "Package Approved" from the notary service, but the approval only contains a ticket for the helper tool, but not for the main bundle binary.


Some of our products don't contain a helper tool. Trying to notarize such a bundle, I always get an error saying "Package has no signed executables or bundles. No tickets can be generated".


Is this normal behavior, or am I doing something wrong? Non-notarized bundles are no longer loaded by the host application on macOS 10.15 beta.

Replies

I filed FB6716476 about the failure to notarize a loadable bundle with

CFBundlePackageType
=
IXOP
.

Thanks for that.

But can you tell me this--given that the application has the entitlements I gave in my first post in this thread (specifically

com.apple.security.cs.disable-executable-page-protection
), should notarization of the bundle (
.xop
) be required in the first place?

I don’t have a definitive answer to that, and probably won’t until DTS starts officially supporting 10.15. However, my general advice on this front is very clear: If you distribute your product to a wide audience, you should notarise it. The last year and a bit [1] has made it very clear that notarisation is the future of macOS software distribution.

Share and Enjoy

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

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

[1] Consider this timeline:

  1. Jun 2018 — We announce notarisation at WWDC.

  2. Apr 2019 — We ship 10.14.5, which requires notarisation for apps.

  3. Jun 2019 — We announce notarisation for other code at WWDC

However, my general advice on this front is very clear: If you distribute your product to a wide audience, you should notarise it.

We can notarize the XOP bundles we distribute with our application, but many of our users also use third-party XOPs. Most of our users and XOP authors are scientists, not professional software developers. I would be shocked if there were more than one or two XOP authors that already have developer accounts with which they can generate credentials to sign and notarize an XOP. Developer accounts are expensive and complicated from a legal perspective, since most XOP authors are writing XOPs as part of their regular university, commercial, or governmental jobs. Most XOPs are freely available and many are open source, so there is little financial incentive for third party XOP authors to go through the arduous process of getting the certificate and then notarizing XOPs.


If our application can't set entitlements that prevent the need for XOPs to be notarized, the alternative is for us to suggest that users remove the quarantine attribute from XOPs so that they can be loaded. When that eventually stops working (as I assume it will), the only alternative may be for us to recommend that users disable Gatekeeper entirely. Some users might not like that and will use some other software, but based on past experience I think that most users would not have a problem disabling Gatekeeper if necessary. Clearly we would prefer to not need to make that suggestion, but we may have no other alternative.

> Agreed. Please do file a bug report requesting that. Make sure to include the UUID of the submission that failed and the submission that succeeded. Please post your bug number, just for the record.


Filed as FB6785071 (misleading error messages and partial approval)