The bridging header works fine for compilation, and with previous version of xcode there were no problems running and debugging the app.
But after switching to 13.2.1, poing a variable leads first to error: expression failed to parse, unknown error, and then to an error hinting at not being able to find header files.
Example:
(lldb) po recipientType
error: expression failed to parse, unknown error
(lldb) po recipientType
warning: Swift error in scratch context: error: /Users/dirk/projects/pEp/src_iOS/pep4ios/pEpForiOS/pEpForiOS-Bridging-Header.h:14:9: error: 'AccountSettings.h' file not found
#import "AccountSettings.h"
^
error: failed to import bridging header '/Users/dirk/projects/pEp/src_iOS/pep4ios/pEpForiOS/pEpForiOS-Bridging-Header.h'
.
Shared Swift state for pEp has developed fatal errors and is being discarded.
REPL definitions and persistent names/types will be lost.
error: expression failed to parse, unknown error
I have experimented with using <> for the import, instead of "", and also setting the framework header path, but no luck so far.
Post
Replies
Boosts
Views
Activity
For being able to pick client certificates, I thought I can simply create my own UTI for certain extensions and feed that to UIDocumentPickerViewController(documentTypes:) to change the way it displays files.
This works for fantasy extensions and .cert, for example, but not .p12 or .pfx. Which may be because these are already used in other UTIs. But this list of UTIs - https://developer.apple.com/library/archive/documentation/Miscellaneous/Reference/UTIRef/Articles/System-DeclaredUniformTypeIdentifiers.html doesn't contain them.
Is there an existing UTI for certificates that I could use?
What are the options doing TCP and supporting self-signed server certificates? It's about IMAP/SMTP connections.
We are currently using NSStream. Is there a higher-level API that automatically supports certificates that have been imported and trusted by the user (as hinted at here - https://support.apple.com/en-us/HT204477)?
If not, is connecting with kCFStreamSSLValidatesCertificateChain disabled, and then querying kCFStreamPropertySSLPeerTrust, involving the user in self-made "trust UI" the way to go?
Sample error:
2021-01-21 14:03:13.673788+0100 pEp[77676:8086560] CFNetwork SSLHandshake failed (-9807)
2021-01-21 14:03:13.673968+0100 pEp[77676:8086560] TCP Conn 0x6000033b89a0 SSLHandshake failed (-9807)
TLDR; Is there a way (on iOS 11 upwards) to get the expiry date of a SecIdentity's certificate imported with SecPKCS12Import?In order to support client certificates for NSStream based TLS TCP connections in an iOS app we're importing the certificates with SecPKCS12Import, extracting the common name and related emails of the certificate for displaying information to the user, generating our own UUID to re-identify this identity later and store it in the keychain. The UUID is packed into the label, which does not help in directly looking the identity up later, but together with equality on SecIdentity helps to identitfy already imported certificates and link them to our own DB.Now a typical use case for a client certificate is to let it expire every now and then, send out new ones to the users and let them handle the update. Knowing the expiry date of identities (which really means the expiry dates of their related certificates) is needed in this case, otherwise I don't see any other data that could let the user easily differentiate between the old, no longer valid identity and the new one.