Keychain error -34018 (errSecMissingEntitlement)

Is there an update on how to fix this while debugging? There's multiple issues at hand it seems:

1) This occurs only while debugging (what I'm seeing)

2) This occurs in production.

It would be nice to know the status of each as neither seems to be fixed at this time.

Quinn - can you verify that under 9.3.1 that the device has to be restarted before access to the keychain for the affected app is restored? I ask because I believe we've captured a log file for this bug however when I quit the app (removed it from the multitask tray) and then restarted the app there was no problem retrieving the keychain values. Device was never rebooted between succes, failure, and success.

I've posted the console log file to

23930504

The interesting part of this log is where it says: CoreAnimation: insecure context 87d24880 - pid 5084 - is possible to determine if its relevant to this bug or another issue altogether? 5084 was the PID of the app in question.

Device was never rebooted between succes, failure, and success.

Restarting the device is not a factor here; when things fail in this way, they fail for a specific process.

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

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

Quinn - Thank you.

Two new log files have been added to 23930504 this morning; one showing a succes (no bug) on one captured when the bug occurred. I captured the logs with this process:

- Quit Xcode, machine rebooted.

- Apple Configurator 2 is launched.

- Phone unlocked.

- Docked with Apple Configurator 2, console log cleared.

- App is launched - console log saved.

We recreate the bug 'almost' regularly by waiting 12 hours between launching the app - the app is not removed from the multi-task tray. I know that an app that goes into the background goes through many stages prior to being completely flushed from the system, but at what time does the PID change?

Quinn,

I just received word that the bugs I was posting log files "is a duplicate of 18766047 and will be closed." Does that mean you no longer need any log files?

I'm hitting this error Every Time, and it only happens after I re-sign my app.

Essentially I build my app Ad-Hoc with an Ad-Hoc profile to use for internal testing and such (and the inital build works perfectly), and then I re-sign the app for production (also adding the beta entitlements at that time). Once it's re-signed, the app will run perfectly on newer devices (64bit, iPhone 5S and up), but gives a startup crash on older devices (32bit, iPhone 5 and down).

Jul  7 11:01:02 Company-iPhone-4S SpringBoard[48] :  SecTrustEvaluate  [leaf IssuerCommonName SubjectCommonName]
Jul  7 11:01:02 Company-iPhone-4S SpringBoard[48] :  SecTrustEvaluate  [leaf IssuerCommonName SubjectCommonName]
Jul  7 11:01:02 Company-iPhone-4S SpringBoard[48] :  SecTrustEvaluate  [leaf IssuerCommonName SubjectCommonName]
Jul  7 11:01:02 Company-iPhone-4S securityd[86] :  secTaskDiagnoseEntitlements MISSING keychain entitlements: no stored taskRef found
Jul  7 11:01:02 Company-iPhone-4S securityd[86] :  secTaskDiagnoseEntitlements MISSING keychain entitlements: no stored taskRef found
Jul  7 11:01:02 Company-iPhone-4S amfid[312] :  SecTrustEvaluate  [leaf IssuerCommonName SubjectCommonName]
Jul  7 11:01:02 Company-iPhone-4S securityd[86] :  secTaskDiagnoseEntitlements MISSING keychain entitlements: no stored taskRef found
Jul  7 11:01:02 Company-iPhone-4S securityd[86] :  secTaskDiagnoseEntitlements MISSING keychain entitlements: no stored taskRef found
Jul  7 11:01:02 Company-iPhone-4S amfid[312] :  SecTrustEvaluate  [leaf IssuerCommonName SubjectCommonName]
Jul  7 11:01:02 Company-iPhone-4S kernel[0] : xpcproxy[359] Container: /private/var/mobile/Containers/Data/Application/877013A4-BF2A-4AC9-8CEA-1598EA2CD336 (sandbox)
Jul  7 11:01:02 Company-iPhone-4S com.apple.xpc.launchd[1] : assertion failed: 13F69: launchd + 85529 [083E000D-4C31-3B98-A2C4-6FADB4D1940F]: 0x3
Jul  7 11:01:02 Company-iPhone-4S MyCompMyAppMobileiOS[359] : Found new TLS offset at 176
Jul  7 11:01:02 Company-iPhone-4S MyCompMyAppMobileiOS[359] : The assembly mscorlib.dll was not found or could not be loaded.
Jul  7 11:01:02 Company-iPhone-4S MyCompMyAppMobileiOS[359] : It should have been installed in the `/Users/builder/data/lanes/3412/3cf8aaed/source/maccore/builds/install/target7/lib/mono/2.1/mscorlib.dll' directory.
Jul  7 11:01:02 Company-iPhone-4S com.apple.xpc.launchd[1] (UIKitApplication:com.MyComp.mobile[0x3eca][359]) : Service exited with abnormal code: 1
Jul  7 11:01:02 Company-iPhone-4S SpringBoard[48] : Application 'UIKitApplication:com.MyComp.mobile[0x3eca]' exited voluntarily.
Jul  7 11:01:03 Company-iPhone-4S kernel[0] : xpcproxy[360] Container: /private/var/mobile/Containers/Data/Application/877013A4-BF2A-4AC9-8CEA-1598EA2CD336 (sandbox)
Jul  7 11:01:03 Company-iPhone-4S com.apple.xpc.launchd[1] : assertion failed: 13F69: launchd + 85529 [083E000D-4C31-3B98-A2C4-6FADB4D1940F]: 0x3
Jul  7 11:01:03 Company-iPhone-4S MyCompMyAppMobileiOS[360] : Found new TLS offset at 176
Jul  7 11:01:03 Company-iPhone-4S MyCompMyAppMobileiOS[360] : The assembly mscorlib.dll was not found or could not be loaded.
Jul  7 11:01:03 Company-iPhone-4S MyCompMyAppMobileiOS[360] : It should have been installed in the `/Users/builder/data/lanes/3412/3cf8aaed/source/maccore/builds/install/target7/lib/mono/2.1/mscorlib.dll' directory.
Jul  7 11:01:03 Company-iPhone-4S com.apple.xpc.launchd[1] (UIKitApplication:com.MyComp.mobile[0xc803][360]) : Service exited with abnormal code: 1
Jul  7 11:01:03 Company-iPhone-4S SpringBoard[48] : Application 'UIKitApplication:com.MyComp.mobile[0xc803]' exited voluntarily.

