Comment: (emphasis: mine) I think that this means that if you don’t use script files and only use regular Mach-O executables, then code-signing doesn’t rely on extended attributes, but if you do, it would. This is relevant as extended attributes require (I think) and HFS+ filesystem, and are not supported by other formats such as TAR and ZIP. I don’t use any script files, so I’m hoping this means that I can use ZIP or another format?
Comment: This is interesting, as it provides a way to put some “out-of-band” data into your app, though it also probably requires HFS+ filesystem.
Apple complicated code signing process is why I wrote App Wrapper for my own use, way back in 2011.
It depends on which Zip processor you use, the one we use in App Wrapper 3 does indeed store the ACLs within the zip file in a way that OS X will retain them.
Apple’s Installer Package also retains ACLs. I don’t know about TAR as I’ve never actually used it.
There is a free trial of App Wrapper, so there is no risk involved in testing it, to see if it will help or not.
Thanks for the help, Sam - you have good suggestions, but my use case is generating these bundles on a Windows PC - so there are non-trivial cross-platform issues that I’m fighting.
There was a discussion a while ago where a Xojo engineer explained precisely why Mac bundles generated on Windows where packed into a tar archive to protect the symlinks and other peculiar aspects of the Mac file system. That was in a discussion where a user had unpacked the Tar and was wondering why some things were broken.
Unfortunately, I cannot locate that at this moment. Maybe someone from Xojo can chime in.