OSStatus错误代码-34018
我正在使用SecItemCopyMatching访问iOS钥匙串。 大概有百分之一我从后台重新启动应用程序后-34018得到-34018结果代码。 该文件指出：
为钥匙串服务分配的错误空间是不连续的：-25240到-25279和-25290到-25329。 钥匙串项目服务也可以返回noErr（0）或paramErr（-50）或CSSM结果代码
所以，似乎-34018是一个“CSSM结果代码”。 我已经按照build议的链接，但无法find结果代码。
它是什么-34018结果代码？ 我怎样才能获得更可靠的钥匙串访问？
- (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; } }
我一直在研究同样的错误。
其要点在于，苹果公司所使用的安全服务是为了与钥匙链进行沟通，在极less数情况下，当用户的设备内存不足时，崩溃并带走应用程序与钥匙链对话的能力，导致可怕的 – 34018。
这只有在像Xcode那样运行时才会发生。
这是苹果公司员工之一在苹果开发者论坛上发布的最新数据：
更新：我们终于能够在iOS 8.3上重现-34018错误。 这是确定根本原因然后提出修复的第一步。
像往常一样，我们不能承诺发布的时间框架，但这已经影响了许多开发人员，我们真的希望得到解决。
早些时候，我build议在应用程序中添加一个小延迟：didFinishLaunchingWithOptions和applicationDidBecomeActive：在访问钥匙串之前作为一种解决方法。 但是，这实际上并没有帮助。 这意味着除了重新启动应用以外，目前还没有已知的解决方法。
这个问题似乎与内存压力有关，所以在处理内存警告时可能会更加积极，可能会缓解这个问题。
来自另一位苹果员工：
- 钥匙扣工程很清楚这个问题的重要性。
- 苹果的主要问题是在这里再现了这个失败。
- 我们现在能够做到这一点（很大程度上要归功于你们在提交和跟踪错误报告方面所做的工作）。
来自2016年3月22日的另一位苹果员工：
好的，这是最新的。 这是一个复杂的问题，有多种可能的原因：问题的一些实例是由不正确的应用程序签名造成的。 您可以很容易地区分这种情况，因为问题是100％可重现的。 这个问题的一些实例是由iOS如何支持应用程序开发（r。23,991,853）中的一个错误引起的。 由于OS（23,770,418）的另一个缺陷掩盖了它的效果，这意味着当设备处于内存压力下时，问题才会出现。 我们相信这些问题已经在iOS 9.3中解决了。 我们怀疑这个问题可能还有更多的原因。 因此，如果您在运行iOS 9.3或更高版本的用户设备（未经Xcode讨论的设备）上看到此问题，请提交有关此问题的错误报告。 尝试将设备系统日志包含在你的bug报告中（我认识到在处理客户设备时可能会非常棘手;一种select是要求客户安装Apple Configurator，以便他们查看系统日志）。 如果你提交了一个bug，请发布你的bug号码，以备logging。 我谨代表苹果，感谢大家为帮助追踪这个相当可怕的问题所做的努力。 分享和享受
不幸的是，没有已知的解决方法，这个问题在9.3.2 Beta 1（13F51a）中仍然没有解决。
经过一番研究，我发现这个： http : //opensource.apple.com/source/Security/Security-55471/sec/Security/SecBasePriv.h
所以-34018是errSecMissingEntitlement和评论说
Internal error when a required entitlement isn't present.
运行unit testing时是否遇到这个错误？ 如果是这样，这可能有所帮助： https : //stackoverflow.com/a/22305193/171933
github上的这个问题说，它似乎只是从Xcodedebugging时发生： https ： //github.com/soffes/sskeychain/issues/97 （也见https://stackoverflow.com/a/28256591/171933 ）
希望这会有所帮助！
这段代码适用于我：
static const UInt8 kKeychainItemIdentifier[] = "com.apple.dts.KeychainUI\0"; - (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; } }
与OP代码的主要区别在于为查询添加了通用属性。 钥匙串项目标识符是苹果的默认值。 这背后的原因来区分可能不同的钥匙链项目彼此。 这是使钥匙链项目访问更加可靠的一种方式。 基本上，换句话说，这可以确保你访问苹果的默认钥匙串。
在尝试了很多堆栈溢出修复之后，事情仍然没有为我工作。
什么工作是切换Xcode中的钥匙串共享function。 build立和运行，它马上工作。
