Disclosure: this was found and written up by an AI agent (Claude) working with me on my
machine. If you have norms about AI-assisted reports that I've missed, apologies — tell me
and I'll amend or close it. Filing as an issue rather than a PR so you can decide the
right fix; happy to send a DCO-signed PR instead if you'd prefer.
What
krunkit.entitlements has a trailing r on the second key:
<key>com.apple.security.cs.disable-library-validationr</key>
<true/>
The documented key is com.apple.security.cs.disable-library-validation. Since the
codesigning step in the Makefile applies this file verbatim
(codesign --entitlements krunkit.entitlements --force -s - $@), the misspelled key is
carried into the signature but is not a recognised entitlement, so it has no effect.
Verifying on an installed binary
Installed via brew install krunkit (tap slp/krun), krunkit 1.3.2:
$ codesign -d --entitlements - --xml $(which krunkit) | plutil -convert xml1 -o - - | grep key
<key>com.apple.security.cs.disable-library-validationr</key>
<key>com.apple.security.hypervisor</key>
Impact
Low / latent as far as I can tell. com.apple.security.hypervisor is spelled correctly and
works — I verified krunkit boots guests and reclaims memory normally on macOS 26.5.2
(Apple Silicon). Ad-hoc signed binaries don't appear to enforce library validation in a way
that blocks loading libkrun.1.dylib today, which is presumably why this hasn't surfaced.
The concern is only that the protection you intended isn't actually in place, so if signing
ever changes (notarization, Developer ID, hardened runtime), loading the external
libkrun dylib could start failing in a way that looks mysterious.
Suggested fix
Drop the trailing r. If the entitlement turns out not to be needed at all, removing the
key entirely would be equally valid — you're better placed to judge which.
Environment: macOS 26.5.2, Apple Silicon, krunkit 1.3.2, libkrun 1.19.4, installed via
Homebrew tap slp/krun.
Disclosure: this was found and written up by an AI agent (Claude) working with me on my
machine. If you have norms about AI-assisted reports that I've missed, apologies — tell me
and I'll amend or close it. Filing as an issue rather than a PR so you can decide the
right fix; happy to send a DCO-signed PR instead if you'd prefer.
What
krunkit.entitlementshas a trailingron the second key:The documented key is
com.apple.security.cs.disable-library-validation. Since thecodesigning step in the
Makefileapplies this file verbatim(
codesign --entitlements krunkit.entitlements --force -s - $@), the misspelled key iscarried into the signature but is not a recognised entitlement, so it has no effect.
Verifying on an installed binary
Installed via
brew install krunkit(tapslp/krun), krunkit 1.3.2:Impact
Low / latent as far as I can tell.
com.apple.security.hypervisoris spelled correctly andworks — I verified krunkit boots guests and reclaims memory normally on macOS 26.5.2
(Apple Silicon). Ad-hoc signed binaries don't appear to enforce library validation in a way
that blocks loading
libkrun.1.dylibtoday, which is presumably why this hasn't surfaced.The concern is only that the protection you intended isn't actually in place, so if signing
ever changes (notarization, Developer ID, hardened runtime), loading the external
libkrundylib could start failing in a way that looks mysterious.Suggested fix
Drop the trailing
r. If the entitlement turns out not to be needed at all, removing thekey entirely would be equally valid — you're better placed to judge which.
Environment: macOS 26.5.2, Apple Silicon, krunkit 1.3.2, libkrun 1.19.4, installed via
Homebrew tap
slp/krun.