Question about Notarization and the com.apple.quarantine flag

Question

Created Oct ’23

Replies 4

Boosts 0

Participants 2

I've developed and distributed a plugin for Unreal Engine (builds as a .dylib). The plugin dynamically loads an external library that is a .bundle

The plugin has been notarized successfully. (Both the .dylib and the .bundle were signed with a Developer Application ID certificate.)

When the plugin is downloaded, both the .dylib and the .bundle get flagged with the quarantine attribute, however because it was notarized, the plugin is able to be loaded inside of Unreal Engine with no problem.

The issue occurs when the user moves the Unreal Engine project (with said plugin) to an external drive. In this case, once the project is opened and tries to load the plugin, an error saying is "***.bundle is damaged and can’t be opened. You should move it to the Trash."

I'm wondering if this is an Unreal Engine issue, or a MacOS(notarization/signing/entitlements/etc) issue.

Feels like if the .bundle is placed on an external drive, the OS does not check for notarization.

If i move the project back to the HD of the laptop, everything works as expected.
If i move the project to an external drive AND manually remove the com.apple.quarantine attribue (via terminal), then everything works as expected.

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’23

Is your external drive using a non-native file system, like MS-DOS/FAT. If you repeat this test with an APFS-formatted external drive, do you still see the problem?

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

1

Answer 2

oalvarado OP

Oct ’23

Thank you for your reply @eskimo.

I tested your suggestion and the issue does not occur if the project is in a APFS-formatted drive.

Is this expected behavior? And if so, is there anything that can be done so that this issue does not occur in the other drive formats?

Appreciate the feedback!

0

Answer 3

DTS Engineer OP

Apple

Nov ’23

the issue does not occur if the project is in a APFS-formatted drive.

Cool.

Is this expected behavior?

Well, clearly it was expected by me (-:

Seriously though, users should be able to run code off any supported volume format. Most of the time this just works. There are two common causes of failure:

Non-ASCII file names
Extended attributes

Are you using any non-ASCII file names within your bundle? If so, I recommend that you stop doing that. See this post for an explanation as to why that’s a bad idea.

Properly signed code should not rely on any extended attributes [1]. However, code that doesn’t follow the rules from Placing Content in a Bundle can end up with code signature info stored in EAs [2], and that can cause problems like this.

Try this:

Run the following against a copy of your bundle on an APFS volume:
```
% codesign -v -vvv --deep --strict /path/to/apfs/mycode.bundle
```
Copy that bundle to the problematic non-APFS volume.
Run the command from step 1 against the new path.

What output do you see?

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

[1] Well there are exceptions to every rule, but I don’t think that’s a concern here.

[2] I touch on this in TN3126 Inside Code Signing: Hashes.

0

Answer 4

oalvarado OP

Nov ’23

Thanks again for the information!

Here's the command run on the APFS drive:

***.bundle: valid on disk
***.bundle: satisfies its Designated Requirement

And on the other non-APFS drive:

***.bundle: a sealed resource is missing or invalid
file added: ***.bundle/Contents/.__CodeSignature
file added: ***.bundle/Contents/MacOS/._***
file added: ***.bundle/Contents/._MacOS
file added: ***.bundle/Contents/._Info.plist

There are no non-ASCII filenames inside the bundle. I suspect It might be with the way that the bundle is built. It's also a different team, from Japan, who creates the bundle - not sure if that might have some hidden potential causes.

The main content of the bundle is just a Mach-O universal binary that is a dynamic library.

Attached you can see an image of the file structure, if it's of any extra help. Screen Shot 2023-11-02 at 10.33.19 AM.png

Seems like they might need to fix something in their build process?

I'd be grateful of any additional information I can pass to them.

0