18 Replies
      Latest reply on Jul 22, 2019 1:21 PM by DmitryO
      DmitryO Level 1 Level 1 (0 points)

        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.

        • Re: Notarizing a loadable bundle
          RGB255 Level 1 Level 1 (10 points)

          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-events

          It'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.

            • Re: Notarizing a loadable bundle
              DmitryO Level 1 Level 1 (0 points)

              Thanks for confirming!

              At least I'm not the only one experiencing this.

               

              It would be good to hear a comment from Apple — perhaps there's a (hopefully temporary) problem with the notary service?

                • Re: Notarizing a loadable bundle
                  RGB255 Level 1 Level 1 (10 points)

                  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.

                    • Re: Notarizing a loadable bundle
                      DmitryO Level 1 Level 1 (0 points)

                      I tried the .dmg approach but the success is at best partial. It reports "Package Approved" but only returns a ticket for the dmg itself. I suspect the service silently ignores the bundle binary in this case.

                       

                      Stapling the dmg works, but its contents remain unchanged. This ticket cannot be used to staple individual bundles.

                      Furthermore, deploying a plug-in by copying it from that dmg (provided it has the qarantine attribute set) still does not allow the host app to load it.

                       

                      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.

                        • Re: Notarizing a loadable bundle
                          RGB255 Level 1 Level 1 (10 points)

                          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.

                  • Re: Notarizing a loadable bundle
                    eskimo Apple Staff Apple Staff (12,095 points)

                    Just as an experiment, I created a small test bundle from the macOS > Bundle template and tried notarising that [1].  It worked as expected, in that notarisation was successful and the ticket contains a cdhash that matches the bundle’s code signature.

                    You should check that your bundle has the CFBundleExecutable property set correctly in its Info.plist.  I’ve seen folks run into problems because of that.

                    Beyond that, my recommendation is that you do what I did, that is, create a new test bundle to see if it works.  If it does, you have a known working case and you can diff from there.  If it doesn’t, we can look into what you and I did differently.

                    Share and Enjoy

                    Quinn “The Eskimo!”
                    Apple Developer Relations, Developer Technical Support, Core OS/Hardware
                    let myEmail = "eskimo" + "1" + "@apple.com"

                    [1] I had to add a dummy .c file so that the bundle actually contained code.

                    • Re: Notarizing a loadable bundle
                      hrodstein Level 1 Level 1 (0 points)

                      I suspect that, for notarization to succeed, the bundle must have the extension ".app" or ".bundle".

                       

                      That should not be required because there has never been any requirement that an executable bundle have a particular extension.

                       

                      I hope Apple will fix this because, if not, it will create problems for us and for thousands of our users at universities and research labs all over the world.

                       

                      UPDATE: Our testing indicates that notarization fails if the CFBundlePackageType is not BNDL *and* the package extension is not .app. It succeeds if CFBundlePackageType is BNDL *or* if the package extension is .app.

                       

                      We use CFBundlePackageType=IXOP because it distinguishes our particular type of plug-in AND because it allows us to associate a custom icon with plug-ins of this type.

                        • Re: Notarizing a loadable bundle
                          DmitryO Level 1 Level 1 (0 points)

                          I just checked and the bundle extension seems to have no effect.

                          For me, it fails with either "bundle" or "aip" for preexisting bundles, and it succeeds with a fresh new test bundle regardless of the extension.

                           

                          So the service seems to be extension-neutral. I'd count this as good news.

                        • Re: Notarizing a loadable bundle
                          eskimo Apple Staff Apple Staff (12,095 points)

                          DmitryO wrote:

                          Still, a verbose error message explaining why the bundle was not processed would be of great help.

                          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.


                          RGB255 wrote:

                          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.

                          OK, that sounds like a clear explanation as to what’s failing.  If you’re OK with changing the CFBundlePackageType property in general, that’s the best way forward.  If there are problems with doing that in general, the only option I can see is to file a bug against the notarisation service.

                          Share and Enjoy

                          Quinn “The Eskimo!”
                          Apple Developer Relations, Developer Technical Support, Core OS/Hardware
                          let myEmail = "eskimo" + "1" + "@apple.com"

                            • Re: Notarizing a loadable bundle
                              RGB255 Level 1 Level 1 (10 points)

                              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.

                                • Re: Notarizing a loadable bundle
                                  RGB255 Level 1 Level 1 (10 points)

                                  FWIW, I filed FB6716476 about the failure to notarize a loadable bundle with CFBundlePackageType = IXOP.

                                  • Re: Notarizing a loadable bundle
                                    eskimo Apple Staff Apple Staff (12,095 points)

                                    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

                                      • Re: Notarizing a loadable bundle
                                        RGB255 Level 1 Level 1 (10 points)

                                        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.

                                    • Re: Notarizing a loadable bundle
                                      DmitryO Level 1 Level 1 (0 points)

                                      > 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)