codesign

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

Hi, So, first off, there are actually three entitlements involved here that overlap each other to a significant extent: Increased Memory Limit -> com.apple.developer.kernel.increased-memory-limit entitlement. Increased Debugging Memory Limit -> com.apple.developer.kernel.increased-debugging-memory-limit Extended Virtual Addressing -> com.apple.developer.kernel.extended-virtual-addressing The first two (1 & 2) are fairly similar, with the difference being that, by design, the second (Debugging) variant will never be included in release builds. If you unintentionally used the second version, then that would immediately explain the failure you're seeing. In the interest of getting a response out I won't try to describe the difference between 1 & 3 beyond saying that the issues here are more complicated than get more memory. That leads to here: Used the same entitlement-enabled code and configuration for distribution. After installing the App Store version on the same device, we found the app now