Now I'm sure the architecture has nothing to do with it, but I'm super baffeled by this error and I have no clue how to properly sign the app to prevent the issue.

#!/bin/bash
set -e # exit on first error.
EXPECTED_ARGS=6
E_BADARGS=1


#verify correct usage
if [ $# -ne $EXPECTED_ARGS ]
then
  echo "Usage: `basename $0` environment_name package_name certificate_name app_id app_version"
  exit $E_BADARGS
fi


ENVIRONMENT_NAME="$(tr [A-Z] [a-z] <<< "$(basename "$1")")"
APPNAME=$(basename "$2")
CERTIFICATE_NAME=$(basename "$3")
APP_ID=$(basename "$4")
PROVISIONING_PROFILE="$ENVIRONMENT_NAME.mobileprovision"
APP_VERSION=$(basename "$5")
BUILD_SERVER_PASSWORD=$(basename "$6")
APPFOLDER=$(find ~/Desktop -maxdepth 1 -type d -name "$APPNAME-*" | head -1)


echo "Unlocking OS X Keychain"
security unlock-keychain -p $BUILD_SERVER_PASSWORD ~/Library/Keychains/login.keychain


echo "Refreshing provisioning profiles."
# if the sigh command fails, you might need to change the password within the build servers login/passwords keychain.
# the name is `deliver.me@mycompany.com`
# note: you MUST use a developer account here. If chase is no longer with fortis, you'll
#       have to add a new `-u` user and add their password to the login/passwords keychain.


export PATH=$PATH:/usr/local/bin
if [ "$ENVIRONMENT_NAME" == 'production' ]
then
  sigh -a "$APP_ID" -u "me@mycompany.com" -o ~/Desktop -q "$PROVISIONING_PROFILE" --force --skip_install
else
  sigh -a "$APP_ID" -u "me@mycompany.com" -o ~/Desktop -q "$PROVISIONING_PROFILE" --force --skip_install --adhoc
fi


echo "Replacing the provisioning profile in Payload/$APPNAME.app/embedded.mobileprovision with $PROVISIONING_PROFILE"
mv ~/Desktop/$PROVISIONING_PROFILE ${APPFOLDER}/Payload/$APPNAME.app/embedded.mobileprovision


echo "Re-Signing application"
/usr/bin/codesign -f -s "$CERTIFICATE_NAME" --entitlements="${APPFOLDER}/entitlements.plist" "${APPFOLDER}/Payload/$APPNAME.app"


echo "Verifying app"
/usr/bin/codesign -dvvv ${APPFOLDER}/Payload/$APPNAME.app


echo "creating archive directory if it doesn't already exist"
mkdir -p ~/Desktop/Archive/$ENVIRONMENT_NAME


echo "Packaging the new application"
pushd ${APPFOLDER}
zip -qr ~/Desktop/Archive/$ENVIRONMENT_NAME/$APPNAME-$APP_VERSION.ipa Payload
popd
if [ ! -f ~/Desktop/Archive/$ENVIRONMENT_NAME/$APPNAME-$APP_VERSION.ipa ]
then
    echo "~/Desktop/Archive/$ENVIRONMENT_NAME/$APPNAME-$APP_VERSION.ipa not found!" 1>&2
    exit 1
fi


echo "removing ${APPFOLDER} folder from OS X Build Server"
rm -rf ${APPFOLDER}


echo "Created ~/Desktop/Archive/$ENVIRONMENT_NAME/$APPNAME-$APP_VERSION.ipa"


exit

Hello dear, friend if you like the app telegram to telegram can stay in touch if you please give your telegram ID?

It seems like this issue has resurfaced with Xcode 8 beta 2, and now beta 3.

https://forums.developer.apple.com/thread/51071

For me this error is happening in a Swift framework. It appears that enabling keychain sharing can make the problem go away if running in an example app. However, if running under unit tests, it fails every time in the simulator.

The problem is ALWAYS reproducable in Xcode 8 beta 2 and beta 3, iOS 10 simulator. Function always returns SecItemAdd error code -34018.

See the radar for a code example.

https://openradar.appspot.com/27422249

I'm not sure to what point this is relevant, but I'm also using Xcode 8, Beta 3 and I have a very simple keychain code like so:

        private func saveValueInKeychain(_ value: String, forKey key: String) {
            var keychainDic = [NSObject : NSObject]()
            let fixedKey = key + "_" + self.name
    
            keychainDic[kSecClass] = kSecClassGenericPassword
            keychainDic[kSecAttrAccessible] = kSecAttrAccessibleWhenUnlocked
            keychainDic[kSecAttrAccount] = fixedKey
    
            if(SecItemCopyMatching(keychainDic, nil) != noErr) {
                /
                keychainDic[kSecValueData] = value.data(using: .utf8)
                let sts = SecItemAdd(keychainDic, nil)
                print("Keychain status saving: \(sts)")
            }
        }

This fails on my Unit Tests. If it matters, this is a Framework project.

Keychain status saving: -34018

But it works fine on an actual app when running it on the simulator:

Keychain status saving: 0

BUT, it did not work on my first try. It started returning 0 when I enabled shared keychain on my Entitlements. This small app does not need shared keychain entilements, but if I don't enable them, I get the error -34018.

Exactly what I'm seeing. Failing on Xcode 8 beta 4 as well. 😟

I'm also seeing this on XC8b4

Just tested and still seeing this issue in Xcode 8 Beta 6.

YES!! THANK YOU!

I lost several hours to debugging this today. After updating our iOS app to Swift 3 and Xcode 8.0b6, all Keychain accesses in our application were failing during unit testing, on a real device or in the simulator. I nuked all codesigning stuff from orbit, rebuilt it all manually, nuked it again and let Xcode try its "automagic" mode, and repeated this with various build settings tweaks... nothing worked and the app couldn't be tested.

And, because of the insane multi-year legacy of the "Keychain error -34018", there are tons of red herrings and unrelated threads on the interweb tubes, and rabbit holes to go down.

But, eventually I got to the end of this thread, and saw your tip to enable the "Keychain Sharing" entitlement for the main application being tested.

Et voilà. Xcode can run all the automated tests that involve the Keychain (SecItemAdd(), SecItemDelete() and friends...) and they all now work, rather than returning errSecMissingEntitlement (-34018).

So, thanks to your comment, my problems are totally solved. Sorry I can't help you with your remaining issues, but I just wanted to note for the record that your tip, at least in the case of my vanilla iOS-app-plus-test-bundle case, totally fixed things.

Same here. I cannot seem to get our app running on any simulator using Xcode 8 Beta 6, as we raise an exception (crash) on unexpected keychain errors.