<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <!--
      Required to create and run VMs in-process via Apple's Virtualization framework — both the
      Linux guests behind the container sandbox (via the containerization framework) AND the macOS
      guests behind the `mac_vm_exec` tool (VZMacOSInstaller / VZVirtualMachine — see
      docs/MACOS_VM.md). This single entitlement covers macOS guests too; there is no separate
      install/guest entitlement. Without it, VZVirtualMachine.start() fails. It is NOT a restricted
      entitlement, so distribution needs no special Apple approval and no provisioning profile — a
      Developer ID certificate + notarization is sufficient. Ad-hoc signing with this entitlement is
      also honored for local development on Apple silicon. (The restricted entitlement we deliberately
      avoid, for both Linux and macOS guests, is `com.apple.vm.networking` — NAT networking needs it
      not, and under an ad-hoc signature it gets the binary killed at launch.)
    -->
    <key>com.apple.security.virtualization</key>
    <true/>

    <!--
      NO keychain-access-groups here — deliberately. Do not re-add it without an embedded
      provisioning profile (see below), or Developer ID launches will die at spawn.

      A team-prefixed keychain-access-groups (L7UDTQ6F5W.xyz.blakeslee.nucleic) is an
      AUTHORIZATION-REQUIRED entitlement — unlike com.apple.security.virtualization above. AMFI
      grants it only when an embedded Developer ID provisioning profile authorizes it; a matching
      Team ID on the signing cert is NOT enough. This bundle ships no provisioning profile, so
      declaring the group made AMFI refuse to spawn the notarized app ("Launchd job spawn failed",
      NSPOSIXErrorDomain 163 / SIGKILL at exec) even though the codesign verify pass, notarization,
      and stapling all passed — codesign's verify is a static check and does not catch this. This
      shipped in canary build 848 (0.3.4) and broke launch; removing the key restored it.

      Losing the group is safe: KeychainOwnedAccess already handles its absence. SecItemAdd against
      the data-protection Keychain returns errSecMissingEntitlement and the caller falls back to the
      login Keychain with an app-owned ACL — the same path ad-hoc/local builds take. To restore
      silent, no-prompt data-protection Keychain access, register the App ID(s) with the Keychain
      Sharing capability + this group in the Developer portal, create a Developer ID provisioning
      profile, embed it at Contents/embedded.provisionprofile (in scripts/package-app.sh, before
      signing), and only then re-add the keychain-access-groups key here.
    -->
</dict>
</plist>
