The _encodeDateHeader method in SigV4Signer+PayloadSigning.swift is throwing unexpected exceptions.

[Danson23]

Describe the bug

Specifically, the _encodeDateHeader method in SigV4Signer+PayloadSigning.swift, which is responsible for encoding the date header, is encountering unexpected crashes.

Steps To Reproduce

Based on our log analysis, we've identified an exception that hasn't been able to be replicated in a controlled environment. We've narrowed down the potential cause to the execution of the following code snippet.

let vc = UIHostingController(rootView: FaceLivenessDetectorSubView(sessionId: sessionid))
vc.modalPresentationStyle = .fullScreen
self.present(vc, animated: true)

Expected behavior

I expect to address this issue by releasing a new version with the necessary fixes.

Swift Liveness Version

1.3.3

Xcode version

Xcode 15.4(15F31d)

Relevant log output

Crashed: com.amazon.aws.amplify.liveness.service
0  xxxx                           0x1fd0000 specialized SigV4Signer._encodeDateHeader(_:) + 4373839872 (<compiler-generated>:4373839872)
1  xxxx                           0x1fcfdd0 specialized SigV4Signer._encodeDateHeader(_:) + 80 (SigV4Signer+PayloadSigning.swift:80)
2  xxxx                           0x1fcf5d8 SigV4Signer._stringToSignWithPreviousSignature(timestamp:credentialScope:payload:dateHeader:) + 61 (SigV4Signer+PayloadSigning.swift:61)
3  xxxx                           0x1fce934 SigV4Signer.signWithPreviousSignature(payload:dateHeader:) + 32 (SigV4Signer+PayloadSigning.swift:32)
4  xxxx                           0x1fa0148 closure #1 in FaceLivenessSession.send<A>(_:eventDate:) + 116 (FaceLivenessSession.swift:116)
5  xxxx                           0x1fa0e78 partial apply for thunk for @callee_guaranteed () -> () + 4373646968 (<compiler-generated>:4373646968)
6  xxxx                           0x1fa03cc thunk for @escaping @callee_guaranteed () -> () + 4373644236 (<compiler-generated>:4373644236)
7  libdispatch.dylib              0x40d0 _dispatch_client_callout + 20
8  libdispatch.dylib              0x13750 _dispatch_lane_barrier_sync_invoke_and_complete + 56
9  xxxx                           0x1f9fcc8 FaceLivenessSession.send<A>(_:eventDate:) + 99 (FaceLivenessSession.swift:99)
10 xxxx                           0x1fa096c protocol witness for LivenessService.send<A>(_:eventDate:) in conformance FaceLivenessSession + 4373645676 (<compiler-generated>:4373645676)
11 xxxx                           0x17f18d4 FaceLivenessDetectionViewModel.sendInitialFaceDetectedEvent(initialFace:videoStartTime:) + 245 (FaceLivenessDetectionViewModel.swift:245)
12 xxxx                           0x17ed438 specialized closure #6 in FaceLivenessDetectionViewModel.process(newResult:) + 56 (FaceLivenessDetectionViewModel+FaceDetectionResultHandler.swift:56)
13 xxxx                           0x17f0ce4 closure #1 in FaceLivenessDetectionViewModel.drawOval(onComplete:) + 174 (FaceLivenessDetectionViewModel.swift:174)
14 xxxx                           0x17eee4c thunk for @escaping @callee_guaranteed @Sendable () -> () + 4365577804 (<compiler-generated>:4365577804)
15 libdispatch.dylib              0x2370 _dispatch_call_block_and_release + 32
16 libdispatch.dylib              0x40d0 _dispatch_client_callout + 20
17 libdispatch.dylib              0x129e0 _dispatch_main_queue_drain + 980
18 libdispatch.dylib              0x125fc _dispatch_main_queue_callback_4CF + 44
19 CoreFoundation                 0x56204 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
20 CoreFoundation                 0x53440 __CFRunLoopRun + 1996
21 CoreFoundation                 0x52830 CFRunLoopRunSpecific + 588
22 GraphicsServices               0x11c4 GSEventRunModal + 164
23 UIKitCore                      0x3d2eb0 -[UIApplication _run] + 816
24 UIKitCore                      0x4815b4 UIApplicationMain + 340
25 xxxx                           0xe87ec main + 15 (main.m:15)

Is this a regression?

Yes

Regression additional context

No response

OS Version

IOS 18.1.1/ IOS16.7.10

Device

iPhone 13/ iPhone 8

Specific to simulators

No response

Additional context

No response

[mattcreaser]

Thank you for the report @Danson23. Someone from the team will need to investigate this.

[thisisabhash]

Hello,
Could you please share the reproduction steps and verbose logs by enabling

Amplify.Logging.logLevel = .verbose

Also, is the device date being manually set to an invalid value?

[RentonLin]

We also have two users who experienced crashes here.
The crashed code is as follows:

func _encodeDateHeader(_ dateHeader: (key: String, value: Date)) -> Data {
        let headerNameLength = UInt8(Data(dateHeader.key.utf8).count)
        let headerValueType = UInt8(8)
        var headerValue = UInt64(dateHeader.value.timeIntervalSince1970 * 1_000).bigEndian //<-- crashed here
        let headerValueBytes: [UInt8] = withUnsafeBytes(of: &headerValue, Array.init)
        let headerKey = Data(dateHeader.key.utf8)

        var data = Data()
        data.append(headerNameLength)
        data.append(contentsOf: headerKey)
        data.append(headerValueType)
        data.append(contentsOf: headerValueBytes)
        return data
    }

After reviewing the code, I found that the date value comes either from the AWS backend or is created using the current date.
Through testing, I discovered that the crash only occurs when the date is before January 1, 1970, which means dateHeader.value.timeIntervalSince1970 * 1_000 will produce a negative value. But date before January 1, 1970 cannot be manually set on an iPhone.
So, I suspect that the issue is caused by a date returned from the backend.

[vincetran]

Thanks for the details @RentonLin, do you happen to have the request IDs for those crashes so that we can send to the service team to investigate?

[RentonLin]

No，in that method's context, what we can get is only key and date.
So maybe what we can do is to add a log before sending request, then in the crash logs, we can get request id in the crash log?

[thisisabhash]

Hello, your suggestion of adding a log is correct.
We are looking for the sessionId so that this can be investigated by the service team.