macOS arm64 binary doesn't launch

[CodeWithShreyans]

Steps to reproduce

1. Copy .app file from dmg to Applications folder.
2. Right click and click open.

Expected behaviour

The app launches.

Actual behaviour

macOS says that it cant open the app.

Operating system

macOS 12.2 Beta (21D5025f)

Version of Kotatogram Desktop

1.4.6 beta (TD 3.3)

Installation source

Static binary from official website

Logs

No response

[ilya-fedin]

Well, we don't have mac hardware, so any help from your side on why this may happen will be highly appreciated

[CodeWithShreyans]

Well that was an extremely fast reply

[CodeWithShreyans]

Can you tell me some ways to find the problem? I am on an M1 Macbook Air 2020 And 1.4.4 works fine

[CodeWithShreyans]

You were having some issues with macOS builds, maybe that is related?

[ilya-fedin]

I can suggest the Linux way to get helpful logs: try to run the application from terminal. Both the .app and actual binary inside .app.

[ilya-fedin]

You were having some issues with macOS builds, maybe that is related?

Well, 1.4.6 is built with other build method. Previously we used packages from brew, now we're using tdesktop's build scripts. That way offers support for macOS 10.12+ and native ARM support.

[ilya-fedin]

The downside is it builds 6 hours on github actions :rofl:

[CodeWithShreyans]

The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x6000036c13b0 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}

This error in terminal

[ilya-fedin]

It's when try to run the .app I guess, what about the actual binary?

[CodeWithShreyans]

It doesn't let it run for security reasons

[ilya-fedin]

Can you overcome that somehow?

[CodeWithShreyans]

Let me try

[CodeWithShreyans]

zsh: killed     /Users/shreyans/Downloads/Kotatogram.app/Contents/MacOS/Kotatogram

Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Process completed]

Just this after overriding security policy

[ilya-fedin]

:sob: just killed?

[CodeWithShreyans]

Yeah this is the only logging that happens after launching the binary directly

[CodeWithShreyans]

Maybe because you switched from x86_64 only to universal binary?

[ilya-fedin]

macOS is a murderer :see_no_evil:

[ilya-fedin]

Maybe because you switched from x86_64 only to universal binary?

Maybe, I don't know much about macOS internals

[CodeWithShreyans]

I think you should atleast stop the update rollout as clicking update button in app breaks it

[ilya-fedin]

But a person in kotato's telegram group says it works :thinking:

[CodeWithShreyans]

Is he on apple silicon running kotato 1.4.6 with macOS Monterey?

[ilya-fedin]

He is on x64 hackintosh IIRC, I don't remember the version though

[CodeWithShreyans]

works perfecty if I force it to run through rosetta which means something is wrong with the arm64 binary

[ilya-fedin]

I wonder what's wrong with arm64 binary, but looks like macOS is not going to tell that

[CodeWithShreyans]

I found the issue! Something is going wrong with app signing so only the x86_64 binary is getting correctly signed. I locally signed the app with sudo codesign --force -- deep --sign - /Path/to/App.app

[ilya-fedin]

kotato has no sign...

[CodeWithShreyans]

sudo codesign --verify --verbose ./Path/to/App.app

./Kotatogram.app: code object is not signed at all
In architecture: arm64

[CodeWithShreyans]

What do you mean no sign?

[CodeWithShreyans]

I think you mean the x86_64 binary is signed but just not verified by apple

[CodeWithShreyans]

I think you mean the x86_64 binary is signed but just not verified by apple

[ilya-fedin]

Only if the build process signs it on its own...

[ilya-fedin]

We have such a line in actions, without it people were unable to launch kotato on x86_64 at all. Maybe it doesn't change the arm part for some reason. https://github.com/kotatogram/kotatogram-desktop-builds/blob/master/.github/workflows/mac.yml#L126

[CodeWithShreyans]

Yes you are correct both the x86_64 and arm64 binaries aren't signed but I found out that arm64 binaries in macos are now killed on start if not signed: https://github.com/golang/go/issues/42684

[ilya-fedin]

Am I understand right that the sign that the linker signs automatically can't be used on another x86_64 machine, but can be used on another arm64 machine? So you can't produce an universal binary that will work on both x86_64 and arm64 without a valid sign?

[CodeWithShreyans]

I didn't understand what you said Which compiler are you using?

[ilya-fedin]

I didn't understand what you said

From the linked issue:

indeed, binaries produced by the machine's clang are codesigned, in what looks like the same exact way as the output of codesign -s -.

And then:

Looks like binaries aren't required to have a signature linked to a Developer ID if they were signed elsewhere. I was able to apply an ad-hoc signature to a binary on my Intel mac and transfer it to my M1 mac and it ran just fine. Appears like binaries just need a signature, doesn't really seem to matter where it came from.

But this 'ad-hoc sign' doesn't work on x86_64, people are unable to run the app even after removing it from quarantine, so codesign --remove-signature is used...

Which compiler are you using?

cmake says it's AppleClang

[CodeWithShreyans]

An ad-hoc sign is only valid to the local machine it was signed on. For example, I just ad-hoc signed the kotatogram app to make it work on my machine but it won't work on someone else's.

Executable=/Applications/Kotatogram.app/Contents/MacOS/Kotatogram
Identifier=io.github.kotatogram
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20400 size=900909 flags=0x2(adhoc) hashes=28147+3 location=embedded
Signature=adhoc
Info.plist entries=28
TeamIdentifier=not set
Sealed Resources version=2 rules=13 files=11
Internal requirements count=0 size=12

[ilya-fedin]

But they're saying in that issue:

Looks like binaries aren't required to have a signature linked to a Developer ID if they were signed elsewhere. I was able to apply an ad-hoc signature to a binary on my Intel mac and transfer it to my M1 mac and it ran just fine. Appears like binaries just need a signature, doesn't really seem to matter where it came from.

[CodeWithShreyans]

Maybe macs with the same Apple ID allow it

[CodeWithShreyans]

https://developer.apple.com/documentation/security/seccodesignatureflags/kseccodesignatureadhoc

[CodeWithShreyans]

Google Chrome's Signature for comparison:

Executable=/Applications/Google Chrome Dev.app/Contents/MacOS/Google Chrome Dev
Identifier=com.google.Chrome.dev
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=2465 flags=0x12a00(kill,restrict,library-validation,runtime) hashes=66+7 location=embedded
Signature size=9042
Timestamp=Dec 16, 2021 at 9:55:33 AM
Info.plist entries=39
TeamIdentifier=EQHXZ8M8AV
Runtime Version=12.0.0
Sealed Resources version=2 rules=13 files=60
Internal requirements count=1 size=204

[ilya-fedin]

So that means we can't have arm64 builds?

[CodeWithShreyans]

No no you can This guide looks good: https://localazy.com/blog/how-to-automatically-sign-macos-apps-using-github-actions

[ilya-fedin]

It seems the guide is about the paid certificate, we're not going to pay anything

[CodeWithShreyans]

No its not

[ilya-fedin]

"Another prerequisite is an Apple Developer Program subscription."

[CodeWithShreyans]

Just a minute

[CodeWithShreyans]

You just have to create a self signed certificate

[CodeWithShreyans]

You can try https://github.com/patrickpr/YAOG if you use Windows Ask me if you need any help

[ilya-fedin]

I don't use Windows