I suggested the approach, but I don't really support us facilitating the circumvention of a system security feature (or annoyance, based on your perspective). At the least, it shouldn't be considered Pd's "standard practice" for macOS, in my opinion.

Hypothetically, what if someone uploads a malicious external to deken, knowing that someone will blindly download, install, remove quarantine, and urn it? Is the onus partially on whoever wrote the plugin as well as the original actor?

I suppose another approach is to have an upload server that automatically signs the library contents of a zip file and creates a notarized dmg for deken using a "shared" Apple developer account. I feel this leads us to the same potential problem if it is truly open to whoever.

On Oct 14, 2022, at 12:00 PM, pd-list-request@lists.iem.at wrote:

Message: 1
Date: Thu, 13 Oct 2022 09:54:52 -0300
From: Lucas Cordiviola <lucarda27@hotmail.com>
To: Dan Wilcox <danomatika@gmail.com>, Alexandre Torres Porres
<porres@gmail.com>
Cc: Pd-List <pd-list@lists.iem.at>
Subject: [PD] loading non notarized externals in newer macOS (was:
[hidraw] pre Deken release)
Message-ID:
<DS7PR10MB4845B8566E81247519EFED77A6259@DS7PR10MB4845.namprd10.prod.outlook.com>

Content-Type: text/plain; charset=UTF-8; format=flowed

How about a tcl-plugin (available from deken) that is reusable instead 
of a script per lib.

Something that you open and choose folder(s) to recursively circumvent 
the quarantine in all binaries found. One has to provide the sudo 
password in a pop-up dialog.

This plugin can also be part of deken or can be called by deken.

--------
Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com