Responding to an authentication challenge with an identity-based credential fails when more than one copy of the identity’s private key exists in the keychain.
<rdar://problem/17782623>
Created attachment 235368 [details] Specify an access group when creating a persistent reference to a key
Comment on attachment 235368 [details] Specify an access group when creating a persistent reference to a key View in context: https://bugs.webkit.org/attachment.cgi?id=235368&action=review > Source/WebKit2/Shared/cf/ArgumentCodersCF.cpp:637 > + RetainPtr<NSDictionary> query = @{ This doesn't need to be a RetainPtr.
Comment on attachment 235368 [details] Specify an access group when creating a persistent reference to a key View in context: https://bugs.webkit.org/attachment.cgi?id=235368&action=review > Source/WebKit2/Shared/cf/ArgumentCodersCF.cpp:632 > +static CFDataRef copyPersistentRef(SecKeyRef key) This doesn't seem to be in a PLATFORM(IOS) ifdef, and it should. > Source/WebKit2/Shared/cf/ArgumentCodersCF.cpp:637 > + RetainPtr<NSDictionary> query = @{ I don't see how this RetainPtr can be appropriate here. > Source/WebKit2/Shared/cf/ArgumentCodersCF.cpp:645 > + OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query.get(), &persistentRef); Do we need __bridge in WebKit code? > Source/WebKit2/Shared/cf/ArgumentCodersCF.cpp:652 > + if (CFGetTypeID(persistentRef) != CFDataGetTypeID()) { > + CFRelease(persistentRef); > + return nullptr; > + } Can this happen? Documentation says that kSecReturnPersistentRef always provides a CFDataRef.
Fixed in <http://trac.webkit.org/r171485>.