You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suppose there's not a great solution for this. In our case, the filenames themselves have the creation timestamp in them, so tracing_appender may be able to use that.
Otherwise, perhaps exposing an option to prevent this from being linked in at compile-time would be sufficient, like perhaps behind a feature. We tested without rollover (so this codepath should not be hit at runtime) and it still triggered Apple's warning.
Alternatives
Unfortunately we're considering just removing tracing_appender altogether and rolling our own non-blocking log writer that doesn't read file timestamp metadata. :-(
The text was updated successfully, but these errors were encountered:
jamilbk
changed the title
Don't rely on file creation timestampstracing_appender: Don't rely on file creation timestamps
Mar 28, 2024
jamilbk
changed the title
tracing_appender: Don't rely on file creation timestampstracing_appender: Don't rely on file creation timestamps for core functionality
Mar 28, 2024
jamilbk
changed the title
tracing_appender: Don't rely on file creation timestamps for core functionalitytracing_appender: Don't rely on reading file creation timestamps for core functionality
Mar 29, 2024
jamilbk
changed the title
tracing_appender: Don't rely on reading file creation timestamps for core functionalitytracing_appender triggers Apple NSPrivacyAccessedAPICategoryFileTimestamp API usage warning in App Store
Mar 29, 2024
jamilbk
changed the title
tracing_appender triggers Apple NSPrivacyAccessedAPICategoryFileTimestamp API usage warning in App Storetracing_appender triggers Apple NSPrivacyAccessedAPICategoryFileTimestamp API usage warning
Mar 29, 2024
.metadata().ok() is an API coming from std; which makes things... complicated. I'd recommend making your own appender that is compliant with Apple's privacy manifests.
Feature Request
Crates
tracing_appender
Motivation
Apple's new Privacy regulations force developers to now declare a "Privacy Manifest" file
with details on why the API in question is needed.
tracing_appender
seems to use theNSPrivacyAccessedAPICategoryFileTimestamp
API in its operation here.This creates a hurdle for building applications for Apple platforms that use tracing_appender as it reads file timestamps by default.
See the error message we received from the App Review team.
Proposal
I suppose there's not a great solution for this. In our case, the filenames themselves have the creation timestamp in them, so tracing_appender may be able to use that.
Otherwise, perhaps exposing an option to prevent this from being linked in at compile-time would be sufficient, like perhaps behind a feature. We tested without rollover (so this codepath should not be hit at runtime) and it still triggered Apple's warning.
Alternatives
Unfortunately we're considering just removing tracing_appender altogether and rolling our own non-blocking log writer that doesn't read file timestamp metadata. :-(
The text was updated successfully, but these errors were encountered: