codesign

Detailed Analysis of the Logs These logs provide a snapshot of system activity and processes, including detailed information about framework usage, threading, and potential performance issues. Below is a breakdown of the logs and an analysis of possible tampering or anomalies. General Observations Key Frameworks and Libraries 1. Foundation & CoreFoundation: • Used for fundamental data manipulation and interaction between processes. Commonly seen in most application logs. 2. QuartzCore: • Graphics and animation rendering. Frequent recursive calls suggest heavy graphical processing. 3. libdispatch: • Task and thread queue management. Repeated invocations at specific offsets (+ 16296, + 49444) indicate high inter-thread activity. 4. AccountsDaemon: • Manages user accounts and synchronization. Persistent queries indicate high activity related to account management. 5. CoreData: • Backend database system; multiple recursive calls (+ 523316, + 182512) suggest inefficiencies in database interactions. Recurrent P

I found a solution to this problem after losing a full day. Thanks again to Apple for releasing an update that serves no purpose other than making life even harder for us developers. Every time an update is released, I dread installing it because I know very well that many apps will stop working after the update. I had coded two applications that use iTunesLibrary. They worked perfectly before, but now they don't work anymore, throwing the same error: Code=4097 connection to service named com.apple.amp.library.framework. Based on the documentation, I suspected an issue with sandboxing, entitlements, or binary signing ... but no, that wasn’t the root of the problem. After trying to mimic some behaviors of the Music app, like com.apple.amp.artwork.client, com.apple.amp.devices.client, com.apple.amp.library.client, com.apple.security.files.user-selected.read-only ... and experimenting with various options (some documented, some not), I stumbled upon something incredible that gave me the solution: I had moved my

Sorry it’s taken me a few days to wade in here; I’m only now just catching up with the backlog that built up over the winter break. [quote='772227021, FCG, /thread/772227, /profile/FCG'] Could this issue also be related to a code signing configuration that needs adjustment? [/quote] On your part? No. First, some background. When you call the PAM API, PAM loads plug-ins into your process. This is subject to library validation, as explained here. IMPORTANT The following discusses implementation details that will help you understand what’s going on, but are not considered API. Don’t ship products that rely on this stuff. The exact rules for library validation are different for code that’s built-in to the OS [1]. For third-party code you have to opt in to library validation, either directly, via the library option when signing your code, or indirectly, via the hardened runtime. In contrast, built-in code is always subject to library validation, with an option to opt out. You can see this in action with the author

Hi @szigetics_nt szigetics_nt, Thank you for you commands and i was able to trust the certificate by creating a package with composer and user these commands in this way through post install script. sudo /usr/bin/security authorizationdb write com.apple.trust-settings.admin allow sudo security add-trusted-cert -p codeSign -p pkgSign -d -r trustAsRoot -k /Library/Keychains/System.keychain /private/tmp/Nexthink/SCTASK8557870_Nexthink.cer sudo /usr/bin/security authorizationdb write com.apple.trust-settings.admin admin you can edit the script as per your certificate and requirement. Also, if you can with the command to temporarily disable and re-enable the confirmation dialog for macOS sequoia then it will greatley helpful

Everything you described above makes sense, except that a Release build with this same entitlements file doesn't work. I don't know a lot about Direct Distribution. My understanding is that it is the same as Developer ID distribution mentioned in Supported capabilities (macOS). If that's the case, CloudKit should be supported. My guess is that your app probably has something wrong about entitlements, which prevents it from using CloudKit. To confirm that, you can: Try to capture a sysdiagnose and find relevant error messages from there. This topic is covered in Capture and analyze a sysdiagnose. Use the following command line tool to dump the entitlements claimed by your app, and check if there is no difference between the the Release and Debug builds. $ codesign --display --entitlements - Also, if you can detail the steps about how you produced the Release build, I'd see if I can find something relevant. Best, —— Ziqiao Chen  Worldwide Developer Relations.

I just started running into this a few days ago and I'm not sure why. Same behavior as described above. Everything is working fine, then I need to connect to a VPN for work and when I disconnect from the VPN and try to build the app again and deploy it to the phone, it fails with: Warning: unable to build chain to self-signed root for signer Apple Development: {redacted} (redacted) Command CodeSign failed with a nonzero exit code There is also mention of errSecInternalComponent. If I open keychain on my Mac, I see that my development certificate now says that it's not trusted. And indeed, as julian99 stated, if I change the trust settings to Always Trust, close that window, re-open the certificate again, change the trust settings back to Use System Defaults and then close the window again, it fixes the problem. For added fun, I have to connect and disconnect from the VPN a lot during the work day because the VPN configuration blocks all IPv6 traffic (including link-local traffic) so when I'm connecte

So, we actually need to stop right here: I'm using SMJobSubmit Stop using SMJobSubmit. That API was deprecated in 10.10 (seven years ago) and I believe we'd been recommending against it for several years. The modern replacement is SMAppService, introduced in macOS 13.0. Note that this is a modern replacement, in that it specifically supports privileged helper tools embedded inside app bundles. Keep in mind that doing this: The tool is embedded in the Contents/MacOS folder. ...is not safe with SMJobSubmit and never has been. SMJobSubmit is hard coding the executable path, which means the user renaming your app (or any other manipulation) will both break your job and create an opening which could allow an attacker to insert their executable in place of your job. If you need to support older systems, then the recommended approach would be to use SMJobBless as shown in EvenBetterAuthorization to install a privileged helper tool. The helper can then be used as the target for a launchd plist, which the privileged h