It would help if you replied using a reply rather than the comments. That’d make it easier to read your text.
Originally you said "you do not need to specify --options runtime
when signing libraries. That flag is only necessary for main
executables".
That’s correct.
But when I follow those instruction, 6 of the tools say they need the
hardened runtime enable by notarization service
A command-line tool is a main executable. I’m using the terms from Signing a Mac Product For Distribution here, which says:
Is it a main executable? (apps, app extensions, command-line tools)
If you’re unsure, use the file command and look for executable in the result:
% file Test685263.app/Contents/MacOS/Test685263
…
… Mach-O 64-bit executable x86_64
… Mach-O 64-bit executable arm64
% file Test685263.app/Contents/Frameworks/libFFF.dylib
…
… Mach-O 64-bit dynamically linked shared library x86_64
… Mach-O 64-bit dynamically linked shared library arm64
so which is it...hardened or not hardened?
I think this is simply a case of you not understanding my terminology here [1], and I hope that the above has clarified that.
Also the doc you mention above says “You add entitlements only to
executables. Shared libraries, frameworks, and in-process plug-ins
inherit the entitlements of their host executable.”
That’s correct.
Clearly this is not the case, since I hardened the main executable but
it complains the child frameworks are not hardened.
OK, you’re definitely confused here. The hardened runtime is enabled by a code signing flag. This is different from entitlements, which is a separate property of the code signature.
Having said that, both the hardened runtime flag and the entitlements are only effective when applied to main executables.
Note Enabling the hardened runtime flag on library code is always benign. Adding entitlements to library code can prevent the code from loading.
I am not personally in control of the tooling here
OK. In that case you should escalate this with your tooling’s vendor. Their tooling should be able to produce products that are compatible with the hardened runtime.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Just to be sure, I created a small test app with a shared library and notarised that:
% codesign -d -vvv Test685263.app/Contents/MacOS/Test685263 2>&1 | grep flags
CodeDirectory v=20500 size=531 flags=0x10000(runtime) hashes=9+3 location=embedded
% codesign -d -vvv Test685263.app/Contents/Frameworks/libFFF.dylib 2>&1 | grep flags
CodeDirectory v=20400 size=330 flags=0x0(none) hashes=5+2 location=embedded
% curl "https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma125/…
{
…
"ticketContents": [
…
{
"path": "Test685263.zip/Test685263.app/Contents/Frameworks/libFFF.dylib",
"digestAlgorithm": "SHA-256",
"cdhash": "af3f614e0c4813a86791437f4f4246a757a0505b",
"arch": "x86_64"
},
…
],
"issues": null
}
As you can see, the app has the hardened runtime flag set and the library does not, and yet it still notarises just fine.
