SecKeychainItemCopyContent for ppc on Leopard

  • I have noticed a difference in the behavior of a unit test
    (SenTestCase) when it is run in Release mode against the i386 arch and
    the ppc arch in Xcode 3.0 on Leopard.

    The following code correctly populates the SecKeychainAttributeList
    "list" for i386. This exact same code, when run from the exact same
    unit test fails with "errSecAuthFailed" (code -25293) for ppc:

        SecKeychainItemRef item;
        NSString *serviceName = @"MyService";
        OSStatus status = SecKeychainFindGenericPassword(NULL,
                                                          [serviceName
    length],
                                                          [serviceName
    UTF8String],
                                                          0,
                                                          NULL,
                                                          NULL,
                                                          NULL,
                                                          &item);
        if (status != noErr) {
            return nil; // status is always 0. always works up to this
    point.
        }

        // from Advanced Mac OS X Programming, ch. 16
        UInt32 length;
        char *password;
        SecKeychainAttribute attributes[8];
        SecKeychainAttributeList list;

        attributes[0].tag = kSecAccountItemAttr;
        attributes[1].tag = kSecDescriptionItemAttr;
        attributes[2].tag = kSecLabelItemAttr;
        attributes[3].tag = kSecModDateItemAttr;

        list.count = 4;
        list.attr = attributes;

        // status is always 0 on i386, -25293 on ppc
        status = SecKeychainItemCopyContent(item, NULL, &list, &length,
    (void **)&password);

    Does anyone have ideas about the source of this difference?

    -Jon Crosby
  • On Nov 1, 2007, at 3:13 PM, Jon Crosby wrote:

    > OSStatus status = SecKeychainFindGenericPassword(NULL,
    > [serviceName
    > length],
    > [serviceName
    > UTF8String],

    I'm not quite sure of the problem, but I think you ought to use
    strlen() there instead of -length, or else your UTF-8 string will be
    cut short if it has non-ASCII characters in it.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • >> I'm not quite sure of the problem, but I think you ought to use
    >> strlen() there instead of -length, or else your UTF-8 string will
    >> be cut short if it has non-ASCII characters in it.
    >

    Thanks for the tip. I replaced [serviceName length] with
    strlen([serviceName UTF8String]). The code in question, however, is
    still behaving differently on i386 and ppc.

    -Jon
  • On Nov 1, 2007, at 3:34 PM, Jon Crosby wrote:

    >>> I'm not quite sure of the problem, but I think you ought to use
    >>> strlen() there instead of -length, or else your UTF-8 string will
    >>> be cut short if it has non-ASCII characters in it.
    >>
    >
    > Thanks for the tip. I replaced [serviceName length] with
    > strlen([serviceName UTF8String]). The code in question, however, is
    > still behaving differently on i386 and ppc.
    >

    If anyone is interested in helping identify the root cause of this
    line of code:

    status = SecKeychainItemCopyContent(item, NULL, &list, &length, (void
    **)&password);

    returning two different status flags for i386 vs. ppc when run from
    the same unit test, the entire project's source can be found here:

    http://oauth.googlecode.com/svn/code/obj-c/

    The line mentioned above is line 96 of OAToken.m and the unit test
    that fails (only for the ppc version of a Release build created in
    Leopard in Xcode 3.0 on a MBP) is "testInitWithKeychainUsingAppName"
    in OATokenTest.m, starting on line 57.

    This is an MIT-licensed project so all of the code is in the public
    domain, free to use in your own projects.

    -Jon
  • Two thoughts on this - first up, try the apple-cdsa mailing list if
    all else fails; the Security guys hang out there and very often
    provide exemplary assistance.

    Second, I have similar code that works perfectly well, and is very
    well tested... the only difference I can see, given the small snippet
    you posted to the list, is that I clear the data & length fields of
    each attribute before passing them into the call... it makes no sense
    given the error code you're seeing, but hey, give it a shot and see
    if that's it.

    Failing that, 99% of the Security framework's source is available
    from Apple's website, so you can peruse through it and figure out
    where (and thus why) it's failing.

    Wade
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today