A dylib fails to load under Hardened Runtime

• The Team in the signature of the dylib definitely needs to match, you should get detailed error messages if you run your app in the debugger with the hardened runtime enabled; it will list why a particular candidate was inappropriate. Make sure you're comparing the verbose output of codesign -d in the app and dylib

• LC_VERSION_MIN_MACOSX was replaced by LC_BUILD_VERSION, they should be equivalent for these purposes. I don't think it's possible to build a Mach-O binary without one of them.

• Relative paths should be fine, though @rpath is generally a better idea (any of the dylibs in Xcode.app/Contents/Frameworks are a good example), e.g. libclang.dylib is "@rpath/libclang.dylib" with an rpath of "@loader_path/../lib"

• Something like OpenSSL really deserves to be a framework, if you can manage it

Code Block 
Aug	4 16:38:30 MacBook-Pro-8 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.oneshot.0x1000004f.myapp[51169]): removing service since it exited with consistent failure - OS_REASON_EXEC | Gatekeeper policy blocked execution
Aug	4 16:38:41 MacBook-Pro-8 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.oneshot.0x10000050.myapp[51205]): Service exited with abnormal code: 2

Code Block 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.cs.disable-library-validation</key>
	<true/>
</dict>
</plist>

Code Block 
codesign \
	--force \
	--deep \
	--display \
	--verbose \
	--options=runtime \
	--timestamp \
	--entitlements ./hardened_runtime_entitlements.plist \
	--sign "MYAPPSIGNENTITY" MyApp.app

• Relying entirely on codesign --verify is not a good guide (as I've previously experienced). It doesn't check whole classes of issues related to signatures, dynamic libraries, entitlements, and code signature requirements

• Since you're building manually (makefiles or other, not Xcode), you're likely missing a particular flag or step. Replacing libcrypto with an empty dylib target built by Xcode might be one way of narrowing down the issue

• In my experience, library validation issues are best troubleshooted in the debugger, since dyld is pretty explicit when it can't find something

• I'm pretty sure --display (-d) and --sign (-s) are mutually-exclusive modes of codesign

• What was the exact issue you saw? You said your app stops loading the dylib, but how did you find out?

1. If I don't use install_name_tool on my executable (thus relying on OpenSSL being installed in the system), I can see a proper crash saying "Library not loaded: /usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib". If I make openssl available, everything is fine. This is a totally expected behaviour, also works with notarisation under hardened runtime rules.

2. If I use install_name_tool on my executable to change the path to the dylib as described in the original post, I can run the app fine without OpenSSL available in the system. This is how I know the dylib gets successfully loaded from my app bundle. However, not under hardened runtime. Once I add --options=runtime to the signing procedure, the app crashes immediately on start.

Code Block 
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>

Code Block 
codesign \
	--force \
	--deep \
	--verbose \
	--options=runtime \
	--timestamp \
	--entitlements ./osx/hardened_runtime_entitlements.plist \
	--sign "XXXXXXXX" MyApp.app

In rare cases, an app might need to override or patch C code, use the long deprecated NSCreateObjectFileImageFromMemory (which is fundamentally insecure), or use the DVDPlayback framework. Add the Allow Unsigned Executable Memory Entitlement to enable these use cases. Otherwise, the app might crash or behave in unexpected ways.

Including this entitlement exposes your app to common vulnerabilities in memory-unsafe code languages. Carefully consider whether your app needs this exception.

@TyngJJ I've found the correct entitlement by trial and error 🤷

While I'm not aware of all the implications as all of this is pretty new to me, I'm sure this is what caused the crash. The JIT entitlement is a different one btw.

it's SQLCipher that provides transparent database encryption over SQLite. But this is just a bit more funny because I use Golang bindings over SQLite and an SQLCipher Golang port. Which I attach to a go-flutter-desktop project as a plugin, that compiles by the means of CGO as a part of a Flutter project compiled with Hover for desktop. 

It's still a good question why the latest brew version of OpenSSL's libcrypto requires that entitlement. Probably building my own separate library of primitives is a good idea and thanks for bringing this to my attention.