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

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!

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!

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. 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. I upload this file to Google Drive, then download it again. 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. 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!

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,

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.

You are right, and it works. Thanks Quinn! Happy to say that notarytool runs on 10.15.7. For anyone else who is attempting this, I'll walk through my experience and hopefully that can help folks in the future. First I'd recommend going to downloads here: https://developer.apple.com/download/all/ and downloading & installing the most recent version of Xcode that's possible to run on your OS (12.4 in my case). I think you need around 40gb of hard disk space. To get notarytool, download Command Line Tools for Xcode (in my case, 13.4) From that file I'd use Pacifist (https://www.charlessoft.com/) to extract notarytools and install it. You could also try Quinn's method in Terminal, mentioned above. notarytool should be installed here: /Applications/Xcode.app/Contents/Developer/usr/bin/notarytool. Open Terminal and send it to the directory that contains notarytool by entering the command cd /Applications/Xcode.app/Contents/Developer/usr/bin/ From here, you use notarytool by beginning your command with ./notarytool instead of xcrun (this last bit is why I was getting the error requires a newer version of macOS.)

Hi Quinn, I extracted notarytool (using pacifist) and installed just that (as well as Xcode 12.4). But it seems not to work on my current OS, 10.15.7. I get this error error: unable execute utility "/Library/Developer/CommandLineTools/usr/bin/notarytool" because it requires a newer version of macOS. I am, however, able to get altool to work in terminal now, so there's that. Any ideas on how to get notarytool to work? I haven't yet looked into VM. Thanks!

Thanks so much for the quick and detailed reply eskimo! macOS is all I need for the moment, as it's intended to run on a DAW like Logic or Cubase. I just want to prevent the "cannot be opened because the developer cannot be verified" messages that's keeping away customers. It looks like you have laid out a roadmap on how I can do that, so thanks!