Notarization warnings from ditto

Code Signing General
JWWalker OP
Created Nov ’19
Replies 8
Boosts 0
Views 1.8k
Participants 2

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.

Answered by DTS Engineer in 396747022

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"
Replies  8
Boosts  0
Views  1.8k
Participants  2
DTS Engineer OP
Apple
Nov ’19

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.

0
JWWalker OP
Nov ’19

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.

0
DTS Engineer OP
Apple
Nov ’19

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.

0
JWWalker OP
Nov ’19

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.

0
DTS Engineer OP
Apple
Nov ’19

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.

0
JWWalker OP
Dec ’19

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

0
DTS Engineer OP
Apple
Dec ’19
Accepted Answer

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"
0
JWWalker OP
Dec ’19

Thank you very much for your efforts, things are clear to me now.

0
Notarization warnings from ditto
First post date Last post date
 
 
Q