Hi, I don't know if this is the right list to post this to, but I'm
encountering an annoying problem and I'm not sure where to turn to for
help, so I apologize if this is the wrong place to ask this question.
I'm writing a program that stores some secure preferences in the
keychain access application
Technically, nothing is stored in the keychain access application
itself. Management of the data in a keychain is handled by the OS.
Other applications would be able to store and retrieve keychain items
even if you removed the Keychain Access application completely.
This works, sometimes, and it used to work all the time. Then
suddenly, it stopped working for some reason that I've yet to pin
down.
One problem here is that [key length] returns the length of the string
in characters, not bytes. However, the SecKeychainFindGenericPassword
function requires the length to be passed in bytes, not characters.
(Characters other than plain ASCII may use more than 1 byte when
represented in UTF-8.) Since this function doesn't do partial string
matches, if you ask for the wrong length, you'll fail to match the
item. Use strlen() to get the length in bytes of a UTF-8 encoded
string.
Now what happens is this:
On the first run of the code it works, but when I recompile the
application and run it again, keychain access asks whether to allow
the new binary access (which makes sense), I click the "Yes" button,
and the program does not "crash" but just stops executing. I attach
the debugger and I get the following stack trace:
#0 0x947544a6 in mach_msg_trap ()
#1 0x9475bc9c in mach_msg ()
#2 0x935ef8b6 in ucsp_client_decrypt ()
#3 0x935f92ce in Security::SecurityServer::ClientSession::decrypt ()
#4 0x935848b4 in SSCryptContext::outputSize ()
#5 0x935cca92 in Security::CSPFullPluginSession::CSPContext::final ()
#6 0x935d6339 in cssm_DecryptDataFinal ()
#7 0x93557900 in CSSM_DecryptDataFinal ()
#8 0x935dc5fb in Security::CssmClient::Decrypt::final ()
#9 0x935e37f8 in Security::CssmClient::SSGroupImpl::decodeDataBlob ()
#10 0x935e464d in Security::CssmClient::SSDbUniqueRecordImpl::get ()
#11 0x9350ac03 in Security::KeychainCore::ItemImpl::getContent ()
#12 0x9350c9b4 in Security::KeychainCore::ItemImpl::getData ()
#13 0x93529f66 in SecKeychainFindGenericPassword ()
When you see a program hung in mach_msg_trap(), it's waiting for a Mach
IPC reply from another program. In this case, it's waiting for
securityd to return the decrypted data of the item that was found. This
suggests that securityd itself is hung or no longer running, which is
definitely a problem.
Furthermore, from that point on keychain access is completely broken,
and any attempts at running any program results in a SIGABRT killing
it. I'm forced to reboot the computer for things to behave properly
again.
As Perry noted in an earlier message, there is a known issue where
securityd can get into a bad state when its code equivalence database
(in /var/db/CodeEquivalenceDatabase) is corrupt. Try moving that file
aside and rebooting.
-ken
I should mention that this problem happens with both the default
keychain, and a custom keychain that I created in an attempt to fix
the problem. Also, the keychain is accessed by two different
programs, the main one and another helper application.
Any help solving this problem would be GREATLY appreciated!
Thanks,
- Greg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Apple-cdsa mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/apple-cdsa/email@hidden
