I have code where we're evaluating SSL certificates in sec_protocol_options_set_verify_block. We have the following code: let secTrust = sec_trust_copy_ref(trust).takeRetainedValue() isValidCertificate = SecTrustEvaluateWithError(secTrust, &error) I'm getting the error that the maximum temporal validity period has been exceeded: Error Domain=NSOSStatusErrorDomain Code=-67901 "“server.com” certificate is not standards compliant" UserInfo={NSLocalizedDescription=“server.com” certificate is not standards compliant, NSUnderlyingError=0x300ddd350 {Error Domain=NSOSStatusErrorDomain Code=-67901 "Certificate 0 “server.com” has errors: Certificate exceeds maximum temporal validity period;" UserInfo={NSLocalizedDescription=Certificate 0 “server.com” has errors: Certificate exceeds maximum temporal validity period;}}} When I inspect the certificate, it's valid for 394 days (4/16/2024 through 5/15/2025) and other than being a wildcard certificate, should be fully trusted. I can't find any information about this specific error. Is Apple requiring SSL certs to be less than 398 days now? Which brings me to the second part - we're OK using this to workaround it var trustFailureExceptions: CFData? = SecTrustCopyExceptions(secTrust) SecTrustSetExceptions(secTrust, trustFailureExceptions) But I haven't found anyway to be able to inspect trustFailureExceptions to ensure it only is this specific error. I'm concerned that otherwise this is going to open up validity exceptions for any certificate problem, which is definitely not what I want to do.

I'm seeing somewhat regular crash reports from my app which appear to be deep in the Swift libraries. They're happening in the same spot, so I'm apt to believe something is likely getting deallocated behind the scenes - but I don't really know how to guard against it. Here's the specific crash thread: 0 libsystem_kernel.dylib 0x00000001d51261dc __pthread_kill + 8 (:-1) 1 libsystem_pthread.dylib 0x000000020eaa8b40 pthread_kill + 268 (pthread.c:1721) 2 libsystem_c.dylib 0x000000018c5592d0 abort + 124 (abort.c:122) 3 libsystem_malloc.dylib 0x0000000194d14cfc malloc_vreport + 892 (malloc_printf.c:251) 4 libsystem_malloc.dylib 0x0000000194d14974 malloc_report + 64 (malloc_printf.c:290) 5 libsystem_malloc.dylib 0x0000000194d0e8b4 ___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED + 32 (malloc_common.c:227) 6 Foundation 0x0000000183229f40 __DataStorage.__deallocating_deinit + 104 (Data.swift:563) 7 libswiftCore.dylib 0x0000000182f556c8 _swift_release_dealloc + 56 (HeapObject.cpp:847) 8 libswiftCore.dylib 0x0000000182f5663c bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1>>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 152 (RefCount.h:1052) 9 TAKAware 0x000000010240c688 StreamParser.parseXml(dataStream:) + 1028 (StreamParser.swift:0) 10 TAKAware 0x000000010240cdb4 StreamParser.processXml(dataStream:forceArchive:) + 16 (StreamParser.swift:85) 11 TAKAware 0x000000010240cdb4 StreamParser.parseCoTStream(dataStream:forceArchive:) + 360 (StreamParser.swift:108) 12 TAKAware 0x000000010230ac3c closure #1 in UDPMessage.connect() + 252 (UDPMessage.swift:68) 13 Network 0x000000018506b68c closure #1 in NWConnectionGroup.setReceiveHandler(maximumMessageSize:rejectOversizedMessages:handler:) + 200 (NWConnectionGroup.swift:458) 14 Network 0x000000018506b720 thunk for @escaping @callee_guaranteed (@guaranteed OS_dispatch_data?, @guaranteed OS_nw_content_context, @unowned Bool) -> () + 92 (<compiler-generated>:0) 15 Network 0x0000000185185df8 invocation function for block in nw_connection_group_handle_incoming_packet(NWConcrete_nw_connection_group*, NSObject<OS_nw_endpoint>*, NSObject<OS_nw_endpoint>*, NSObject<OS_nw_interface>*, NSObje... + 112 (connection_group.cpp:1075) 16 libdispatch.dylib 0x000000018c4ad2b8 _dispatch_block_async_invoke2 + 148 (queue.c:574) 17 libdispatch.dylib 0x000000018c4b7584 _dispatch_client_callout + 16 (client_callout.mm:85) 18 libdispatch.dylib 0x000000018c4d325c _dispatch_queue_override_invoke.cold.3 + 32 (queue.c:5106) 19 libdispatch.dylib 0x000000018c4a21f8 _dispatch_queue_override_invoke + 848 (queue.c:5106) 20 libdispatch.dylib 0x000000018c4afdb0 _dispatch_root_queue_drain + 364 (queue.c:7342) 21 libdispatch.dylib 0x000000018c4b054c _dispatch_worker_thread2 + 156 (queue.c:7410) 22 libsystem_pthread.dylib 0x000000020eaa5624 _pthread_wqthread + 232 (pthread.c:2709) 23 libsystem_pthread.dylib 0x000000020eaa29f8 start_wqthread + 8 (:-1) Basically we're receiving a message via UDP that is an XML packet. We're parsing that packet using what I think it pretty straightforward code that looks like this: func parseXml(dataStream: Data?) -> Array<String> { var events: [String] = [] guard let data = dataStream else { return events } currentDataStream.append(data) var str = String(decoding: currentDataStream, as: UTF8.self) while str.contains(StreamParser.STREAM_DELIMTER) { let splitEvent = str.split(separator: StreamParser.STREAM_DELIMTER, maxSplits: 1) let cotEvent = splitEvent.first! var restOfString = "" if splitEvent.count > 1 { restOfString = String(splitEvent.last!) } events.append("\(cotEvent)\(StreamParser.STREAM_DELIMTER)") str = restOfString } currentDataStream = Data(str.utf8) return events } the intention is that the message may be broken across multiple packets, so we build them up here. Is there anything I can do to guard against these crashes?

It appears that on older posts the code blocks are completely broken. For example https://developer.apple.com/forums/thread/678075 show the code block as a single inline value. Looking at the HTML this is what I see generated <code class="hljs block shell language-shell">Code Block shell#!/bin/bashrm -rf output/rm -rf simulator_fat/mkdir simulator_fatlibs=( "lib_static" ) #Add for i in "${libs[@]}"do lipo -create arm64_simulator/$i.a x86_64/$i.a -output simulator_fat/$i.a xcodebuild -create-xcframework -library simulator_fat/$i.a -library arm64/$i.a -output output/$i.xcframeworkdone</code> Obviously newer code blocks seem to be working (as long as the one above is) but it wreaks havoc trying to look at older posts.