“codesign”

Yes I'm referring to the files inside the .app. We need this info for statistics and create if possible also the reports. We execute the codesign inside a CI pipeline. Thanks

The impact of self-signed certificate expiration on the SDK. We have developed an SDK and signed it with a self-signed certificate. Our certificate will expire on January 30, 2025. After it expires, will there be any impact on apps that are already published on the App Store? If a user opens the app on January 31, 2025, will the app crash due to the expired self-signed certificate? Many apps have integrated our SDK, and this issue is very urgent and important for us. We kindly ask for your prompt reply. Thank you! Here are the steps we followed for signing: Self-signing steps: self-signed certificate xcframework Keychain creation: Certificate Assistant - Create Certificate - Self-signed Root Certificate + Code Signing Modify trust settings for the self-signed root certificate Sign the already packaged xcframework (Official command example) codesign --timestamp -v --sign Certificate Name ~/Desktop/MySDK.xcframework

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