New macOS Universal Binaries are signed

[aarlt]

Our new Unversal Binary Executable is now signed, while our old executables where not signed at all. This might create different behaviour related to security prompts.

We might need to discuss whether we should just remove the signature (if possible), or whether we need to sign it in a proper way.

Old Executable:

# codesign -dv --verbose=4 solc-macos
solc-macos: code object is not signed at all

New Universal Binary Executable:

# codesign -dv --verbose=4 solc-macos
Executable=solc-macos
Identifier=main-arm64.out
Format=Mach-O universal (x86_64 arm64)
CodeDirectory v=20400 size=298023 flags=0x20002(adhoc,linker-signed) hashes=9310+0 location=embedded
VersionPlatform=1
VersionMin=853248
VersionSDK=917504
Hash type=sha256 size=32
CandidateCDHash sha256=d5ab423e4c721c7d8cb5069e0460765e0f1ffdb5
CandidateCDHashFull sha256=d5ab423e4c721c7d8cb5069e0460765e0f1ffdb5a3f6da425901ff6b1291e7c4
Hash choices=sha256
CMSDigest=d5ab423e4c721c7d8cb5069e0460765e0f1ffdb5a3f6da425901ff6b1291e7c4
CMSDigestType=2
Executable Segment base=0
Executable Segment limit=24353728
Executable Segment flags=0x1
Page size=4096
CDHash=d5ab423e4c721c7d8cb5069e0460765e0f1ffdb5
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none

[ekpyron]

What would signing it properly entail? I guess that'd mean registering an official account with Apple and managing credentials for it? Knowing Apple probably even paying for getting it verified (I'm not sure)?

[sambacha]

What would signing it properly entail? I guess that'd mean registering an official account with Apple and managing credentials for it? Knowing Apple probably even paying for getting it verified (I'm not sure)?

If you want your apps to open on a Mac that has Gatekeeper enabled or want to distribute apps in the App Store, you need to create a developer ID to sign your Mac apps and installer packages; only Apple Developer code signing certificates are compatible with GateKeeper.

You can use a codesigning certificate that is self issued by yourself, however you will need the end user to install the certificate on their machine, and you still do not have the benefit of being accessible without bypassing GateKeeper.

Check for GateKeeper

    gatekeeper_status=`spctl --status | awk '/assessments/ {print $2}'`
   if [ $gatekeeper_status = "disabled" ]; then
      result=Disabled
   else
      result=Active
   fi
   echo $result
fi

Instrumenting without CodeSign

To instrument a binary that is not codesigned you have to do the following:

I mention this as its a slight benefit to getting it 'codesigned'.

codesign -s - -v -f --entitlements debug.plist $PATH_TO_BINARY_WITH_DSYM_INFO

debug.plist

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.security.get-task-allow</key><true/></dict></plist>

0.8.24

My local binary shows a non-universal binary, only arm-64 under Format

$ codesign -dv --verbose=4  $HOME/.svm/0.8.24/solc-0.8.24
Executable=/Users/janitor/.svm/0.8.24/solc-0.8.24
Identifier=solc
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=288701 flags=0x20002(adhoc,linker-signed) hashes=9019+0 location=embedded
VersionPlatform=1
VersionMin=720896
VersionSDK=787200
Hash type=sha256 size=32
CandidateCDHash sha256=cb7250ee8e2cc8a52b27c2e910aeb5917e3caf04
CandidateCDHashFull sha256=cb7250ee8e2cc8a52b27c2e910aeb5917e3caf0482eeb8b89375c201586713f0
Hash choices=sha256
CMSDigest=cb7250ee8e2cc8a52b27c2e910aeb5917e3caf0482eeb8b89375c201586713f0
CMSDigestType=2
Executable Segment base=0
Executable Segment limit=27901952
Executable Segment flags=0x1
Page size=4096
CDHash=cb7250ee8e2cc8a52b27c2e910aeb5917e3caf04
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none

I would prefer not to use universal binary tbh, the binary is more performant built native.

[sambacha]

My differing solc binary is due to svm-rs and it providing aarch64 binaries separately, alloy-rs/solc-builds#13

[ekpyron]

We decided to move back to the previous status quo that was fully unsigned binaries for the time being in https://github.com/ethereum/solidity/pull/14869, so I'm closing this until there is a user-request for having signatures.

I would prefer not to use universal binary tbh, the binary is more performant built native.

Are you sure? Universal binaries are native builds, just several of them for multiple platforms packed together. The only difference you should see is the size of the binary, not in performance.

[sambacha]

We decided to move back to the previous status quo that was fully unsigned binaries for the time being in #14869, so I'm closing this until there is a user-request for having signatures.

I would prefer not to use universal binary tbh, the binary is more performant built native.

Are you sure? Universal binaries are native builds, just several of them for multiple platforms packed together. The only difference you should see is the size of the binary, not in performance.

The perf diff was due to using a different linker (its called sold) - forgot it was set as default on this computer

[cameel]

Reopening since we ended up reverting #14869 and the release binaries are still signed with an ad-hoc signature. We need to decide whether we're fine with that or if we actually want to try to get it signed properly (maybe there's still some way that does not require kowtowing to Apple?).