codesign xpc

We are having issues code signing correctly the XPC services that are deployed with our app.

When checking in CLI I see the following

spctl --assess --verbose ./xxxxxx-xpc.xpc

./xxxxxxx-xpc.xpc: rejected (the code is valid but does not seem to be an app)


I really don't know where to take it from here. All targets are set to automatically manage sigining.

There is very little on the web about examples to how to porperly codesign XPC services.

We are using XCode 8.3.3


The XPC services reside in Contents/XPCServices


Can anyone provide some guidance ?

Accepted Reply

It sounds like you’re butting up against the keychain access control list (ACL). When an app creates an item in the keychain it defaults to having an ACL that only allows that app to access it. If you want other apps to access your item, you need to set the ACL when you create it. The Creating a Custom Keychain Item section of the Keychain Services Programming Guide shows how to do this.

There’s two things to note here:

  • The code in Listing 3-2 uses the old school

    SecKeychainItemCreateFromContent
    API to create the keychain item. If you’re using the SecItem API you can grab the
    createAccess
    function from Listing 3-2 and then pass in the resulting
    SecAccessRef
    to your
    SecItemAdd
    call via the
    kSecAttrAccess
    attribute.
  • This technique used to work between arbitrary apps. In recent versions of macOS it only works between apps from the same team. Fortunately that shouldn’t be a problem in your case.

    Note One of my colleagues filed a bug (r. 33635514) to get the Keychain Services Programming Guide updated to cover this change.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Replies

ok so doing some further test what is happening when launching the app that is codesigned for the first time.The XPC service needs to access the main.app keychain Username and Password in order to then chat with web services. When the app is first installed there is an OS allert indicating that XPC is trying to access the Main.app keychain entry , [Always Allow] [ Deny] [Allow] .
I would like to avoid this step so that the XPS service is allowed automatically and user does not need to provide input. if XPC is a target of the same app wouldd the system see it as part of it and not have to ask ?
My initial thought is that the system is asking to allow the entry because the XPC services are not certified correctly but maybe there is more or something different to it ?

Anyone ?

It sounds like you’re butting up against the keychain access control list (ACL). When an app creates an item in the keychain it defaults to having an ACL that only allows that app to access it. If you want other apps to access your item, you need to set the ACL when you create it. The Creating a Custom Keychain Item section of the Keychain Services Programming Guide shows how to do this.

There’s two things to note here:

  • The code in Listing 3-2 uses the old school

    SecKeychainItemCreateFromContent
    API to create the keychain item. If you’re using the SecItem API you can grab the
    createAccess
    function from Listing 3-2 and then pass in the resulting
    SecAccessRef
    to your
    SecItemAdd
    call via the
    kSecAttrAccess
    attribute.
  • This technique used to work between arbitrary apps. In recent versions of macOS it only works between apps from the same team. Fortunately that shouldn’t be a problem in your case.

    Note One of my colleagues filed a bug (r. 33635514) to get the Keychain Services Programming Guide updated to cover this change.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you !

We will test this and verify it corrects the issue.

But this does not correct the fact that when verifying the codesignature for the XPS service it shows up as rejected (the code is valid but does not seem to be an app). Or is this response normal when verifign and xpc service ?

But this does not correct the fact that when verifying the codesignature for the XPS service it shows up as rejected (the code is valid but does not seem to be an app). Or is this response normal when verifign and xpc service ?

Honestly, I don’t know. I deal with XPC Services a lot at the API level but I’ve never got into the ins and outs of code signing it. If you want at definitive answer to this you should open a DTS tech support incident and talk to our code signing experts.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"