MacOS Catalina introduces new security measures, and script libraries that contain embedded code such as Cocoa frameworks are affected. Fortunately there is a simple, if non-obvious, solution.
Examples of such script libraries are Myriad Tables Lib or BridgePlus, and the problem stems from the fact that they cannot be notarized. Let’s look at how the issue manifests itself first.
If you have such a library installed before you upgrade, there should be no issue; the Gatekeeper check is confined to the first “launch”. But suppose you download one of these libraries, and put it in your ~/Library/Script Libraries folder. When you first try to run a script that uses the library, you will get a warning dialog warning that it cannot be opened “because the developer cannot be verified”. The two choices are Cancel and Move to Trash (or Bin in my locale).
If you press Cancel, you will get the same dialog again. You can then click Cancel again. (The second appearance of the dialog smells like a bug.)
If you then open System Preferences at Security & Privacy, and click on the General tab, you will see some extra text below the radio buttons that normally allow you to control which apps are allowed. Next to this text will be a new button, Open Anyway.
If you press the Open Anyway button and return to your script, this time when you run it you will get a more detailed dialog, with an extra button: Open.
Click the Open button, and that’s the problem solved.
You might wonder why this is now necessary, and why it only affects libraries containing code such as bundled frameworks. The reason is that Catalina now expects any code files, or bundles containing code, to be notarized. The definition of code in this case means executable code, which excludes AppleScript code (and code written in other scripting languages), meaning
.scptd files without code are ignored by Gatekeeper.
So Gatekeeper sees these particular
.scptd files as bundles requiring notarization, but the notarization process does not (yet) allow them to be notarized.
Compounding the matter is the fact that any code or framework within a script library can itself be notarized. This makes no difference to the behavior outlined, so you might reasonably ask why libraries are not distributed with notarized frameworks. After all, code-signing them using the enhanced runtime, which is required by notarization, means you know the code has been scanned for malware. It surely offers at least some extra security.
The answer, unfortunately, is that it introduces complications if the libraries are subsequently embedded in apps.
Suppose you have an app that uses Myriad Tables Lib, and you want to email it to a colleague. You can embed a copy of the library in the app’s /Contents/Resources/Script Libraries folder, and send it off.
If you have a developer account, you will probably notarize the app before sending it. But if you do not, when the recipient first tries to run it they will get a dialog similar to the first one above. If they trust you, they will be able to bypass Gatekeeper by control-clicking on the app in the Finder and choosing Open from the contextual mean. The subsequent dialog will allow them to run the app. (Approval in this case covers the app and its embedded library.)
However if some part of the app — and not all of the app — is code-signed, Gatekeeper sees the situation differently: the only options will be Cancel and Move to Trash. Presumably when only some of the contents of an app is code-signed, Gatekeeper assumes the worst, some kind of tampering.
So if these libraries did contain notarized frameworks, they could only be successfully embedded in apps by users who code-sign their software (notarizing will generally replace any existing code-signing so that all code is signed by the same identity).
It’s fair to say that the security situation is still evolving.