Thank you so much for the reply! As -50 is a vague error code, I'm lost what should I look into. I know that I got the error after I added the kSecUseKeychain attribute. And looking at the documentation, I failed to find more information related to the keychain attribute Item Attribute Keys and Values. Would you have any information related? Would you mind also providing more information about execution context? I'm not sure what is it about. For the password example, I tried with a generic password, it pop out the same error: errSecInteractionNotAllowed. I guess the issue was with the execution context?

Hi Quinn, thank you so much for the instruction. I was able to run the generic password sample. I created a simple C command line program, compiled and run with cmake/clang from terminal. (well, vscode terminal to be specific.) The program was able to run the generic password test after I switch to a machine I had full access permission. I assume the generic password was failed because of permission. However, adding the ECC key still failed with OSStatus -50 in the C program. I also tried with Objective-C in XCode, and got the same result. Also, I will get error "OSStatus -34018 : A required entitlement isn't present.", if I don't specify the keychain to add to. I'm not sure if that is one of the cause. I will continue to try out different attributes and keys to see if there is any inspiration. I would really appreciate if you have further suggestion about what should I do next. Thank you.

Hi eskimo, You are right. I'm trying to build a client daemon which setup network connection with SSL. I'm trying to create an identity with the ECC key and the certificate (in RSA PEM format. I was able to setup the certificate with SecItemImport as it supports RSA PEM format) And setup the identity as following: // Add ECC Key to keychain (failed here) CFMutableDictionaryRef secItemParams = CFDictionaryCreateMutable(default_alloc, 0, NULL, NULL); CFDictionarySetValue(secItemParams, kSecClass, kSecClassKey); CFDictionarySetValue(secItemParams, kSecValueRef, privateKey); CFDictionarySetValue(secItemParams, kSecUseKeychain, import_keychain); OSStatus key_status = SecItemAdd(secItemParams, NULL); // setup identity SecIdentityCreateWithCertificate(keychain, certificate, &output_identity); identity = CFArrayCreate(default_alloc, (const void **)certs, 1L, &kCFTypeArrayCallBacks); // Set certificate using the identity SSLSetCertificate(ctx, identity);

I'm a little confused about the keychain implementation here. As mentioned in On Mac Keychains: The Keychain and SecKeychain APIs only talk to the file-based keychain. The SecItem API talks to either implementation. Specifically, it talks to the data protection keychain if you supply either the kSecUseDataProtectionKeychain or the kSecAttrSynchronizable attribute. If not, it talks to the file-based keychain. The keychain should default to file-based, since I'm working with MacOS and I didn't set either kSecAttrSynchronizable or kSecUseDataProtectionKeychain. I didn't get why the keychain is considered as data protection here. However, inspired by the article, I manually set the above two attributes to false. And eventually I got the error: OSStatus -25304 : The specified item is no longer valid. It may have been deleted from the keychain. It seems like I did something wrong when I create the SecKeyRef, so it failed to find it. I applied SecKeyCreateWithData to create the SecKey as described here Storing CryptoKit Keys in the Keychain. Though the example is for CryptoKit, I assume the API should also work for pure data... or am I wrong here? Here is the implementation, and key_error returns NULL. I assume the key creation succeed. CFMutableDictionaryRef parameters = CFDictionaryCreateMutable(my_alloc, 0, NULL, NULL); CFDictionarySetValue(parameters, kSecAttrKeyType, kSecAttrKeyTypeECSECPrimeRandom); CFDictionarySetValue(parameters, kSecAttrKeyClass, kSecAttrKeyClassPrivate); CFDictionarySetValue(parameters, kSecUseDataProtectionKeychain, kCFBooleanFalse); CFDictionarySetValue(parameters, kSecAttrSynchronizable, kCFBooleanFalse); CFDictionarySetValue(parameters, kSecUseKeychain, keychain); // Not sure if the keychain attribute works here ...? // key_data is the binary data read from ANSI file, which is a ECC key in X963 format. SecKeyRef privKey = SecKeyCreateWithData(key_data, parameters, &key_error);

Sorry, I was mean to say "client" only. I'm working on a library to help setup network connection with TLS, and testing with a TLS client build upon it.

Though it really depends on the library user, I would say there is a high possibility that the library is used for a daemon context. Regardless of that, as the previous implementation for RSA keys is using file-based keychain, I would like to keep it consistent and stick with the file-based keychain. Could I import ECC key as file-based keychain? Would there be any attribute I need to take care for that?

