Debug-only read errors: errSecMissingEntitlement -34018

[jcampbell05]

Hey, Do you know if its possible to use the same instance across threads ?

We have an issue where we can write but we don't get the data back when reading. However when we run this on the main queue it is okay.

[dfed]

Valet is built with the intent to allow allow using the same instance across multiple threads, so this should indeed work. Is it possible you've got a timing issue? Try adding a break point on the return line of objectForKey: and setObject:forKey: to see what your timing is. If the order of operations is what you're expecting, I'm curious what the status code is on the failed objectForKey:

[EricMuller22]

And just to help with diagnosis, mind providing us with which platform and which Valet subclass you're using?

[jcampbell05]

This is as much as we know.

We added some breakpoints and they execute in the correct order, we tried this using FXKeychain and it logs out an error code -34018 (Something I think Valet should do when there is an error).

This error seems to mean that either our bundle ID doesn't match the one used to write/read to the keychain or we don't have the correct entitlements if it's a shared one.

We used the normal Valet subclass for accessing the keychain, the weird thing is when we run the exact same app not from Xcode it works perfectly. And sometimes running it from Xcode it will be perfectly okay especially if you've ran the app untethered beforehand but then suddenly we will just get that error.

It primarily happens on a iPhone 6 / 6 Plus under iOS 8.3, we don't get it on a iPod Touch.

We've tried to research this online, it seems some people have this issue but so far no solutions.

[dfed]

This is a debug-only entitlement issue, not a threading issue. Sometimes Xcode fails to sign the debug build properly, which can cause this error. We saw this a whole lot on Xcode 6.2 IIRC, but we haven't seen it since upgrading to 6.3. [valet canAccessKeychain] will return NO in this state. We worked around this issue by asserting canAccessKeychain in application:didFinishLaunchingWithOptions: under #if DEBUG. That way we knew right off the bat if Xcode/entitlements had screwed up. This issue never affected our signed enterprise builds or our signed app store builds.

Any chance you aren't running the latest version of Xcode?

EDIT: Never mind, you're running on iOS 8.3, which means you must be using Xcode 6.3+. Maybe it was Xcode 6.3 that caused the issue and upgrading to Xcode 6.3.2 fixed it? I don't recall the exact scheme that fixed it, but a couple months ago we were seeing this error daily, and now we aren't – and we haven't made any changes to Valet or how we use Valet that could affect this issue since then. The only other change we've made regarding entitlements since then is to regenerate our then about-to-expire provisioning profile. If I remember correctly we encountered this issue in the week or two leading up to our internal (not App Store) provisioning profile expiring.

[jcampbell05]

So we did some more research and we found out that one of our developers is using OS X 10.11. And it seems the combination of Xcode 6.3.2, OS X 10.11 and iOS 8.3 causes this issue.

We have filed a radar with Apple to help shed some light on the issue, but that information is very interesting.

[dfed]

Something to look forward to when we upgrade our machines I guess 😕. Thanks for filing the radar!

I'm closing this issue since it seems resolved. If you get any updates to the radar, please do share them.