macOS 14.5 marks files opened in non-notarized apps with quarantine attribute

Question

Created Sep ’24

Replies 5

Boosts 0

Participants 2

So I'm trying to maintain free open-source macOS tools. These two tools are sandboxed and hardened runtime. One is an image viewer that writes out a perftrace file into the sandbox folder (in Containers). Then another app tries to open that perftrace file (json).

When the perftrace file is opened in Xcode (signed and notarized), the file opens fine the first and all subsequent times.

When the opening app is kram-profile (signed not notaraized), the file opens once and then nothing can ever open it again. The app has attribute com.apple.quarantine set on it.

The only workaround to then open this file is to remove the attribute

xattr -d com.apple.quarantine <filename>

This is my tool build in Xcode, and having to sign let alone notarize an app is a large amount of complexity. Also this app is available on github.

Answered by DTS Engineer in 802903022

this just seems to be the default behavior of turning on the App Sandbox.

Right. And for the reasons that you outlined.

If you repeat your test with a file using the .txt extension, do you still see the problem?

In general, quarantine doesn’t apply to documents. However, some document types could contain code, and thus are checked by quarantine. For example, on my Mac I created two documents, test.txt and test.md, and quarantined them in the same way. The test.txt document always opens fine, but the test.md document bumps into the issue you’re seeing [1].

I’ve never explored this space in detail, so I’m not 100% sure what all the rules are. Hence the test I’ve suggested above.

I guess the lesson is to only enable hardened runtime and app sandbox in an App Store or otherwise distributable build, and not in the debug/release builds.

That seems like it’d be a mistake in general. The hardened runtime and App Sandbox both significantly change the behaviour of your app. If you only enable them when you ship, you are likely to miss problems. In this case it seems like it’d be better to create a build just for profiling. Alternatively, you can remove the quarantine in this case.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Markdown can contain HTML which is code as far as quarantine is concerned.

Boost

Answer 1

Alecazam OP

Sep ’24

Even writing a file to the Containers tmp folder is marked as quarantine. This is using C style fopen()/fclose() calls. Then I open and copy the contents to another file in the same Containers folder (since tmp file will be removed). So both files end up with quarantine flag set.

This all worked perfectly fine in macOS 11-13. So this is something that changed in macOS 14. I used to be able to sign app locally, and all would work.

0

Answer 2

Alecazam OP

Sep ’24

kramv.perftrace

Tmp file:

    com.apple.quarantine	 20

Copied to ../Traces/ folder

	com.apple.LaunchServices.OpenWith	147 
	com.apple.lastuseddate#PS	 16 
	com.apple.macl	 72 
	com.apple.quarantine	 20

clearing quarantine attribute, it returns after opening file in profile app

   com.apple.LaunchServices.OpenWith	147 
   com.apple.lastuseddate#PS	 16 
   com.apple.macl	 72 
   com.apple.quarantine	 27   <- changed to 27

0

Answer 3

Alecazam OP

Sep ’24

Okay, so this just seems to be the default behavior of turning on the App Sandbox. Even though sandboxed apps are able to write to the container folder, the files are marked as quarantine. That way the app can't open a script, or any other app can open the file without a permission query. For some reason, macOS never posts that permission query, and just posts that the file is damaged and should be moved to the trash.

So I guess the lesson is to only enable hardened runtime and app sandbox in an App Store or otherwise distributable build, and not in the debug/release builds.

0

Answer 4

DTS Engineer OP

Apple

Sep ’24

Recommended

this just seems to be the default behavior of turning on the App Sandbox.

Right. And for the reasons that you outlined.

If you repeat your test with a file using the .txt extension, do you still see the problem?

In general, quarantine doesn’t apply to documents. However, some document types could contain code, and thus are checked by quarantine. For example, on my Mac I created two documents, test.txt and test.md, and quarantined them in the same way. The test.txt document always opens fine, but the test.md document bumps into the issue you’re seeing [1].

I’ve never explored this space in detail, so I’m not 100% sure what all the rules are. Hence the test I’ve suggested above.

I guess the lesson is to only enable hardened runtime and app sandbox in an App Store or otherwise distributable build, and not in the debug/release builds.

That seems like it’d be a mistake in general. The hardened runtime and App Sandbox both significantly change the behaviour of your app. If you only enable them when you ship, you are likely to miss problems. In this case it seems like it’d be better to create a build just for profiling. Alternatively, you can remove the quarantine in this case.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Markdown can contain HTML which is code as far as quarantine is concerned.

0

Answer 5

Alecazam OP

Sep ’24

Would help if the docs mentioned this About sandboxes. This was a perftrace file, but it was just Perfetto json. So the files definitely get this attribute set. 20 seemed to be for a written file, and when attribute was cleared and then file is read changes to 27. Both are labeled as com.apple.quarantine.

It’s also confusing since there is the Xcode setting for “app sandbox” which I hadn’t set, but sometime back I’d set the entitlement in prep for App Store. So some of the sandboxing was already applied. Now I just turned it all off. But will add back in a shipping build script.

Seems like App Store builds are mostly about writing plist entries and not touching the Xcode settings. Otherwise, I can’t put these projects/apps up on github with team id and provisioning and signing and hardened runtime. This to too much work for free tools. We couldn’t actually put several Adobe tools in the App Store as a result.

0