Code signing fails when running on an iCloud mounted drive

[DragonFired]

Describe the bug

While following the Beware tutorial in the Packaging for distribution section, briefcase build fails whit the following error:

Unable to code sign /Users/arana/Documents/PycharmProjects/Personal/IntroToBeewareRetread/helloworld/build/helloworld/macos/app/Hello World.app.

The actual error being raised by codesign is

Resource fork, Finder information, or similar detritus not allowed

Steps to reproduce

1. Create a helloworld project in a folder that is being mirrored on iCloud
2. Enter briefcase create; briefcase build
3. See error

Expected behavior

Build complete successfully.

Screenshots

No response

Environment

• Operating System: MacOS 14.4.1
• Python version: 3.12.0
• Software versions:
  • Briefcase: 0.3.18
  • Toga:
  • ...

Logs

briefcase.2024_05_20-12_21_49.build.log

Additional context

Build succeeded on M1 Mac with similar software config.

[freakboy3742]

Thanks for the report; the underlying problem appears to be this issue.

[freakboy3742]

Filling in some details found in person: It appears that the issue is running the tutorial on a drive that is being archived on iCloud. The iCloud syncing process is adding metadata to the files in the .app bundle, which the signing process can't deal with.

The immediate workaround is to avoid running Briefcase on an iCloud synced drive... but that's not a very satisfying solution.

[alcarithemad]

When iCloud Drive (and likely any other File Provider extension, like Google Drive) controls a directory, the system daemon implementing it will set extended attributes on directories. Since the File Provider API is a sort of FUSE-like system, it's impossible to remove these attributes, as the underlying framework controls all reads in the directory.

I think the only way to sign an app in this case is to check for the presence of the extended attribute (specifically, it seems to be com.apple.fileprovider.fpfs#P, but I'd suggest matching any com.apple.fileprovider attribute) on the app folder and copy the app bundle to a temporary directory that is not under the control of a File Provider extension, then copy the signed bundle back.

[freakboy3742]

The other approach would be straightforward prevention - if an attempt is made to run briefcase where pyproject.toml is on a drive that sets file attributes, refuse to run at all.

In terms of identifying the problem - iCloud attributes can be idenfied using xattr -lr <path>. If any content is returned, there are files with attributes.