8 Replies
      Latest reply on Dec 3, 2019 3:38 PM by JWWalker
      JWWalker Level 1 Level 1 (0 points)

        When I notarize one of my apps, some members of the app package produce a warning saying "ditto: Couldn't read pkzip local header".  These files do NOT have a .zip extension, but are a modified kind of zip archive.  Why is the notarization server trying to look inside them?  If I changed the file format further so that they couldn't be recognized as zip archives, would that make notarization "happy"?

         

        As I understand it, notarization warnings are likely to become errors in January, so I'd like to get this sorted out.

        • Re: Notarization warnings from ditto
          eskimo Apple Staff Apple Staff (12,425 points)

          Do these faux zip archives contain code?

          Share and Enjoy

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

          ps DTS is closed 25…29 Nov in observance of the US Thanksgiving holiday.

            • Re: Notarization warnings from ditto
              JWWalker Level 1 Level 1 (0 points)

              Yes, the archives are applications.

               

              I devised my custom compression scheme back in the days when I had to worry about resource forks.  Maybe I don't need it any more, except I'm not sure about the symbolic links inside frameworks.

                • Re: Notarization warnings from ditto
                  eskimo Apple Staff Apple Staff (12,425 points)

                  Yes, the archives are applications.

                  In that case I recommend that you switch to using standard zip archives.  The notary services needs to be able to see all the code that you ship in order to include that code in the ticket that it issues.

                  I devised my custom compression scheme back in the days when I had to worry about resource forks.

                  ditto can handle traditional macOS metadata, including resource forks.

                  I'm not sure about the symbolic links inside frameworks.

                  ditto can also handle symlinks.

                  Maybe I don't need it any more

                  Quite.  AFAIK ditto has always been able to handle these edge cases, well, at least since we added zip archive support back in… oh gosh… no idea… probably the 10.3 days.

                  Share and Enjoy

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

                  ps DTS is closed 25…29 Nov in observance of the US Thanksgiving holiday.

                    • Re: Notarization warnings from ditto
                      JWWalker Level 1 Level 1 (0 points)

                      I knew that ditto (with the right parameters) was able to handle the necessary cases.  But I'd much rather have an API rather than needing to use NSTask for compression and decompression.

                       

                      > The notary services needs to be able to see all the code that you ship in order to include that code in the ticket that it issues.

                       

                      I'm not sure why I need that to happen, because the apps being compressed have individually been notarized and stapled.

                        • Re: Notarization warnings from ditto
                          eskimo Apple Staff Apple Staff (12,425 points)

                          I knew that ditto (with the right parameters) was able to handle the necessary cases.  But I'd much rather have an API rather than needing to use NSTask for compression and decompression.

                          So what zip archive API are you currently using?

                          The method used by ditto to encode Mac metadata in a zip archive is pretty straightforward — it creates a __MACOSX directory at the root and then builds a parallel tree of AppleDouble files in there — so updating your current zip code to do that shouldn’t be too hard.  Indeed, you can use COPYFILE_PACK to do the heavy lifting.  See the copyfile man page for more info.

                          Oh, and if you’d like Apple to provide a proper API for working with zip archives, please do file an enhancement request along those lines.


                          I'm not sure why I need that to happen, because the apps being compressed have individually been notarized and stapled.

                          OK, at this point I need to get a better understanding of the big picture.  What is your app doing with these nested, archived apps?

                          Share and Enjoy

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

                          ps DTS is closed 25…29 Nov in observance of the US Thanksgiving holiday.

                            • Re: Notarization warnings from ditto
                              JWWalker Level 1 Level 1 (0 points)

                              > So what zip archive API are you currently using?

                               

                              I'm using the minizip contributed code that comes with zlib, with my own rules for using the "local extra field" to store things like mod date, creation date, and executable bit.

                               

                              > Indeed, you can use COPYFILE_PACK to do the heavy lifting.  See the copyfile man page for more info.

                               

                              That looks useful, thanks.

                               

                              > OK, at this point I need to get a better understanding of the big picture.  What is your app doing with these nested, archived apps?

                               

                              It's a custom installer.

                                • Re: Notarization warnings from ditto
                                  eskimo Apple Staff Apple Staff (12,425 points)

                                  It's a custom installer.

                                  OK.  We have specific advice on that topic in Customizing the Notarization Workflow (search for “custom third-party installer”).  This advice is based on the assumption that the notary service can’t ‘see’ inside the custom installer format.  So, you have two paths you could take here:

                                  • You could notarise the contents of these zip archives and then further obscure them to avoid them being seen by the notary service.

                                  • You could switch to using standard zip archives, which would avoid the need for notarising them independently.  The notary service would look inside the zip archives and include all of that code in your main app’s ticket.

                                  I think either is valid.  The most critical thing here is that, when all is said and done, the notary service must see all your code.

                                  Share and Enjoy

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