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 mailto:lucarda27@hotmail.com> To: Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> Cc: Pd-List <pd-list@lists.iem.at mailto: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 mailto: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 http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/