Is it correct to codesign dylib/framewoks with entitlements? My understanding is that only executables need to have the entitlement and the dylibs loaded in that process will automatically inherit those entitlements.
However, I am seeing a lot of scripts on the internet that are signing dylibs as well with entitlements. For eg -
# sign *.dylibs
find "$APP_BUNDLE" -type f -name "*.dylib" -exec codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements "$ENTITLEMENTS_FILE" --sign "$SIGNING_IDENTITY" {} \;
Is this even allowed? I know of at least one app that has passed notarization checks as well. If allowed, can a dylib have more entitlements than the process that loaded it?
Is it correct to codesign dylib/framewoks with entitlements?
No. It’s never correct to do that. Entitlements are only useful when applied to a main executable and can cause problems when applied to library code.
Is this even allowed?
Depends on what you mean by “allowed”. It never does anything useful. It won’t be caught by either App Store Connect or notarisation. In most cases it’s benign. In some specific cases it will cause your program to be blocked by the trusted execution system.
I know of at least one app that has passed notarization checks as well.
The goal of the notary service is for software to be “checked by Apple for malicious components”. It doesn’t audit your program for correctness, except as necessary to perform that goal. You can notarise a program that dereferences NULL, and likewise you can notarise a program with pointless and potentially harmful entitlement claims.
If allowed, can a dylib have more entitlements than the process that loaded it?
No. That concept is nonsensical. Apple platforms enforce permissions checks at the process boundary, so it’s impossible for a library loaded in your process to have different permissions than the process itself.
I am seeing a lot of scripts on the internet
What can I say… Don’t believe what you read on the Internet (-: especially when it comes to code signing )-:
Since taking over as DTS’s lead for Mac code signing back in… oh gosh… that was in 2019!… I’ve been trying to correct this misconception. For example…
Creating distribution-signed code for macOS says:
IMPORTANT Don’t apply entitlements to library code. It doesn’t do anything useful and can prevent your code from running.
The Restricted Entitlements on Library Code section of my Resolving Library Loading Problems DevForums post says:
Entitlements are only effective when applied to a main executable. Code that isn’t a main executable is called library code, and that includes frameworks, dynamic libraries, and bundles. Do not apply entitlements to library code. At best it’s benign. At worse, it causes a code signing crash like this.
And --deep Considered Harmful references that as one of the key reasons that signing with --deep is a bad idea.
But, you know, sometimes the Internet latches on to these things and won’t let go [1]. If you see folks making this mistake, I’d appreciate you correcting them.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] I’m still grumpy about folks calling a PowerBook G3 (bronze keyboard) a Lombard.