Recent

Author Topic: Apple Silicon (ARM64) code signing  (Read 3568 times)

ChrisR

  • Full Member
  • ***
  • Posts: 247
Apple Silicon (ARM64) code signing
« on: November 07, 2020, 02:39:33 pm »
The latest version of macOS (11.0.1 Beta, 20B5022a) requires that every native ARM64 application is code signed (this restriction does not apply to x86-64 applications).
  https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-require-signed-code/
Therefore, even compiling a "hello world" example requires a code sign:

 $fpc hello.pas
 Free Pascal Compiler version 3.3.1 [2020/07/22] for aarch64
 Copyright (c) 1993-2020 by Florian Klaempfl and others
 Target OS: Darwin for AArch64
 Compiling i2nii.pas
 Assembling (pipe) hello.pas
 Linking i2nii
 15 lines compiled, 0.1 sec
$./hello
zsh: killed ./hello
$codesign -s - ./hello
$./hello
Hello world!

Dmitry-
 Would it be possible to have Lazarus code sign with each compile. At the moment, when the user select Run/RunWithoutDebugging, the new application is built, but it will not launch as the newly compiled executable is not code signed (so the user needs to do this manually).

Jonas-
 Can you update your excellent manual to describe installation on Apple Silicon. For example, the created executable ppca64 must be code signed:

https://wiki.freepascal.org/macOS_Big_Sur_changes_for_developers#ARM64.2FAArch64.2FAppleSilicon_Support

Indeed, in addition to the Lazarus executable, a lot of other executables must be code signed, in my testing the minimal set was
codesign -s - startlazarus
codesign -s - lazarus
codesign -s - /usr/local/bin/fpc
codesign -s - /usr/local/bin/ppca64
codesign -s - /usr/local/bin/fpcres


Jonas Maebe

  • Hero Member
  • *****
  • Posts: 1058
Re: Apple Silicon (ARM64) code signing
« Reply #1 on: November 07, 2020, 02:55:47 pm »
The Xcode linker (which FPC uses) already adds an ad hoc signature to all binaries it creates. There should be no need to run codesign again separately, unless you want to sign using an actual developer signature.

This also means you still won't need a paying developer account to distribute ARM64 binaries for macOS.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 1058
Re: Apple Silicon (ARM64) code signing
« Reply #2 on: November 07, 2020, 03:43:46 pm »
Can you try deleting your "hello" binary before compiling it again? There are sometimes codesign signature caching issues when binaries get overwritten.

ChrisR

  • Full Member
  • ***
  • Posts: 247
Re: Apple Silicon (ARM64) code signing
« Reply #3 on: November 07, 2020, 03:55:27 pm »
Jonas-

Thanks for your response. For others that experience this issue after upgrading AArch64 Big Sur, upgrade your linker and other tools. For me, installing the latest "Command Line Tools for Xcode 12.2 Release Candidate" resolved the issue.

Igor Kokarev

  • Sr. Member
  • ****
  • Posts: 370
Re: Apple Silicon (ARM64) code signing
« Reply #4 on: November 07, 2020, 09:04:41 pm »
I had no problem with running my compiled AARCH64 app on 11.0.1 Beta (Apple DTK).

Lazarus/FPC also run fine (although I compiled them earlier with Beta 9).

11.0.1 Beta/RC work unstable, DTK reboots frequently, as also reported by other owners of DTK.

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: Apple Silicon (ARM64) code signing
« Reply #5 on: November 07, 2020, 11:37:07 pm »
Dmitry-
 Would it be possible to have Lazarus code sign with each compile. At the moment, when the user select Run/RunWithoutDebugging, the new application is built, but it will not launch as the newly compiled executable is not code signed (so the user needs to do this manually).
At this point of the time one should set up "After Compile" step in order to code-sign automatically.
an fully "automated" (and macOS specific) might require an IDE plugin (or changes in IDE itself)

Igor Kokarev

  • Sr. Member
  • ****
  • Posts: 370
Re: Apple Silicon (ARM64) code signing
« Reply #6 on: December 03, 2020, 06:14:50 pm »
How you codesign an app with embedded dynamic libraries?

Before signing, compiled app and compiled dylibs on this Mac work fine.

After codesigning of an app (aarch64), one of two dylibs doesn't load.

I sign the app bundle:

Code: Pascal  [Select][+][-]
  1. codesign --timestamp --options runtime --deep -s "Developer ID Application: CompanyName" MyApp.app

then I tried to sign all dylibs before sign APP bundle:

Code: Pascal  [Select][+][-]
  1. codesign --timestamp --options runtime --deep -s "Developer ID Application: CompanyName" MyApp.app/Contents/Frameworks/SomeLib1.dylib
  2. codesign --timestamp --options runtime --deep -s "Developer ID Application: CompanyName" MyApp.app/Contents/Frameworks/SomeLib2.dylib
  3. <...>
  4. codesign --timestamp --options runtime --deep -s "Developer ID Application: CompanyName" MyApp.app
  5.  

The same problem with loading second dylib.

This problem doesn't occur with signing x86-64 APP bundle where embedded dylibs are not signed at all.
« Last Edit: December 03, 2020, 06:26:39 pm by Igor Kokarev »

Thaddy

  • Hero Member
  • *****
  • Posts: 14204
  • Probably until I exterminate Putin.
Re: Apple Silicon (ARM64) code signing
« Reply #7 on: December 03, 2020, 08:34:45 pm »
This problem doesn't occur with signing x86-64 APP bundle where embedded dylibs are not signed at all.
Then you should report this to Apple, because all binaries should be signed.
Everything and all. No exceptions.
That is the whole point of Apple's policy.

(And that is how it should be. I commend Apple for this strict policy)

Are you sure they are embedded, so statically linked instead of dynamic?
Because both are possible with dylibs.
« Last Edit: December 03, 2020, 08:44:24 pm by Thaddy »
Specialize a type, not a var.

trev

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2020
  • Former Delphi 1-7, 10.2 user
Re: Apple Silicon (ARM64) code signing
« Reply #8 on: December 03, 2020, 09:51:18 pm »
From what I've read, the linker or other ad hoc signature is sufficient to run the binary (or shared library) on any macOS system. However, as Jonas mentions, there is a caching issue if the binary uses the same inode (so copying it elsewhere is a workaround).

It would be nice if macOS Lazarus could produce universal binaries like Xcode, but I suspect that will have to remain an "After compile" script for the moment at least.

Igor Kokarev

  • Sr. Member
  • ****
  • Posts: 370
Re: Apple Silicon (ARM64) code signing
« Reply #9 on: December 04, 2020, 03:28:30 pm »
trev,
Thaddy,

Thanks for your advices!

The problem occurs with dynamically loaded dylib. And statically loaded dylib is OK. All dylibs are included in /Frameworks folder in APP.

I found a temporary workaround - with entitlement com.apple.security.cs.disable-library-validation I successfully sign the APP and notarize it.

So I don't understand why some dylibs (compiled on this same Mac) can't be accepted for signing.

trev

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2020
  • Former Delphi 1-7, 10.2 user
Re: Apple Silicon (ARM64) code signing
« Reply #10 on: December 04, 2020, 10:25:23 pm »
So I don't understand why some dylibs (compiled on this same Mac) can't be accepted for signing.

It might be worth opening a TSI with Apple - Quinn The Eskimo gets back to you pretty quickly.

Igor Kokarev

  • Sr. Member
  • ****
  • Posts: 370
Re: Apple Silicon (ARM64) code signing
« Reply #11 on: December 05, 2020, 07:44:13 am »
trev,

Thanks, I'll think about this idea.

 

TinyPortal © 2005-2018