There's a good answer here: https://apple.stackexchange.com/questions/258623/how-to-fix-killed-9-error-in-mac-os The key is, when copying binaries, to remove the existing destination before the copy. Or, just move if you can. This works for us.

We have this problem, too. Monterey, fully up to date as of today. Mini M1. Merely copying binaries can trigger it, where the originals work and the copies do not.

Right. My specific concern is setting DYLD_LIBRARY_PATH. Is that the approach you recommend to your customers? Or something else? Yes, we tell them to use DYLD_LIBRARY_PATH or put the OpenSSL libraries into the application directory, if they aren't in an environment where security is a concern.

Thanks for the confirmation, @eskimo. Appreciated. Having said that, I have some questions. You wrote: We have a language (Allegro Common Lisp) which has a module for making SSL connections. Can you explain more about the relationship between this language and your product. Is your product the language itself? Or are you using the language to build your actual product? The language is our product (google "Allegro Common Lisp" if you are curious). The language has a networking layer and one of the features is an SSL socket stream. Using OpenSSL (or LibreSSL) is how we provide SSL socket streams. We dynamically load the OpenSSL libraries because we want to get the latest, secure libraries. On Linux, we use the system libraries in standard places and loading it is trivial. On macOS, it's been a real hardship on our users (and us). Hopefully the entitlements above will make things much easier going forward.

I just found out about the com.apple.security.cs.allow-dyld-environment-variables entitlement. This seems to be the answer to my needs, but I'm worried about notarization with this entitlement being used.