Crash and service failed to start on Sonoma 14.1

[JensenJiang]

• yabai: yabai-v6.0.0 (installed through macports)
• system: Sonoma 14.1

Hi all, I am observing 2 issues on Sonoma 14.1:

1. Service failed to start. When I use yabai --start-service to start the service, it keeps requesting Accessibility permission, although the permission is already granted. yabai_jensen.err.log shows yabai: could not access accessibility features! abort..
2. Crash on yabai -m window --focus east. When I run yabai in terminal and send yabai -m window --focus east, it segfault:

EVENT_HANDLER_DAEMON_MESSAGE: window --focus east
[1]    2336 segmentation fault  yabai --verbose

My config is mostly same as the example, with some app specific rules. Please lemme know if any other information is needed for triage.

[Mmasson-01]

same issue. Second point is a dup #1936

[Koston-0xDEADBEEF]

First problem sounds like codesign issue. You can try two things to fix it:

1. Remove yabai from accessibility permissions list entirely, then re-grant the permission when requested.

2. Sign the binary: sudo codesign -f -s - /opt/local/bin/yabai and see wiki for more in-depth information about codesigning and how to do it more properly.

[JensenJiang]

First problem sounds like codesign issue. You can try two things to fix it:

1. Remove yabai from accessibility permissions list entirely, then re-grant the permission when requested.

I tried this but it doesn't work, even if I used tccutil reset Accessiblity to reset all Accessibility settings.

2. Sign the binary: `sudo codesign -f -s - /opt/local/bin/yabai` and see wiki for more in-depth information about codesigning and how to do it more properly.

Yes this works like a magic! I wonder if the macports version might not sign the binary correctly? My skhd is also using macports version, but it doesn't have any issue with accessibility permision...

[Koston-0xDEADBEEF]

2. Sign the binary: `sudo codesign -f -s - /opt/local/bin/yabai` and see wiki for more in-depth information about codesigning and how to do it more properly.

Yes this works like a magic! I wonder if the macports version might not sign the binary correctly? My skhd is also using macports version, but it doesn't have any issue with accessibility permision...

That is probably the case, but I haven't had time to look further into it.

FWIW, you can check the signature with codesign -dv -r- /opt/local/bin/yabai

[JensenJiang]

FWIW, you can check the signature with codesign -dv -r- /opt/local/bin/yabai

Thanks for the pointer. Yeah inspection on yabai gives:

Executable=/opt/local/bin/yabai
Identifier=yabai
Format=Mach-O universal (x86_64 arm64)
CodeDirectory v=20400 size=5982 flags=0x20002(adhoc,linker-signed) hashes=184+0 location=embedded
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
/opt/local/bin/yabai: code object is not signed at all

and skhd:

Executable=/opt/local/bin/skhd
Identifier=skhd
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=733 flags=0x20002(adhoc,linker-signed) hashes=20+0 location=embedded
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
# designated => cdhash H"3cca883219e96b9252f76a41436b960a104145a6"

[JensenJiang]

For future references: it turns out that the pre-built binary provided by macports have different codesign situation:

• skhd: has cdhash
• yabai: has no codesign
  Will check with macports community to see why is it

[Koston-0xDEADBEEF]

* yabai: has no codesign
  Will check with macports community to see why is it

Can you @ me in any github issues/PRs you might find on this? I've done some MacPorts work before, and looking into yabai codesigning is on my backlog.

[JensenJiang]

Can you @ me in any github issues/PRs you might find on this? I've done some MacPorts work before, and looking into yabai codesigning is on my backlog.

The only ticket I found is https://trac.macports.org/ticket/51504, which is still pending, so it seems that there is currently no support for codesign, which is a bit confusing because some of their pre-built binaries are signed

[Koston-0xDEADBEEF]

Thanks @JensenJiang. I know MacPorts doesn't want to add generic codesign support, because it would partly defeat the purpose of codesigning and undermine its intended use. It can still produce signed binaries, if eg. upstream build includes signing or maintainer of a given port has explicitly added signing.

Apple has been slowly tightening the noose on it, and it's getting to a point where MacPorts need to thoroughly revisit this topic.

[koekeishiya]

The binaries I release (for yabai) are codesigned, and it is what is installed by default when using homebrew, unless the user explicitly opts to install directly by building from the master branch (--HEAD flag). Maybe the portfile should adopt the same strategy.

[Koston-0xDEADBEEF]

MacPorts is a source-based package manager and tightly coupled with building from source. Prebuilt binaries are available (and preferred by default), but never without corresponding Portfile for reproducing the build.

[koekeishiya]

Well the build can be reproduced easily, so that shouldn't be an issue? Every yabai release is tagged alongside its source commit.

e.g:
tag:
https://github.com/koekeishiya/yabai/releases/tag/v6.0.1

prebuilt:
https://github.com/koekeishiya/yabai/releases/download/v6.0.1/yabai-v6.0.1.tar.gz

source:
https://github.com/koekeishiya/yabai/archive/refs/tags/v6.0.1.tar.gz

[Koston-0xDEADBEEF]

If I'm reading the Makefile correctly, sign target signs the binary using signing identity "yabai-sign", which you use for signing releases and which isn't available for users (nor should it be). So, user built binaries are unsigned.

This is a problem for MacPorts to solve, how to handle software which require signing to run on newer macOS versions. But distributing a binary it can't build is a non-starter for any source-based package manager, even if the difference is merely the signature.