Post not yet marked as solved
We have the same problem with bundles used by our software, which also have a non-standard CFBundlePackageType. I filed FB6716476 about this in July but have received no response since then.I changed the extension of our bundle from .xop to .app, and then resubmitted to the notary service. Making this simple change resulted in the notary service notarizing and providing a ticket for the bundle itself. I could then rename the bundle back to .xop and staple the ticket.The downside to this approach is that we can't submit a .dmg containing our application the the various .xop bundles we ship for notarization at once. Instead, we notarize all of the .xop bundles first, staple the tickets to the .xop bundles, and then create the .dmg of the application and the .xop bundles and notarize that.
Post not yet marked as solved
I guess you're referring to this (from the transcript):"And the first launch policy will be slightly different, where we won't be requiring first launch user approval for standalone executables or libraries, but all bundled software will show first launch prompt."That seems like a rather arbitrary distinction between a plugin loaded from a bundle vs. from a ***** file, but if this is how things are supposed to work this saves me from filing a bug report. Thanks.
I think that https://developer.apple.com/news/?id=09032019a explains what you're seeing.
Post not yet marked as solved
I forgot to mention that I'm testing on Catalina beta 7.
Post not yet marked as solved
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.
Does the application have the quarantine attribute in both cases? I suspect it does when you download from GitHub with a browser, but it probably doesn't on your machine after you create it and Slack might also not add the quarantine attribute. As far as I understand, Gatekeeper doesn't check (or maybe less intrusively checks) if there is no quarantine attribute.You can use xattr or ls -la@ in terminal to see if it has the quarantine attribute.It does seem that your app should run either way if it's successfully notarized, but I suspect the quarantine attribute explains the difference you're seeing in the two conditions.
Post not yet marked as solved
FWIW, I filed FB6716476 about the failure to notarize a loadable bundle with CFBundlePackageType = IXOP.
Post not yet marked as solved
Thanks Quinn. I will file a bug report about the failure to notarize a bundle with a custom CFBundlePackageType property.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? This seems like a bug to me, but since the documentation for that entitlement is so sparse I'm not sure if I'm misunderstanding its purpose or not.For what it's worth, I have used codesign to view the entitlements of the application while it is running (you gave instructions to do this in another thread) and they are as I expect them to be. And I am able to do things with the application such as access the camera and debug the application.
Post not yet marked as solved
I saw the same thing happen yesterday on 10.15 beta 3, but in my case it was a loadable bundle that couldn't be loaded instead of the main application. Also, in my situation, I had not stapled the ticket to the bundle--I was relying on Gatekeeper to pull information about notarization from online.To "fix" the problem, I re-opened the .dmg file containing my application and loadable bundles, and copied everything in the .dmg to a new location. I then ran the new copy of the application, which loaded the bundle successfully. I then went back to the original version of the application which at first would not load and now it loaded just fine.Just to be clear, both copies of the application and the loadable bundles were identical. Also, as in your case, spctl claimed that the loadable bundle was notarized, except when I tried to actually load it I got the same error dialog you got.
Post not yet marked as solved
BTW, you might want to check that your notarized bundle works on another machine if it was downloaded from the Internet. If there's no quarantine flag on it, the verification step is omitted.Yes, the machine on which I tested is running Catalina while the notarization was done on Mojave. On the Catalina machine, I tested for notarization success both by running spctl and running the application which loads the bundle. Prior to notarization, the .xop failed to load. After notarizing (again, on a different machine) and then waiting a few minutes, I was now able to run the application with the .xop loading on the Catalina machine. I didn't change the .xop that's loading at all, so the OS must have looked up the notarization ticket online, since it wasn't attached to the .xop bundle on that machine.
Post not yet marked as solved
Our .xop bundles set CFBundlePackageType to IXOP in the Info.plist. I tried changing IXOP to BNDL for one of the .xop bundles. After re-codesigning and resubmitting to the notary service, I see that both the outer .dmg and now the .xop bundle is listed in ticketContents.The legacy documentation at https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/20001431-111321 states "For loadable bundles, you can also choose a type code that is more specific than BNDL if you want.". The newer documentation at https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundlepackagetype?language=objc leaves it ambiguous as to whether it is allowed to use a custom type code for a bundle.
Post not yet marked as solved
I was finally able to successfully notarize my plugin bundle in such a way that the main application can load the plugin. This is not pretty.Our plugins are bundles with the .xop extension. I renamed the bundle to have the .app extension, and then created a .dmg container to hold the bundle. I then uploaded the .dmg to the notary service. The notary service accepted and notarized the .dmg. When I look at the log for the notarization process, there are two entries in the "ticketContents" array, one for the outer .dmg file itself and one for the .app file. The actual executable in the bundle, located in Contents/MacOS, is not included in the ticketContents list. However, a few minutes after the notarization succeeded, I was able to run my application on a separate machine and the bundle, still with the original .xop extension, was successfully loaded by my application.I have not yet tested whether stapling a ticket to my .xop bundle works, or if I can staple the ticket to the temporarily named .app bundle and then rename give it the .xop extension.It is also not clear why I need to go to the trouble to notarize the plugin in the first place since my main application includes the com.apple.security.cs.disable-library-validation entitlement.I have also not tested whether a plugin signed/notarized by a different developer certificate than the main application will load.For the record, I am doing the code signing and notarization on Mojave, and testing the application on 10.15 beta 3. Also, the .xop bundle itself does NOT use hardened runtime. Based on the documentation for hardened runtime, it is the application that controls the hardened runtime entitlements, not the plugin. But I don't know if that documentation is actually correct.
Post not yet marked as solved
I'm seeing the same behavior for plug-ins used by our application (not related to Adobe but similar idea). Our plugins never contain helper tools, so we only see the error about "Package has no signed executables or bundles. No tickets can be generated" when trying to notarize. And then the bundles aren't loaded when running on Catalina.Our application (which is itself notarized) that loads our plugins has the following entitlements set, yet they don't seem to avoid the need to notarize our plugins:com.apple.security.cs.allow-jit
com.apple.security.cs.allow-unsigned-executable-memory
com.apple.security.cs.allow-dyld-environment-variables
com.apple.security.cs.disable-library-validation
com.apple.security.cs.disable-executable-page-protection
com.apple.security.get-task-allow
com.apple.security.device.audio-input
com.apple.security.device.camera
com.apple.security.automation.apple-eventsIt's not clear to me whether setting these entitlements should avoid the need for our plugins to be notarized or not. They are code signed but that doesn't seem to be sufficient.
