“codesign”

Hello, thanks a lot for your guidance. This is the error I am facing at the moment, tried some things but I am stuck: Prompting policy for hardened runtime; service: kTCCServiceAppleEvents requires entitlement com.apple.security.automation.apple-events but it is missing for accessing={TCCDProcess: identifier={APP_IDENTIFIER}, pid=63455, auid=502, euid=502, binary_path=[PATH_APP]}, requesting={TCCDProcess: identifier=com.apple.appleeventsd, pid=756, auid=55, euid=55, binary_path=/System/Library/CoreServices/appleeventsd}, What I did since last conversation was to move python libraries to the app and only the python executable is located in the bundle. Python.bundle/Contents Python.bundle/Contents/Info.plist Python.bundle/Contents/MacOS Python.bundle/Contents/MacOS/python3.11 Added to bundle Info.plist: CFBundleExecutable python3.11 Added to Python.entitlements: com.apple.security.inherit, with a Boolean value of true. Python bundle entitlements now looks like this: com.apple.security.app-sandbox com.apple.sec

[quote='808809022, bradleymcgill, /thread/764017?answerId=808809022#808809022, /profile/bradleymcgill'] we are using Maven so I believe this would be the link where the Jar we are getting is from … [/quote] Ta! I downloaded that, unzipped it, and looked at the signature: % codesign -d -vvv --entitlements - jffi-1.3.10-native/jni/Darwin/libjffi-1.2.jnilib … CodeDirectory v=20400 size=1547 flags=0x2(adhoc) hashes=42+2 location=embedded Hash type=sha256 size=32 … That looks reasonable enough. It’s ad hoc signed, which is pretty typical for this sort of thing. It has modern hashes, which is good. And it has no entitlements, which is also good. It also has a reasonable SDK value: % vtool -show-build jffi-1.3.10-native/jni/Darwin/libjffi-1.2.jnilib jffi-1.3.10-native/jni/Darwin/libjffi-1.2.jnilib (architecture x86_64): Load command 8 … version 10.6 sdk 12.0 jffi-1.3.10-native/jni/Darwin/libjffi-1.2.jnilib (architecture arm64): Load command 9 … minos 11.0 sdk 12.0 … Note The Intel deployment target is a bit

Run this in the same environment in which you’re running codesign: % curl -D /dev/stderr http://timestamp.apple.com What do you get back? Does it yield the same level of inconsistency, that is, working sometimes and failing others? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='766224021, pnelson, /thread/766224, /profile/pnelson'] There should be a way to build a PAM module (dynamic Library ) so it can be code signed. [/quote] It’s certainly possible to sign a PAM module: % cp /usr/lib/pam/pam_deny.so.2 . % codesign -s - -f pam_deny.so.2 pam_deny.so.2: replacing existing signature However, that won’t help when it comes to -setCodeSigningRequirement:. macOS enforces security as process boundaries. PAM modules are in-process plug-ins, so they can’t be distinguished from any other code running in that process. Thus, from the perspective of the XPC remote peer, you can’t tell whether the request came from the PAM module running inside the process or any other code running inside that process. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

A bit of a late reply on this, but I have a few things to share: As far as I can tell Xcode 16 has fixed all of these issues. Set codesigning to automatic, configure your capabilities in Xcode, and it signs everything exactly the way it should. I haven't specifically tested enterprise distribution (I don't have an account of that type at hand), but the automatic flows have worked perfectly for Developer ID and Mac App Store Test Flight. If it's all possible, I think building and signing with Xcode 16 is the easiest solution to all this. If you must use Xcode 15.4, then you need to be very careful about he exact flow involved. You're right that this is the underlying issue: I'm assuming this has to do with the fact that the entitlements plist is using the wildcard * instead of a proper vendor id. The wildcard value is why the development profiles can work with everything, which is also what breaks distribution signing. Here is what you can try to resolve this: I'm not sure how this stands in Xcode 15.

Hi Quinn, The jar we are trying to sign is jffi from https://github.com/jnr/jffi/releases/tag/jffi-1.3.10. We are extracting the libjffi-1.2.jnilib from the jar and signing before re-packing them. This step goes fine with nothing going wrong. We then get issues when trying to notarize the application where it says the binary isn't signed, the signature isn't valid and there isn't a valid timestamp. sign-jar-force ./Contents/Resources/xx/drivers/jffi-1.3.10-native.jar jni/Darwin/libjffi-1.2.jnilib sign-jar() { if [ -e $$app_path/$1 ]; then echo Signing (jar): $1 $2 unzip $app_path/$1 $2 -d $temp_path || echo (jar $1): unzipping $2 failed > $temp_path/.failed codesign --sign $sign_identity --timestamp $temp_path/$2 || echo (jar $app_path/$1): $temp_path/$2 > $temp_path/.failed jar -ufv $app_path/$1 $temp_path/$2 || echo (jar $1) zipping $temp_path/$2 > $temp_path/.failed rm -f $temp_path/$2 else echo Skipping: $1 (path not found) fi } This is our method for signing the jar. We have also tried

Hello, I've made a very good progress. following the changes you indicated the app works :) There is only a little detail, if python executable is moved to: SampleApp.app/Contents/MacOS/python3.11 It appears a pop up asking 'Allow [APP] to find devices on local networks?'. I tested the app placing python here: SampleApp.app/Contents/MacOS/bin/python3.11 and the app works the same but the pop up is not appearing. This is a capability is not requested in the app... I'm very curious to know why this happens. Let me share the changes that were applied: This is the new entitlements: com.apple.security.app-sandbox I enabled Hardened Runtime in Build Settings - Signing section. What about lib/python3.11. That’s not a single file, right? It’s a directory containing a hierarchy of Python goo, right? Yes, it is a folder with all the libraries, etc. Is it ok when the folder stays in Resources? Last change I made is to remove the --deep when signing python executable, now it looks like this: codesign --force --

Your app has a number of code signing issues that will cause problems. First, the immediate problem you’re seeing is caused by the absence of the App ID entitlement in your main app’s code signature: % codesign -d --entitlements - Remote for Mac.app Executable=/Users/quinn/Desktop/Remote for Mac.app/Contents/MacOS/Remote for Mac [Dict] [Key] com.apple.developer.networking.multicast [Value] [Bool] true [Key] com.apple.developer.persistent-content-capture [Value] [Bool] true [Key] com.apple.security.automation.apple-events [Value] [Bool] true Without this, older systems are unable to match up your app’s profile with its code. See Check for Required Entitlements within Resolving Code Signing Crashes on Launch. Note That’s part of my Resolving Trusted Execution Problems, which contains answers to all the weird trusted execution problems I’ve encountered over the years. Beyond that, I see other concerns. Your app contains a bunch of executables: % find Remote for Mac.app -print0 | xargs -0 file | grep exe