.dmg with symlinks to /Library/Audio/Plug-Ins/

Audio Plugins
21

I guess it not only has to be UDZO format, but also notarized/codesigned …

@sudara See details here:

https://developer.apple.com/forums/thread/128166

22

Yeah, I’ve gone through this round of googling already :slight_smile: it’s good to have someone to sanity check and double check though! UDZO isn’t happy either, even when notarized, you can try here

23

Hmm, haven’t tried this on the dmg, though:

If you’re signing non-bundled code, set the code signing identifier by adding -i BBB , where BBB is the bundle ID the code would have if it had a bundle ID. For example, if you have an app whose bundle ID is com.example.flying-animals that has a nested command-line tool called pig-jato , the bundle ID for that tool would logically be com.example.flying-animals.pig-jato , and that’s a perfectly fine value to use for BBB .

24

Okay, I just codesigne’d the .dmg with my Apple Developer Distribution ID, and the quarantine bit was gone after a download. Maybe you should double-check the codesigning ID you’re using?

25

I get a malware warning (codesigned with no notarization) and still no drop ability there… I’m going to look into the fake bundle id…

26

Yeah, I guess that was only valid on my local machine, removed …

Either way I think you’re close. :slight_smile: I eagerly await your solution to the problem, first beers on me …

27

Heh, close… to giving up! Trying the fake bundle id now (spoiler: it failed)

I submitted a TSI to Apple. Thanks for pairing on double checking everything!

28

I received some fantastic support from Apple. +1 for using an apple developer technical support incident if you ever get stuck on something apple-y system-y like this.

Short story: It’s not possible and unlikely to be fixed.

Long story:

It’s due to quarantine behavior (as we already knew). After customizing and enabling private data around the logging, the Apple rep was able to see the following:

type: error
time: 05:24:58.704737-0700
process: Finder
subsystem: com.apple.syspolicy
category: default
message: Drag to alias/symlink /Volumes/QDiskImage/Components, which targets /Library/Audio/Plug-Ins/Components, is disallowed by system policy

Due to prior attacks in the past, Apple consults their “system policy module” when a file is dropped on a quarantined symlink. In the case we care about (plugin paths), the policy module has denies the request, because the plugin paths are not on the allowlist.

These folders are currently on the allowlist, in both / and ~ forms:

  • Applications
  • Applications/Utilities
  • Desktop
  • Library/QuickLook
  • Library/Screen Savers
  • Library/PreferencePanes
  • Library/CloudStorage/iCloud Drive/Desktop

I noted that it’s strange that I can have a notarized pkg installer that dumps all sorts of stuff everywhere — but a notarized dmg can’t do a drag and drop, even on user authentication. It sounds like despite the symlink’s behavior being altered by quarantine, Gatekeeper isn’t being consulted at all (even though it should be, that’s the entire point of notarization and user authentication).

I also noted that possible to drag a file outside of the dmg to the “disallowed” target — the policy only applies to other quarantined files being dropped on the symlink.

So at the end of the day, it is what it feels like: An edge case Apple put in to prevent a specific type of attack, inconsistent with the notarization mental model, unlikely to be fixed.

4 Likes
29

Wow. Strange days indeed. A very common user experience is on its way out …

So, .pkg it is then?

30

Dragging into a /Library symlink/alias on a .dmg seems to be fixed in Ventura?

I bought a plugin which was delivered in a dmg and it surprised me by working just fine. Also confirmed with the test.dmg in this thread and a pamplejuce run Pamplejuce · sudara/pamplejuce@fc3adb8 · GitHub

I confirmed it still didn’t work on a machine running 12.2, though…

31

@sudara, thanks for your work on this - I have been struggling with DMG distribution as well. I still like the DMG installer method, so the user has some control over what’s being done to their computer. At least with a pkg, you can inspect it with good ol’ Suspicious Package to see what’s going on. (Unlike .app installers.)
So now I distribute a DMG with the plugins (but no symlinks), a readme and a pkg inside. However this is still not without issue…
After a lot of testing, VMs, and some emails with Rob from Avid, I have found that Gatekeeper blocks notarized AAX plugins distributed alongside a notarized pkg containing that same AAX. This is somehow related to the non-standard plist entry I mention here.
So, if you are distributing an AAX alongside your pkg, you can use Projucer to override the plist entry in AAX and Gatekeeper will not block it if distributed with a pkg.

1 Like