I really appreciate your help here. Here is the hex dump of a sample EC key in X963 format I'm using for test. Would this work? unsigned char hard_code_key[] = { 0x04, 0x0F, 0x12, 0x9D, 0x04, 0x61, 0x7F, 0x4A, 0xB3, 0xC4, 0xE9, 0x99, 0xCF, 0xFF, 0x37, 0x04, 0x57, 0xA5, 0x7D, 0xFA, 0xC3, 0xE4, 0x2A, 0x25, 0xA9, 0xE4, 0x8D, 0x77, 0xF6, 0x54, 0x41, 0x8E, 0x40, 0x4A, 0x2C, 0x55, 0xF2, 0xAE, 0xDC, 0x37, 0xB2, 0x7F, 0x0B, 0x6A, 0x13, 0x00, 0xED, 0xF2, 0x1D, 0x19, 0xE4, 0x3E, 0xDA, 0x28, 0x41, 0x9C, 0xB2, 0x14, 0x18, 0xD4, 0x61, 0x10, 0xD1, 0x79, 0x61, 0x7B, 0x7B, 0xE9, 0x64, 0x38, 0x2C, 0x7E, 0x20, 0x88, 0x28, 0x09, 0x42, 0x9F, 0xCD, 0x51, 0x39, 0x91, 0x0A, 0x4F, 0xAF, 0x5B, 0xC3, 0xAD, 0xA9, 0x79, 0xE6, 0x87, 0xA9, 0x76, 0xEA, 0x13, 0xAC};

Thank you so much for your help, otherwise I could not locate the issue. I really appreciated it! I will see if I can figure it out.

Hi Quinn, That's a great news and thank you so much!! I will try it out. I followed the post here to contribute the key binary. (https://developer.apple.com/forums/thread/72445) However, I could did something wrong with the raw keys. I will work on it. Again, thank you so much.

It was still failed. In fact the original issue was exactly SecKeychainCopyDefault failed when I run xcodebuild test. However, if I ran default-keychain directly in the terminal, it can correctly return the default keychain. Therefore, I'm thinking if that is an issue with xcode setup on the CI host. Would I need to do a code-sign for xcode build? Reading Resolving errSecInternalComponent errors during code signing, I also tried to run unlock keychain before run my test. As I'm running on Github CI, I dont have the password for the default keychain there. I tested by creating my own keychain like, but unfortunately it did not help. security create-keychain -p pwd build.keychain security default-keychain -s build.keychain security unlock-keychain -p pwd build.keychain

Update: Resolved. It turned out to be issue for my environment variable. The env var "HOME" was set to a different value in the terminal.

Update: Resolved. It turned out to be an issue for environment variable "HOME". "HOME" was set to a different value in terminal and failed the keychain operation.

Hi Quinn, Thank you so much for the response. I have some follow-up questions about network suspension and resumption (or socket reclaim?). From Networking and Multitasking All iOS networking APIs are ultimately implemented in terms of the BSD Sockets API From this statement, I got the impression that the Apple Network Framework uses BSD Sockets for its underlying implementation. However, in your reply from iOS/tvOS seem to reuse closed sockets, you mentioned this is all Network framework and thus there are no sockets in play I'm a little confused about what does the "no sockets" means here. Here’s my understanding of the reclaim mechanism for Listening Sockets—please correct me if I'm wrong: If the resource is reclaimed, to resume the app properly, the app needs to reconfigure the socket, perform the handshakes, and re-established the connection. If the resource is not reclaimed yet, the socket is put in idle while the app is in the background. When the socket is resumed, the app can continue processing the requests. (Of course, as the socket was idled, the requests might fail or time out, and the app would need to handle these cases.) One peculiar thing I’ve noticed is that the "reclaim" behavior seems inconsistent. While testing with the Network framework using the following steps from Networking and Multitasking putting your app in the background ensuring that the app is suspended locking the screen Sometimes when the socket is reclaimed, the Network framework sends out a TCP FIN packet and closes the connection, and other times it does not. Does this mean the behavior is undefined for reclaim, or am I doing something wrong? Additionally, I observed the same results using my own BSD socket implementation and the Apple Network framework (the test app is based on the SWIFT-NIO library). It seems they behave similarly. As I planed to move to the Network Framework for TLS1.3 support, are there any features or behaviors that the Network Framework provides that I should be aware of? Thanks again for your help!

I was not able to edit the original post, therefore I will update in the replies. I did some investigation and it looks like the completion handler block would not be guaranteed to run respect to any dispatch queue related order. And here is my current solution to avoid any possible data racing issue: I always wrapped any user_data changes into the dispatch queue B. For example: For example static void send_message(){ dispatch_data_t data = dispatch_data_create(message, len(message), dispath_event_loop->dispatch_queue, DISPATCH_DATA_DESTRUCTOR_DEFAULT); nw_connection_send( nw_connection, data, NW_CONNECTION_DEFAULT_MESSAGE_CONTEXT, false, ^(nw_error_t error) { dispatch_async(dispatch_queue_B, ^(){ user_data.client_status = SENT; mem_release(user_data.message_to_sent);} }); }); } And so far it seems working. Feel free to correct me if I was wrong, and possibly share any better way to handle it.

Thank you so much for the detailed and patient explanation of my questions. It is really helpful and clarified a lot for me! [quote='805638022, DTS Engineer, /thread/764555?answerId=805638022#805638022'] “… and then call some higher-level function to process that data” then you’re more likely to hit issues. [/quote] That's definitely my concern. I was trying to avoid the complication of dead locks, and went with the serial dispatch queue to so that the shared data are processed one at a time. Of cause, if locks are better solution here, I'm open to it. I'm also looking into the target queue as you mentioned here, the target queue design sounds like similar to my current solution if I understand correctly. Please correct me if I was wrong. Instead of putting everything on dispatch queue B, we put user_data related block to the target queue so that they are always processed in order.