NetworkExtension uses NSPrivacyAccessedAPICategoryFileTimestamp causing App Store hurdle about firezone HOT 6 CLOSED

Looks like something inside the NetworkExtension uses the API as well.

Hello,

We noticed one or more issues with a recent submission for TestFlight review for the following app:

Firezone
Version 1.0.0
Build 1711660079
Although submission for TestFlight review was successful, you may want to correct the following issues in your next submission for TestFlight review. Once you've corrected the issues, upload a new binary to App Store Connect.

ITMS-91053: Missing API declaration - Your app’s code in the “PlugIns/FirezoneNetworkExtensioniOS.appex/FirezoneNetworkExtensioniOS” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryFileTimestamp. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.

Apple Developer Relations

from firezone.

It's probably coming from tracing_appender: https://github.com/tokio-rs/tracing/blob/master/tracing-appender/src/rolling.rs#L605

from firezone.

Unfortunately this is still an issue even without the log roller. Just got the email from Apple. 😢

Perhaps there are other places where tracing_appender is reading file timestamp metadata.

Refs tokio-rs/tracing#2918

from firezone.

Just received the error again. The saga continues.

from firezone.

I think I found the last place it's being used:

https://github.com/tokio-rs/tokio/blob/master/tokio/src/net/unix/pipe.rs#L1376

That means that codepath is likely being hit. I'll see if I can fork and patch around it to test the theory.

from firezone.

I've confirmed that this change successfully removes the last remaining _fstat from the debug target.

HOWEVER, _stat and _fstat are still present in the --release target.

Very strange. --release is actually pulling in more syscalls than the debug target. My current theory is that rustc is pulling in those from the System framework during release builds with -lSystem.

If I run nm on the resulting network extension binary, we can see that's where they're from. This would make sense, System contains the libc headers presumably.

(undefined) external _stat (from libSystem)

(undefined) external _fstat (from libSystem)

from firezone.