Valid installer .pkg becomes invalid after uploading to Google Drive?

The most common cause of such problems is that your code is packaged incorrectly resulting in the code signature being stored in extended attributes. Non-Apple file systems tend to drop extended attributes so, if your code signature relies on them, it breaks your code signature.

However, it’s hard to be sure without seeing the code in question. Can you replicate this with a dummy plug-in that you’re willing to share here? If so, please post a link.

Note See tip 14 for advice on posting links.

If not, try looking through your product to see if there are code signature extended attributes on either the installer package itself or any items within that. See TN3126 Inside Code Signing: Hashes for info on what those extended attributes look like. See Placing Content in a Bundle for advice on how to structure your code. It contains this great ‘money’ quote:

If you put content in the wrong location, you may encounter hard-to-debug code signing and distribution problems.

See the following for specific advice on how to sign and package code for the Mac:

• Creating Distribution-Signed Code for Mac

• Packaging Mac Software for Distribution

Alternatively, you could open a DTS tech support incident and we can pick this up in private.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks Quinn. I'll hold off on sharing dummy code for now, but I did attach a screenshot (embedded below) of the file structure (this is an .AU audio unit plugin). In addition to the _CodeSignature folder at the top, I also signed the binary (default.bin).

Is there any easy method for me to check my code signature(s) to see if it was created as an extended attribute?

Meanwhile, I'm reading over the links you posted (and trying to wrap my head around this stuff), and looking through past posts on this forum. I apologize if I'm missing something obvious.

Is there any easy method for me to check my code signature(s) to see if it was created as an extended attribute?

See the ls example in TN3126.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks Quinn. I ran ls -l@ in Terminal. And I'm not seeing any extended attributes in the plugin itself, which is a relief.

But I do see see an extended attribute in my installer .pkg: com.apple.macl

I'm creating my .pkg using the app Packages (by Sudre). Is it possible that the application is making the .pkg incorrectly and this is causing the corrupt data error? If need be, I can try to familiarize myself with productbuild or pkgbuild.

But the Packages app has been very convenient and quick to use. Unfortunately, I don't see any settings in the Packages app that allow me to disable extended attributes.

Okay,

The com.apple.macl extended attribute has nothing to do with code signing [1]. The code signing ones all start with com.apple.cs., as shown by the example in TN3126.

Is it possible that the [third-party] application is making the .pkg incorrectly and this is causing the corrupt data error?

That has happened in the past, although I can’t see any evidence that this is the problem right now. But…

If need be, I can try to familiarize myself with productbuild or pkgbuild.

Do this, at least for this purposes of this investigation. Once you work out what the problem is, you might choose to go back to your third-party tool, but right now it’d be good to work with Apple tools so there’s no distributed responsibility (-:

Creating a simple installer package with productbuild is pretty straightforward. I have an example of this in Packaging Mac Software for Distribution.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] It’s part of the file system mandatory access control (MAC) system; see On File System Permissions if you’re curious.

Thanks Quinn. I think I've made a little progress on the issue (of files being corrupted by Google Drive).

Here's how I'm recreating the error.

1. I start with a valid .AU plugin that is code-signed twice (first the binary nested inside the package, then the entire package). This plugin works fine.

2. I upload this file to Google Drive, then download it again.

3. When downloading, Google Drive makes it into a .zip first. I'm guessing this is where the problem occurs. When I re-downloaded file and unzip, the plugin is now corrupt.

4. It seems that the CodeResources file (that holds the code signature) has been turned into an .xml file.

So my next step is to figure out if there's something wrong with the plugin's structure that makes the code signature susceptible to being corrupted.

I made a dummy plugin, per your suggestion. Hopefully there will be a clue as to what's going wrong:

https://drive.google.com/file/d/1IFu6d9qdSvMt4LYuV0ZrvBxq-clW02gZ/view?usp=share_link

(I zipped the dummy plugin before uploading to Google Drive, which I believe will avoid corrupting it.)

Much appreciated!

It seems that the CodeResources file … has been turned into an .xml file.

Yikes!

Regarding your steps to reproduce, in step 2 you’re uploading the installer package file (.pkg), right? I’m quite surprised that Google Drive is rewriting this as a zip archive.

I made a dummy plugin, per your suggestion.

If you do the same thing with that — that is, make an installer package and upload that to Google Drive — does it show the same problem?

If so, can you post a link to that? I’d love to see it in action.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

In my own testing, uploading the (.pkg) does not corrupt the file. It only becomes corrupted when I upload the .AU (the individual plugin itself).

However, after comparing with other commercial plugins, this appears to be normal. They all become corrupted when uploading to Google Drive.

--

My original post was about a problem a beta tester had with a (.pkg) that I sent them. I've been unable to recreate that issue with my own testing, because on my end uploading to Google Drive doesn't corrupt a (.pkg) . So I'm not sure what to make of that.

Here is a link to a dummy (.pkg) to check out: https://drive.google.com/file/d/10GJdQrT-xRzjMCqESDr_DKpBRPc92Sr5/view?usp=share_link

At this point, my goal is to figure out if there's something wrong with the way I'm making the (.pkg) that would make things susceptible to breaking.

Thanks!

However, it’s hard to be sure without seeing the code in question. Can you replicate this with a dummy plug-in that you’re willing to share here? If so, please post a link.

Hi Quinn, here's a link to a dummy .pkg

https://drive.google.com/file/d/1gbQPmLLB1hDgwIahAbKgP7qq1bZs2XS7/view?usp=share_link

Could you take a look and see if anything is packaged incorrectly?

Thanks!

Could you take a look and see if anything is packaged incorrectly?

I can’t see anything obviously wrong that. I took a quick general look and I also run it through the steps described in Testing a Notarised Product (using macOS 13.0 in the VM) and it worked.

If you send this dummy package to your customer, do they have the same problem they have with your real package?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for taking a look Quinn! I'm unable to recreate the error, so for now I'll assume it's a fluke.