Dear apple folks, we try to establish command line based codesigning for a second user account on a machine, where it already works for another user account. User A is able to run the codesign tool like this: /usr/bin/codesign --verbose \ --timestamp \ -o runtime \ --entitlements $BASEDIR/entitlements.plist \ --sign "Developer ID Application: OUR COMPANY" \ OUR_APP.app With keychain, user A sees the following objects within the system area: A private key of OUR COMPANY The Developer ID Application certificate for OUR COMPANY User A can ask security find-identity -p codesigning and gets an output with 1 matching and 1 valid identity. This is fine so far. Not so user B. With keychain, user B sees the same objects within the sytem area as user A on this same machine. But security find-identity lists 0 identities and codesign tells user B "The specified item could not be found in the keychain". So: although the items are visible in keychain, somehow, the identity is not accessible for user B. At this point we have a lack of understanding how this is supposed to work. Can 2 users on one machine share one digital identity for codesigning? Or does user B need a second identity? We have then executed the steps in thread https://developer.apple.com/forums/thread/660871 meaning: we exported the digital identity consisting of private key and the developer ID application certificate with user A to a p12 file using keychain access. we imported this p12 file with user B via the command security import IDENTITY_FILE.p12 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". Any ideas?

Dear Apple folks,we develop a C++ application that depends on another 3rd partylibrary which is installed under /Library/frameworks.This library is optionally loaded dynamically at runtime by a call todlopen().So far, we have signed our application successfully with ourDeveloper ID Application certificate.For notarization, we have enabled the hardened runtime option in ourapplication signature process.With hardened runtime enabled, this library loading does not workanymore on MacOS 10.14 and 10.15.Following the Apple documentation and several developer forum threadsI have already checked the following constraints:* The application is signed using a secure timestamp.* The application is signed without using the option 'deep'.* The 3rd party lib is signed by it's vendor with their Developer ID Application certificate.* The lib's deployment target is MacOS 10.9 or higher (LC_VERSION_MIN_MACOSX).* The lib's installation name is fixed under /Library/Frameworks. (LC_ID_DYLIB, calling otool -l on the lib, is this correct?).* As the lib uses another certificate than the application, the application enables the disable-library-validation entitlement. This has been checked via codesign -d --entitlements :- on the app.* Enabling all hardened runtime related entitlements for test purposes does not help.To be clear again:* A signed application without option 'hardened runtime' loads the lib successfully.* A signed application with option 'hardened runtime' enabled and all related entitlements enabled fails loading the lib.I do not see any relevant error messages so far:* If the application is executed from a terminal, it does not produce any error output.* The system log does not produce related messages (or I do not see them).* I do not see any dyld related messages (Where should I find them?).* codesign --verify --verbose=4 APP_BUNDLE says 'valid on disk'.* spctl --verbose?4 --assess --type execute APP_BUNDLE says 'accepted'.So, how can I gather more information from the system about why itforbids to load the lib?Do you have any other ideas for me?Thanks,-Markus