TrustKit initialisation fully blocks the main thread ina NotificationServiceExtension if its attempted before first unlock BFU. This makes it impossible to use trustkit to pin network calls made from extensions which imo is a major issue.
Steps to reproduce
Create an application with a NotificationServiceExtension.
Either on the implementation of UNNotificationServiceExtension.init or UNNotificationServiceExtension.didReceive(_:withContentHandler:) attempt to instantiate TrustKit via TrustKit(configuration: someconfiguration). The configuration object seems irrelevant to reproduce the issue.
Install the app+extension on a real device, launch and make sure to grab the push notification token.
Make sure to set a PIN/Password on your phone.
Restart your phone. DO NOT UNLOCK IT
Send a notification to the phone via your preferred method (I recommend APNS console which should just require the PN token from step 3.). The payload is not important aside from making sure it has an aps.alert dictionary and aps.content-mutable: 1 so that it gets processed by the service extension.
There should be an abnormal delay in the PN arriving.
Export the sysdiagnose to your computer and you should see something along these lines in the system_logs.logarchive file:
default 2023-10-04 13:16:30.938216 +0100 NotificationExtension Hello, I'm launching as euid = 501, uid = 501, personaid = 1000, type = DEFAULT, name = <private>
default 2023-10-04 13:16:30.980808 +0100 NotificationExtension Will initialize TrustKit <- I added this log line
error 2023-10-04 13:16:31.073940 +0100 NotificationExtension Attempting to create a background session before first device unlock!
default 2023-10-04 13:16:31.073976 +0100 NotificationExtension Waiting for first unlock
default 2023-10-04 13:16:31.074028 +0100 NotificationExtension Device is locked - waiting
error 2023-10-04 13:17:00.605212 +0100 SpringBoard [your.extension.bundle.id] Extension will be killed because it used its runtime in starting up
TSKBackgroundReporter.init creates a NSURLSession with background configuration.
This blocks the calling thread until the phone is first unlocked (don't ask me why, its apple'd behavior.)
Expected Results:
Initialising trustKit should still be possible from a BFU context. Failing that, we should at least throw an error or have some warnings in the docs that it cannot be used by extensions reliably. (Save the next guy the insane amount of time it took me to diag this.)
Problem description
TrustKit initialisation fully blocks the main thread ina NotificationServiceExtension if its attempted before first unlock BFU. This makes it impossible to use trustkit to pin network calls made from extensions which imo is a major issue.
Steps to reproduce
UNNotificationServiceExtension.initorUNNotificationServiceExtension.didReceive(_:withContentHandler:)attempt to instantiate TrustKit viaTrustKit(configuration: someconfiguration). The configuration object seems irrelevant to reproduce the issue.aps.alertdictionary andaps.content-mutable: 1so that it gets processed by the service extension.system_logs.logarchivefile:Explanation:
TrustKit.initcreates aTSKBackgroundReporterregardless of reporting flags in the configuration: https://github.com/datatheorem/TrustKit/blob/master/TrustKit/TrustKit.m#L156TSKBackgroundReporter.initcreates aNSURLSessionwith background configuration.Expected Results:
Initialising trustKit should still be possible from a BFU context. Failing that, we should at least throw an error or have some warnings in the docs that it cannot be used by extensions reliably. (Save the next guy the insane amount of time it took me to diag this.)
Kindly,
Caio