Corrupted .dmg but only sometimes

Hello everyone!

Not 100% JUCE related, but perhaps someone had a similar problem and can give me some hints.

I finally managed to release my first plugin (:tada:), but some users are getting an issue with the .dmg I created for packaging the demo and I can’t figure out what’s the issue. The prompted error message is: “The disk image couldn’t be opened. The disk image is corrupted”.

The error is not deterministic. I can’t get it when testing on the same setup of users getting it. Some users get it, but after downloading the .dmg again, they can open it without issues.

I thought something might be off with my way of signing and notarizing. I followed the procedure described here (How to code sign and notarize macOS audio plugins in CI · Melatonin) but I’m not 100% sure regarding the final .dmg packaging. Perhapes that can be the cause of the problem?

This is the procedure I follow to deliver the product:

  1. Build VST3 and AU
  2. Sign VST3 and AU using codesign. I verify the signature and it’s correct.
  3. Create the .pkg using pkgbuild and productbuild to install both VST3 and AU.
  4. Sign the .pkg using productsign. I check the signature and it’s correct.
  5. Notarize the .pkg via xcrun notarytool. The notarization goes through correctly.
  6. Staple the notariaztion to the .pkg via xcrun stapler. The signature and notarization are verified through spctl and everything looks correct.
  7. Create the .dmg containing the .pkg and convert it to read-only via hdiutil.

Am I doing something wrong? Perhaps I need to sign also the .dmg created at step 7?

Thank you!

I sign and notarize,staple my .dmg.
(btw, I like your website, what website software is running that? in the future I might be looking for a back end that handles user logins/their software licenses)

Are the users with the issue by any chance running very old versions of macOS? At some point the SHA fingerprints changed and when signing on modern macOS, old ones (10.9 and lower or so) can’t verify the signatures because of missing SHA1 fingerprints.

1 Like

Do you also have a .pkg inside the .dmg you deliver? You don’t do anything to the .pkg?

Thank you! Not sure what you mean by website software! I wrote the website from scratch and used Wordpress as CMS!

Not really. One user reporting the issue has a 2013 Mac with Monterey. I later tested on a 2015 Mac with Monterey and didn’t have any issue.

I opted away from .pkg. At one stage, I did use the Packages app and created a pkg inside a dmg because I wanted to deliver to the user Library, but after some research I opted to deliver straight to the system-wide Library location.
I use DropDMG to make the whole process easier. DropDMG will deliver easily to the system-wide locations, but not local user.

fwiw i used to do something similar but i had some customers who couldn’t successfully download / install the .dmg.

so instead i put the .pkg file in a folder and created a .zip of the folder. i’ve had no complaints / issues since then.

1 Like

Got it. Thanks for sharing. Not sure what are the pros of delivering directly to the system-wide Library location, I do that too since all other plugins I have on my machine are installed there. I can do that without problems when creating the .pkg with pkgbuild.

Thanks. I might give that a try too if I get more complaints.