“codesign”

It looks ilke you have two certificates in your keychain (Koot Software Design and Mac Developer: C.J. Koot (MFNVQX3C9R)) which match your search term “Koot Software Design”. You can either delete one of those certificates or supply a more specific search term.One option here is to supply a SHA-1 hash of the specific certificate you want to use. The codesign man page has the details. You can see the SHA-1 hash of a certificate in Keychain Access. Double click the certificate and scroll to the bottom. You’ll find a section labelled Fingerprints, which contains SHA-1 and MD5 hashes of the certificate.Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Quinn, I have the same issue with a keychain in my app. It seems to happen when I move my application bundle in a different place on disk. For example: the app is launched from the ~/Downloads folder and a new keychain item is created. As far as the app stays in place I can update or delete my keychain item as I like. But after the app is moved to another path, like /Applications (or whatever) I only can read, but cannon remove the item from the keychain. I get errSecInvalidOwnerEdit error. I am definitely sure there are no issues with codesign. Would you please help? It seems to me that this observed differentiation of apps based on their launch path is extremely limited and inconvenient. IMO Keychain ACL should differentiate apps based on their identity, not their location. On Mac it's perfectly legal to duplicate apps, move them around and so on...Update: It seems like you have to rename the app bundle to reproduce this issue.

Cause and solution: http://stackoverflow.com/questions/41865537/how-does-apples-codesign-utility-decide-which-sha-algorithms-to-sign-a-shared

Can one restrict XPC communications to only occur between processes that share the same code signing identity? Yes. Well, you probably don’t want the same core signing identity (in general, each separate executable should have its own identity) but rather you want to evaluate code signing requirements for the client, and you can definitely do that. There are two basic tools for this: Various properties on the XPC connection (like NSXPCConnection’s auditSessionIdentifier, processIdentifier, effectiveUserIdentifier, and effectiveGroupIdentifier properties, and the equivalent C functions to get these values from an xpc_connection_t) Various security APIs, most notably the code signing API () The exact way in which you combine these is up to you, but here’s an example of how you might restrict access to your service to just your app: When a client makes a connection to your service, get the process ID of the client from that connection. If you’re using NSXPCConnection, you should do this in your -listener:shouldA

Hey Ross, did you get an answer on this? Because this enterprise distribution cert is used to codesign apps and not for encrypting internet traffic, did you still have to adhere to the company's date for cuting over to SHA-2?

1. I am applying for APP ID I found some difference between OSX and iOS in iOS it has the key of APP Groups but in OSX do not have the key of APP GroupI’m having a hard time parsing your text, but I believe you’re referring to the app group prefix here. And yes, there is a difference: on macOS the app group identifier is prefixed by the the Team ID, whereas that’s not the case on iOS. For example, here’s what I see when I dump the entitlements of my macOS test app:$ codesign -d --entitlements :- build/Debug/QNEPacketTunnel.app … <dict> … <key>com.apple.security.application-groups</key> <array> <string>VR9NTVC6BB.com.example.apple-samplecode.QNE-macOS</string> </array> </dict> </plist>And here’s the output for the iOS version of that app:$ codesign -d --entitlements :- build/Debug-iphoneos/QNEPacketTunnel.app … <dict> … <key>com.apple.security.application-groups</key> <array> <string>group.com.example.apple-sa