It does, and the exception reason tripped me up at first: Exception Type: EXC_BAD_ACCESS (SIGKILL) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 VM Region Info: 0 is not in any region. Bytes before following region: 4339253248 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 102a3c000-102a40000 [ 16K] r-x/r-x SM=COW /var/containers/Bundle/Application/5BD67EC6-39CC-428C-944B-C2E2FCA311B4/<private>.app/<private> Termination Reason: CODESIGNING 2 Invalid Page Turns put it was likely a problem with an async closure passed to a Combine subject as indicated by the first stack frames: 0 ??? 0x0000000000000000 0x0 + 0 1 <private> 0x0000000102edacc8 type metadata accessor for (nonisolated(nonsending) (), ()) + 44 (/<compiler-generated>:0) 2 <private> 0x0000000102edac64 type metadata accessor for PassthroughSubject<(nonisolated(nonsending) (), ()), Never> + 44 (/<compiler-generated>:0)

So, the code under test takes a trust object (SecTrust) and returns an allow / deny decision based on the public keys in the certificates in the chain? Exactly If so, you could solve this problem by having you test hardness create the trust object using the basic X.509 policy (SecPolicyCreateBasicX509()) rather than TLS policy (SecPolicyCreateSSL(::)). We are in fact using SecPolicyCreateSSL(_:_:). I'll try SecPolicyCreateBasicX509() and report back. ps You’re probably aware of this, but ATS supports public key pinning via the NSPinnedDomains property. If that works for you, it’s a lot easier than doing this in code. I know (and I've lobbied for it), but we are required to support HPKP.

We have a custom implementation of HTTP Public Key Pinning on top of App Transport Security. The code in question tests this implementation (i.e. that given a valid trust object performing pin validation either lets our custom trust evaluation fail or succeed).

Thanks Quinn; I'll file this under "think first, ask later"

FB15438273

Sorry Quinn, I'll try to be more specific: We want the key to be usable with either biometry or device passcode - hence .userPresence - but we want to be able to decide whether to allow biometry in some cases or not. With .userPresence this does not seem to be possible out of the box since this always seems to prefer biometry if available. We tried passing a LAContext which has been used to access a (different) keychain item protected with .devicePasscode, but to no avail.

Thanks Quinn, the loctable was basically what I was looking for.

Hi Argun, thank you; indeed the error occurred while trying to read from a characteristic. Here is a snippet of the log: I just assumed that if 6 was CBATTErrorRequestNotSupported then 65535 would be kBluetoothSDPErrorCodeReservedEnd. However I was able to resolve the issue. I reviewed all the changes that happened since I had it working and as it turns out the instances' type I store details about the connection in got changed from a class to a struct. This change in semantics make it very likely that the connection got dropped while the read was in process. After I changed the type back to a class everything worked as it did before.

You mean via the NSFileProviderService? I was not aware that this uses XPC under the hood.

Thanks Quinn, the latest beta 4 seems to have resolved this issue for the time being. I will keep an eye on the upcoming betas nevertheless and report back in case it happens again.

This seems to be the same problem addressed here, am I right?

I did just that: Calling SecTrustEvaluateAsyncWithError (on a background queue) myself before calling SecTrustCopyCertificateChain (on the main queue). The latter, however, lead to Xcode printing "This method should not be called on the main thread as it may lead to UI unresponsiveness." which apparently resulted from SecTrustCopyCertificateChain calling SecTrustEvaluateIfNecessary even though I had already done that. So I ended up calling SecTrustCopyCertificateChain on the background queue as well.

Sorry, but I have another question: To do my own checks I need to call e.g. SecTrustCopyCertificateChain(_:) on the trust object. Is that API guaranteed to return the correct certificate chain if the trust object has not been evaluated?

Thank you. It was not obvious (to me) that continuing with completionHandler(.useCredential, URLCredential(trust: serverTrust)) does not benefit from the OS performing trust evaluation.

Sure: I am required to implement HPKP (aka. Public Key Pinning Extension for HTTP) as defined in RFC 7469 which is not supported out of the box (cf. FB5986841). Additionally I have to secure the first-ever connection as well by supporting preloaded pins, but I cannot use Identity Pinning (cf. thread and FB12333846). So I have to build everything from scratch.