SecTransformExecute issue when keychain access is denied by user

It's probably a known issue (at least someone on stackoverflow has faced it: http://stackoverflow.com/questions/7966829/seckeyrawsign-osx-with-ec-cert) but it's apparently not covered in the forums (*).


Problem:


When SecTransformExecute is called and the user denies access to the keychain, the returned data is not NULL. The error is NULL.


This is not at all what the documentation states.


Question:


How are we supposed to know that we're in this case from the returned values of SecTransformExecute? Are we supposed to assume that chacking whether we received a 32KB zeroed data ref is the sign the access was denied?



* Tried looking for "SecTransform deny keychain": no results and it was suggested I may have meant "Spectra, deny, sketching". Sigh.

Replies

This is not at all what the documentation states.

Indeed.

Have you tried this with the new unified SecKey APIs in 10.12? Does it have the same problem?

Are we supposed to assume that chacking whether we received a 32KB zeroed data ref is the sign the access was denied?

32KB? If you’re signing stuff, where does 32KB come into this picture?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

> Have you tried this with the new unified SecKey APIs in 10.12? Does it have the same problem?


I've checked the same code on OS X 10.8.5, OS X 10.11 and macOS Sierra GM and it works correctly (NULL returned and CFErrorRef set). The problem seems to be limited to Mac OS X 10.7.


I haven't tried the new unified SecKey API as it's 10.2 or later only.


> 32KB? If you’re signing stuff, where does 32KB come into this picture?

No idea. The input data is the Info.plist of TextEdit.app for testing purpose.

The output is a 32KB data with zeroed data.


---------


SecTransformRef tTransformRef=SecSignTransformCreate(tPrivateKeyRef, NULL);


NSData * tInputData=[NSData dataWithContentsOfFile:@"/Applications/TextEdit.app/Contents/Info.plist"];


SecTransformSetAttribute(tTransformRef,kSecTransformInputAttributeName, (__bridge CFDataRef) tInputData,NULL);


CFErrorRef tErrorRef=NULL;


CFTypeRef tTypeRef=SecTransformExecute(tTransformRef, &tErrorRef);


NSData * tOutputData=(__bridge_transfer NSData *)tTypeRef;


NSLog(@"%d %@",(int)[tOutputData length],tOutputData);

The problem seems to be limited to Mac OS X 10.7.

Ah, I missed that point in your original post.

The best option here is to drop 10.7 support. If Minecraft can do it, you can do it as well (-:

If you won’t do that then checking for this oddball output seems like a reasonable workaround as long as you conditionalise it for 10.7 only. 10.7 is no longer getting software updates (which, btw, is a very good reason for you to drop your support for it), so you don’t have to worry about your workaround breaking.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"