Got it.
This has been some keychain misconfiguration issue.
User A's digital identity was spread over different keychains:
The certificate was located in the system keychain.
The related private key was located in the login keychain.
That's why keychain access did not show any digital identity under 'my certificates'.
codesign however was able to use these scattered items.
Additionally, other unrelated private keys were located in the system keychain.
This led me export a digital ID with an invalid combination of key and
certificate. This digital ID did not work for codesigning with user B.
Exporting the digital ID of User A with a valid combination of private key and
certificate and importing this for User B has solved the problem.
By the way, the following article has been very enlightened:
Certificate Signing Requests Explained: https://developer.apple.com/forums/thread/699268
Thanks!
Hi again,
We have now imported the p12 file into user B's login keychain via
security import IDENTITY_FILE.p12 -k login.keychain
After this, still the same behaviour: no identities listed from
security find-identity -p codesigning and codesign still throws
"The specified item could not be found in the keychain".
Reading your reply, I begin to wonder why user A stores it's identity
within the system keychain instead of the login keychain.
I can only state that codesigning works this way for user A.
Following https://developer.apple.com/forums/thread/699268 , digital
identities are listed in keyring within login / my certificates.
This ist not the case for both users A and B, not in system and not in login.
Mh ...
OK, got it.Solution:Additionally to the constraints listed above, set an absolute path in thefield LC_LOAD_DYLIB of the wrapper lib.Thanks,Markus
Ok, I am getting deeper into this ...New info:* dlerror() tells me 'image not found'.* I still do not see any related entries within system log. Especially syspolicyd keeps calm. Please see the attached log.I have currently 2 directions into which I investigate:1. Heterogenous IDE and toolchain setups for different modules2. Some dynamic link time resultion problem. Perhaps MacOS searches for dylibs more restrictive with hardened runtime enabled.1. IDE and toolchainHistorically, we compile our application and some of it's libs using differenttoolchains.* The application itself is recompiled frequently using MacOS 10.14 and XCode 11.* Some of our wrapper libs are not compiled together with our application. These binaries have been compiled using older versions of MacOS and XCode (still need to investigate the exact versions). For the one wrapper dylib that fails loading the 3rd party lib from /Libraries/Frameworks, otool -l shows LC_VERSION_MIN_MACOSX Version 10.7, SDK 10.12 This wrapper lib gets deployed within our bundle. Therefore it also gets signed with our Developer ID Application certificate.Finally our bundle and it's dependancies look like this:* BUNDLE/Contents/MacOS/APPLICATION LC_VERSION_MIN_MACOSX Version 10.10, SDK 10.15 Signed with -o runtime + entitlements, using our certificate* BUNDLE/Contents/Framework/WRAPPER_DYLIB LC_VERSION_MIN_MACOSX Version 10.7, SDK 10.12 Signed, using our certificate* /Libraries/Frameworks/FRAMEWORK_NAME.framework/Versions/A/3RD_PARTY_DYLIB LC_VERSION_MIN_MACOSX Version 10.9, SDK 10.12 Signed, using 3rd party certificateQ: In a chain like this, do all the bundle's internal modules need an LC_VERSION_MIN_MACOSX >= 10.9 or only the lib to be loaded from outside of the bundle?Q: We need hardened runtime and entitlements only for the application, not for the libraries, is this correct?2. Dynamic link time resultionThe other thing I see is that the wrapper lib contains a fieldLC_LOAD_DYLIB with an incomplete (and therefore relative?) path:"FRAMEWORK_NAME.framework/Versions/A/3RD_PARTY_LIB_NAME"No @rpath or similar prefix variables, but also no absolute path.Q: Running with hardened runtime and loading libs from /Libraries/Frameworks, do we need complete and absolute paths in LC_LOAD_DYLIB?Thanks,-Markus
