OSStatus error code
I am using SecItemCopyMatching to access the iOS keychain. About 1 in a hundred times I get a -34018 result code right after relaunching the app from the background. The documentation states:
The assigned error space for Keychain Services is discontinuous: –25240 through –25279 and –25290 through –25329. Keychain Item Services may also return noErr (0) or paramErr (–50), or CSSM result codes
So it seems that -34018 is a 'CSSM result code'. I have followed the suggested link but could not find result codes.
What it the -34018 result code? How can I get more reliable keychain access?
- (NSData *)getKeychainData:(NSString *)key
{
NSDictionary *query = @{
(__bridge id)kSecClass:(__bridge id)kSecClassGenericPassword,
(__bridge id)kSecAttrService:SEC_ATTR_SERVICE,
(__bridge id)kSecAttrAccount:key,
(__bridge id)kSecReturnData:@YES
};
CFDataRef result = nil;
OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, (CFTypeRef *)&result);
if(status == errSecItemNotFound) {
return nil;
}
if(status == noErr) {
return CFBridgingRelease(result);
} else {
[self logError:[NSString stringWithFormat:@"SecItemCopyMatching status %d", (int)status] :nil];
return nil;
}
}
I've been just researching the same error.
The gist of it is that the security service apple uses in order to communicate with the key chain, in rare cases, when the user's device is low on memory, crashes and taking away the app ability to talk to the keychain which results the dreadful -34018.
This is not happening only while running through Xcode like some may claim.
This is the most recent data regarding the issue taken from the Apple developer forums by one of the Apple staff:
UPDATE: We have finally been able to reproduce the -34018 error on iOS 8.3. This is the first step in identifying the root cause and then coming up with a fix.
As usual, we can't commit to a release timeframe, but this has affected many developers and we really want to get this resolved.
Earlier I suggested adding a small delay in application:didFinishLaunchingWithOptions and applicationDidBecomeActive: before accessing the keychain as a workaround. However, that doesn't actually appear to help. That means that there's no known workaround at this time other than relaunching the app.
The issue appears to be related to memory pressure, so perhaps being more aggressive in handling memory warnings may alleviate the problem.
From Another Apple staff member:
From Another Apple staff member on Mar 22, 2016 :
OK, here's the latest. This is a complex problem with multiple possible causes: Some instances of the problem are caused by incorrect app signing. You can easily distinguish this case because the problem is 100% reproducible. Some instances of the problem are caused by a bug in how iOS supports app development (r. 23,991,853). Debugging this was complicated by the fact that another bug in the OS (r. 23,770,418) masked its effect, meaning the problem only cropped up when the device was under memory pressure. We believe these problems were resolved in iOS 9.3. We suspect that there may be yet more causes of this problem. So, if you see this problem on a user device (one that hasn't been talked to by Xcode) that's running iOS 9.3 or later, please do file a bug report about it. Try to include the device system log in your bug report (I realise that can be tricky when dealing with customer devices; one option is to ask the customer to install Apple Configurator, which lets them view the system log). And if you do file a bug, please post your bug number, just for the record. On behalf of Apple I'd like to thank everyone for their efforts in helping to track down this rather horrid issue. Share and Enjoy
Unfortunately there are no known workarounds and the issue is still not fixed in 9.3.2 Beta 1 (13F51a)
After some research, I found this: http://opensource.apple.com/source/Security/Security-55471/sec/Security/SecBasePriv.h
So -34018 is errSecMissingEntitlement and the comment says
Internal error when a required entitlement isn't present.
Do you experience this error while running your unit tests? If so, this might help: https://stackoverflow.com/a/22305193/171933
This issue on github says that it only seems to happen while debugging from Xcode: https://github.com/soffes/sskeychain/issues/97 (also see https://stackoverflow.com/a/28256591/171933)
Hopefully some of this will help!
This code works for me:
static const UInt8 kKeychainItemIdentifier[] = "com.apple.dts.KeychainUI ";
- (NSData *)getKeychainData:(NSString *)key
{
NSData *keychainItemID = [NSData dataWithBytes:kKeychainItemIdentifier length:strlen((const char *)kKeychainItemIdentifier)];
NSDictionary *query = @{
(__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecAttrService: SEC_ATTR_SERVICE,
(__bridge id)kSecAttrAccount: key,
(__bridge id)kSecReturnData: (__bridge id)kCFBooleanTrue,
(__bridge id)kSecAttrGeneric: keychainItemID
};
CFDataRef result = NULL;
OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, (CFTypeRef *)&result);
if(status == errSecItemNotFound) {
return nil;
}
if(status == noErr) {
return CFBridgingRelease(result);
} else {
[self logError:[NSString stringWithFormat:@"SecItemCopyMatching status %d", (int)status] :nil];
return nil;
}
}
The main difference with OP's code is the addition of a Generic Attribute to the query. The Keychain Item Identifier is the default from apple. The reason behind this comes to differentiate possible different keychain items from each other. This is one way to make a more the keychain items access more reliable. Basically, in other words, this makes sure you access apple's default keychain.
链接地址: http://www.djcxy.com/p/83288.html上一篇: 钥匙串iOS 8 kSecAttrAccessible崩溃
下一篇: OSStatus错误代码