search

beeware / briefcase

Tools to support converting a Python project into a standalone native application.
https://briefcase.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
2.68k stars 371 forks source link

Cannot code sign on Big Sur MacOS #1818

Open JonathanLoungani opened 6 months ago

JonathanLoungani commented 6 months ago

Describe the bug

When following the BeeWare tutorial on a Big Sur MacOS (x86_64), the briefcase build command is unable to code sign.

Steps to reproduce

  1. Follow the steps in the BeeWare tutorial until Tutorial 3 – Packaging for distribution.
  2. Run briefcase create
  3. Run briefcase build
  4. Observe that the briefcase build command fails with the following error: 
    Unable to code sign /Users/jonathanloungani/dev/beeware/beeware-tutorial/helloworld/build/helloworld/macos/app/Hello World.app.

    Notably, the command

    codesign '/Users/jonathanloungani/dev/beeware/beeware-tutorial/helloworld/build/helloworld/macos/app/Hello World.app' --sign - --force --entitlements /Users/jonathanloungani/dev/beeware/beeware-tutorial/helloworld/build/helloworld/macos/app/Entitlements.plist

Produces the following result:

/Library/Developer/CommandLineTools/usr/bin/codesign_allocate: fatal error: file not in an order that can be processed (link edit information does not fill the __LINKEDIT segment): /Users/jonathanloungani/dev/beeware/beeware-tutorial/helloworld/build/helloworld/macos/app/Hello World.app/Contents/MacOS/Hello World (for architecture x86_64)
/Users/jonathanloungani/dev/beeware/beeware-tutorial/helloworld/build/helloworld/macos/app/Hello World.app: the codesign_allocate helper tool cannot be found or used

Expected behavior

The ad-hoc signing should complete without issue.

Screenshots

No response

Environment

Logs

briefcase.2024_05_20-16_37_34.build.log

Additional context

No response

JonathanLoungani commented 6 months ago

I am looking further into this issue. Currently, this StackOverflow post suggests that "This problem happens when xcode-select developer directory was pointing to /Library/Developer/CommandLineTools when a full regular Xcode was required (happens when CommandLineTools are installed after Xcode)".

I verified that xcode-select -p prints /Library/Developer/CommandLineTools. In addition, the following is output after entering the command xcodebuild

xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
freakboy3742 commented 6 months ago

Interesting - Briefcase should be verifying that all the necessary tools are available, including differentiating between Xcode and the Command Line Tools.

I've just done a test on my M1 Mac, and it looks like it is possible to use the command line tools to sign; I wonder if this might be an x86-related incompatibility. Although the SO post mentions the specific install order, I don't think the order of installation is likely to be the cause - this should only be triggered be the tools that are currently active.

JonathanLoungani commented 6 months ago

Continuing to dig, I found the following page on PyInstaller which explains an issue with PyInstaller that produces the same error message.

PyInstaller breaks OSX code signing because it appends python code at the end of the binary. Appending data at the end of executable breaks the Mach-o format structure. codesign utility complains with the following messages. the __LINKEDIT segment does not cover the end of the file (can't be processed) file not in an order that can be processed (link edit information does not fill the __LINKEDIT segment)

I'm not sure whether this is directly relevant.

JonathanLoungani commented 6 months ago

Current guess based on discussion during the sprint:

Something in the format of the template being produced by recent versions of Xcode are incompatible with the code signing tools from the older versions of Xcode.

Next steps:

nidhikamath2102 commented 6 months ago

If anyone is still facing issue even after checking XCode and iCloud Drive, the following worked for me!

Steps to follow:

  1. Check if XCode is updated (App Store), installed and active (xcode-select -p)

  2. Check if the directory where project is created is not synced to iCloud Drive (System Settings -> iCloud -> iCloud Drive)

  3. Check git config --global –list. I had git config core.autocrlf=true by mistake. Set to false (git config core.autocrlf false) or remove (git config --global --unset core.autocrlf) it. (Setting core.autocrlf=true is generally recommended for Windows users to avoid issues with line endings) Read More about this here - https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings#per-repository-settings

  4. Finally remove the build and clean the project. Do so as mentioned below, rm -rf build rm -rf ~/.cookiecutters/ briefcase build

This worked like a charm! Happy Coding!

freakboy3742 commented 6 months ago

@nidhikamath2102 To clarify - the issue you were seeing (CRLF handling) is a different way to manifest the same error message. The PyCon sprints have revealed at least 3 ways that signing can fail:

  1. The project drive is being mirrored on iCloud
  2. Git has core.autocrlf enabled
  3. Running on an x86_64 machine with an older version of Xcode.

These are all distinct issues, with different solutions - although they all manifest with the "Unable to code sign" error message.

JonathanLoungani commented 6 months ago

I was unable to build the stub project from the Mac OS app template on my machine, as described in this issue: https://github.com/beeware/Python-Apple-support/issues/220

hlovatt commented 2 days ago

Using Ad Hoc signing, tutorial build fails for me with:

Unable to code sign /Users/lov080/Library/Mobile Documents/com~apple~CloudDocs/Python/beeware-tutorial/helloworld/build/helloworld/macos/app/Hello World.app.

Going through all of nidhikamath2102 points and adding in Intel Processor point, Python version, and OS version also mentioned in this forum:

  1. M1 MacBook Air, therefore not Intel problem
  2. Sequoia 15.1, therefore not out of date OS
  3. Have Xcode installed (xcode-select -p gives: "/Applications/Xcode.app/Contents/Developer"), therefore not lack of Xcode problem
  4. Python 3.12.7, therefore not old Python
  5. I don't have a .gitconfig file, therefore not core.autocrlf problem.
  6. iCloud is syncing, can see up to date files on icloud.com, therefore not iCloud problem.

Unfortunately this means that the problem is not due to anything discussed here and is a show stopper for me.

freakboy3742 commented 2 days ago

@hlovatt The issue with iCloud isn't having the folder being out of date with syncing - it's with using an iCloud synced folder at all. iCloud writes metadata to the folders that it manages in a way that renders them unsignable.

The only solution I'm aware of is to not use a folder that is associated with iCloud - it needs to be a "local only" folder.

hlovatt commented 1 day ago

Great. All works now. Many thanks. (It works on OneDrive.)