-
Re: Intermittent -34018 errors from users in the field
tijmen Oct 4, 2016 5:11 AM (in response to eskimo)We raise an exception (/crash) when any unexpected keychain status code is returned. So our crash logs alert us to problems with the keychain. Sadly the exception text is not included so I cannot confirm it is error -34018.
At the moment, we have a couple of crash logs with Keychain problems, including one on iOS 10.0.1. Does that qualify as the latest release or should we only be looking for iOS 10.0.2 and higher?
-
Re: Intermittent -34018 errors from users in the field
eskimo Oct 5, 2016 1:35 AM (in response to tijmen)Sadly the exception text is not included so I cannot confirm it is error -34018.
Bummer. Can you rev your app so that the error code gets included in the log?
At the moment, we have a couple of crash logs with Keychain problems, including one on iOS 10.0.1. Does that qualify as the latest release or should we only be looking for iOS 10.0.2 and higher?
Yeah. AFAIK 10.0.2 did not include any fixes specific to this issue. However, it’s not necessarily relevant without knowing what error you got.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardwarelet myEmail = "eskimo" + "1" + "@apple.com"
-
Re: Intermittent -34018 errors from users in the field
tijmen Oct 11, 2016 2:20 AM (in response to eskimo)Sure, but how do I get the error code in the crashlogs? I cannot seem to set an custom exception code for example.
-
Re: Intermittent -34018 errors from users in the field
eskimo Oct 12, 2016 3:15 AM (in response to tijmen)how do I get the error code in the crashlogs?
There is no supported way to put custom app state into a crash log. However, I don’t see how that matters here. This error is reported to you as an
OSStatus
; it’s your choice whether you crash when you get the error and, if you do, you can log the error somewhere that you can report it via your own logging the next time you launch.Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardwarelet myEmail = "eskimo" + "1" + "@apple.com"
-
-
-
-
Re: Intermittent -34018 errors from users in the field
luca34 Oct 26, 2016 2:18 AM (in response to eskimo)Hi,
I'm developing an application in Swft 2.3 that uses this library to access the keychain (version 3.0.16). We use a keychain for a group that includes the iOS app, a keyboard extension and an iMessage app
We are experiencing some problems on testing devices where a really old access token is persisted.
So this is the flow:
The user log in successfully -> The user log out -> An old access token (not the latest one) is in the keychain.
What I found out (just through an experimental way, please correct me if I'm wrong) is that the Security framework provides a kind of in-memory cache that has the priority on the stored keychain and where the operation is done even if the stored keychain hasn't been modified. That's why the user can login successfully and can use their own brand new access token.
This problem, by the way, it's occurring only on the access token field, not for the other values stored in the keychain, which they are cleaned as well after the user log out.
So I started to investigate this problem that seems to appers without any logic. It happens on an iPhone 6 Plus iOS 8.4 and on an iPhone 6 iOS 10.0.1 (both connected at least once on Xcode and not rebooted).
While debugging this error on these devices I found out that trying to set a new value or delete the value for the key in keychain results in a -34018 OSStatus, while, in the same moment, setting or deleting any other value works perfectly
Unfortunately I can't give you any other info since I'm still stucked in this problem and we are, sadly saying, moving to a shared user default with encrypted values there.
-
Re: Intermittent -34018 errors from users in the field
eskimo Oct 26, 2016 3:24 AM (in response to luca34)This doesn’t sound like an exact match for the intermittent problem that’s the subject of this thread, but it is an interesting failure nevertheless.
What I found out (just through an experimental way, please correct me if I'm wrong) is that the Security framework provides a kind of in-memory cache that has the priority on the stored keychain and where the operation is done even if the stored keychain hasn't been modified.
To be clear, the SecItem APIs always do an IPC to the security daemon, which always results in a database query against the true keychain database. So there’s no caching there.
There is, however, caching at other levels. The caches that most commonly trip folks up are:
the TLS session cache, described in QA1727
HTTP 1.1 (and now 2) persistent connections
Foundation network per-session (that is, non-persistent) credential caching
One or more of these could be in play here; it’s hard to say without knowing more about how your credentials are tied to your networking.
It happens on an iPhone 6 Plus iOS 8.4 and on an iPhone 6 iOS 10.0.1 (both connected at least once on Xcode and not rebooted).
To my mind the iOS 8.4 case is uninteresting; during the iOS 9 cycle we definitely fixed bugs that cause the -34018 error when using Xcode.
OTOH, the iOS 10 case is interesting. If you can distill down a reasonable test project that shows this, we would definitely appreciate a bug report for that (if you do create a bug, please post your bug number, just for the record).
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardwarelet myEmail = "eskimo" + "1" + "@apple.com"
-
Re: Intermittent -34018 errors from users in the field
luca34 Oct 26, 2016 5:10 AM (in response to eskimo)That's quite strange because when I delete the key or set a new value for that key, it changes its value (or it deletes it value) until I reopen the app. At that time, in the first line of didFinishLaunchingWithOptions in the AppDelegate I print the value for that key and it's again the old value.
We are not using anything complex: we store the api token received from the login in the keychain and we use this api token for each request. The api token it's a string (see JSON Web Token)
I'll try to investigate more the problem on iOS 10.
-
-
Re: Intermittent -34018 errors from users in the field
schang1967 Dec 20, 2016 3:05 PM (in response to eskimo)My app got a -34018 OSStatus calling SecItemCopyMatching when resuming from facebook login process.
I was using Xcode 7.3 to run a debug build on IOS 8.3 Iphone 7, 1, not 100% reproducible but I have seen it happened a few times and our QA have reported a few occurrences before.
Key chain access calls working fine after the app was launched, read and write returns successfully.
Then Facebook login is trigger and the app was pushed to background, after the Facebook login is done and returned to the app, the keychain read failed with -34018 and keep failing all the calls until the app is terminated.
I assume the bug was triggered when
- Resuming the app
- System resources may be low(?)
-
Re: Intermittent -34018 errors from users in the field
eskimo Dec 21, 2016 3:17 AM (in response to schang1967)I was using Xcode 7.3 to run a debug build on iOS 8.3 …
As I mentioned to luca34, the iOS 8 case is uninteresting because we definitely fixed bugs related to this during the iOS 9 cycle.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardwarelet myEmail = "eskimo" + "1" + "@apple.com"
-
-
Re: Intermittent -34018 errors from users in the field
eldanb Dec 12, 2017 11:05 PM (in response to eskimo)We're seeing an issue where calls to SecKeyCreateRandomKey for generating a key into the SE hang. Below is how we call it (on an iOS 10 device; the kSecAttrApplicationTag attribute points to some NSData object containing a tag derived from a string.)
This happened to us in the lab once. This is accompanied by log messages about access permissions from keychain -- however note that the call hangs. When we saw this in the lab, we were able to make this call right after application launch, in the application delegate's application:didFinishLaunchingWithOptions: call -- hangs again. Seems like once a device is in that state, it's persistent. The only way we were able to recover was to reboot the device.
We now get reports on this from customers in the field.
Any pointers will be appreciated.
---------------
CFErrorRef error = NULL;
SecAccessControlRef access = NULL;
access = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
kSecAccessControlPrivateKeyUsage,
&error); // Ignore error
NSDictionary* attributes =
@{ (id)kSecAttrKeyType: kSecAttrKeyTypeECSECPrimeRandom,
(id)kSecAttrKeySizeInBits: @256,
(id)kSecAttrTokenID: (id)kSecAttrTokenIDSecureEnclave,
(id)kSecAttrAccessControl: (__bridge id)access,
(id)kSecPrivateKeyAttrs:
@{ (id)kSecAttrIsPermanent: @YES,
(id)kSecAttrApplicationTag: ....
}
};
SecKeyCreateRandomKey((__bridge CFDictionaryRef)attributes,
&error);
-
Re: Intermittent -34018 errors from users in the field
eskimo Dec 18, 2017 2:09 PM (in response to eldanb)The problem, as you’ve described it, is unlikely to be related to your code. My recommendation here is that you file a bug, including a sysdiagnose log taken shortly after you reproduced the problem.
Note For more info on sysdiagnose logs, see our Bug Reporting > Profiles and Logs page.
Please post your bug number, just for the record.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardwarelet myEmail = "eskimo" + "1" + "@apple.com"
-
Re: Intermittent -34018 errors from users in the field
eldanb Dec 19, 2017 2:06 AM (in response to eskimo)Thank you for this response.
We have previously filed a report on this -- nr. 35622508 and we were informed that it is a duplicate of 33714117. Unfortunately that is the only information we have -- no insight on why this is happening or what's a suitable workaround.
Are you able to shed more light on this?
-
-