On May 17, 2006, at 1:35 AM, Markus Hanauska wrote:
I think this issue might be a bug, so I filed a bug report already
4550961. Maybe this was a bit too early, so let me ask some folks
here on the list, maybe someone knows the issue.
Hi Markus,
Yes, this is a known bug in the SecKeychainItem{Copy,Modify}
AttributesAndData APIs, previously reported as 3425797.
SecKeychainItemCopyAttributesAndData is usually more flexible than
SecKeychainItemCopyContent in terms of which attributes you can
specify, which is why it's listed as the preferred API.
Unfortunately, the "AttributesAndData" versions of these APIs have a
bug which currently makes them unable to deal with one particular
attribute constant, kSecLabelItemAttr, and you'll get an "invalid
attribute" error result when specifying it.
The Sec* APIs normally translate four-character attribute constants
to the underlying index required by the database schema.
kSecLabelItemAttr maps to the "print name" attribute at index 1 in
the database schema for native CDSA objects (i.e. keys and
certificates), and index 7 for others (e.g. password items).
SecKeychainItem{Copy,Modify}Content goes through a different code
path than SecKeychainItem{Copy | Modify}AttributesAndData does, and
the latter fails to correctly translate the attribute tag.
So there are two possible workarounds for this problem, if you
explicitly need to use the label attribute:
1) pass a value of either 1 or 7 directly for the attribute tag,
depending on the type of item (see above), instead of using
kSecLabelItemAttr
2) use SecKeychainItemCopyContent instead of
SecKeychainItemCopyAttributesAndData
-ken
_______________________________________________
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
