I have a narrow follow-up question about file-based Keychain partition lists, this time specifically for Developer ID Installer signing with productbuild. I’ve reviewed the existing guidance around Keychain ACLs and partition lists. For codesign, the security documentation explicitly calls out the apple: partition requirement. I haven’t been able to find an equivalent supported statement for productbuild. My setup uses separate private keys for the two roles: Developer ID Application → /usr/bin/codesign Developer ID Installer → /usr/bin/productbuild The trusted-application ACL is also role-specific. I’m trying to determine the corresponding partition constraint for the Installer key without inferring it from a configuration that merely happens to work. So my question is: When /usr/bin/productbuild uses a Developer ID Installer private key from a file-based Keychain, what partition-list requirement should that key use according to the supported macOS contract? In particular, should the Installer key use apple:, apple-tool:, some combination of partitions, or something else? I’m not looking for a broad CI workaround or an “Allow all applications” configuration. I’m trying to keep the Application and Installer roles separate and use only the partition constraint actually required by the Apple signing tool. If there is no documented/supported partition value for productbuild, knowing that limitation would also answer the question. Thanks.

I’m evaluating whether Apple cloud signing can replace locally managed Developer ID private keys in a macOS distribution pipeline. I’ve read the documentation on cloud-managed certificates and the Xcode cloud-signing workflow. I understand the supported Developer ID Application flow through Xcode’s archive/export distribution process, but I haven’t been able to find an equivalent documented workflow for Developer ID Installer. I’m also checking this against the current Xcode 27 / macOS 27 toolchain, in case the supported cloud-signing scope has recently expanded. My distribution pipeline produces custom flat installer packages using productbuild. It uses separate Developer ID Application and Developer ID Installer identities, as expected. So my main question is: Can a custom macOS .pkg be signed with a cloud-managed Developer ID Installer identity using a currently supported Apple workflow? More specifically, is there a supported cloud-signing equivalent of using a local Developer ID Installer identity with productbuild / productsign, or are Developer ID Installer package signatures still expected to use a locally or externally available signing identity? I’m specifically asking about custom Developer ID packages distributed outside the Mac App Store, rather than an App Store or Xcode-managed installer workflow. If cloud-managed Developer ID Installer signing isn’t currently supported, knowing that limitation would answer my question as well. Thanks.

I have a follow-up question about file-based Keychain ACLs, this time specifically about inspecting the authorization state after it has been configured. I’ve been looking through the public SecAccess / SecACL / SecTrustedApplication APIs. I can enumerate ACL entries and their authorizations, and SecACLCopyContents gives me the trusted applications associated with an ACL. What I haven’t been able to establish is whether the complete stored caller-matching condition can be read back through a supported API. In particular, SecTrustedApplicationCopyData returns opaque application-identifying data. Is that data intended to be a complete representation of the condition that the Keychain will use to recognize that trusted application? Or can the stored trusted-application condition contain additional code-signing requirements or other matching constraints that are not represented by SecTrustedApplicationCopyData? My higher-level requirement is to verify, after configuring a private key, that its effective authorization scope is no broader than an independently reviewed policy. Ideally I would like to compare: the authorized private-key operations; all trusted-application subjects and their complete matching conditions; prompt-related state; and partition-list constraints. Is there a public and supported API, or an Apple-provided tool with a supported machine-readable contract, that can enumerate the complete effective authorization state of a private key in a file-based Keychain? I’m deliberately not trying to infer this from the current executable’s path, designated requirement, hash, security dump-keychain output, or representative negative tests unless Apple considers one of those to be the supported way to establish the stored authorization state. I realise from the existing guidance, including TN3137 and the discussion around file-based Keychains, that this is legacy technology. If complete supported introspection simply isn’t available for this model, knowing that limitation would also answer my question. Thanks.

I’m trying to clarify the supported authorization semantics for a private key in a file-based Keychain. I’ve read the existing Apple guidance around SecAccess / trusted applications and the commonly documented codesign setup that combines a trusted-application ACL with an apple: partition list. I think I understand those pieces individually, but I haven’t been able to find a public contract for how they compose when both are present. My case has three legitimate users of the same private key: a project-owned, reviewed helper that performs a bounded private-key challenge; /usr/bin/codesign; /usr/bin/productbuild. I want to grant no broader access than those callers and their required signing operations, and I don’t want to infer authorization semantics merely because a particular configuration happens to work on one macOS release. So my main question is: When a private-key ACL contains both trusted-application restrictions and a partition list, are these independent conditions that must both be satisfied by the calling process? In particular, suppose the trusted-application ACL explicitly contains my non-Apple helper, while the partition list contains only apple:. Is the helper expected to be denied because it does not satisfy the partition condition, despite being explicitly trusted by the ACL? If so, is there a supported partition configuration for a key that must be usable by both a specifically trusted non-Apple helper and Apple signing tools such as codesign / productbuild, without broadening access to an application class? I’m specifically looking for the supported contract here. A successful experiment would be useful qualification evidence later, but I don’t want to use that experiment to infer undocumented authorization semantics. Thanks.

I’m designing a least-privilege system LaunchDaemon registered with SMAppService, and I’d like to clarify whether the following architecture is supported by public macOS contracts. The LaunchDaemon declares a MachServices entry. Its steady-state service must run as a dedicated non-root account and later creates an NSXPCListener for that Mach service. We currently launch the daemon directly using UserName, GroupName, and InitGroups=false. However, InitGroups=false does not appear to guarantee that the resulting process supplementary-group list is limited to the service’s intended group. In testing, the daemon received a supplementary group outside our accepted set. We therefore do not want to depend on incidental inherited launch-time group state. We are considering this alternative: launchd starts a small, fixed, code-signed bootstrap executable as root. The bootstrap reads the target UID/GID from an existing protected root-owned binding record. It establishes an exact credential state using public BSD APIs, conceptually: setgroups(...) setgid(...) setuid(...) It verifies the resulting non-root credentials. It creates no XPC listener or storage connection while privileged. Without forking, it permanently replaces itself using execve() (or possibly POSIX_SPAWN_SETEXEC) with another fixed, separately signed executable in the same bundle. That non-root executable independently validates its security state and then creates NSXPCListener(machServiceName:) for the Mach service declared by the original LaunchDaemon job. The bootstrap would not remain as a privileged parent or supervisor. My main questions are: Is a same-PID exec after permanent UID/GID/supplementary-group reduction supported for an SMAppService system LaunchDaemon before it checks in to its declared Mach service? Does the exec-replaced process retain the launchd/bootstrap context required for NSXPCListener(machServiceName:) to check in to that Mach service? If so, what execution context must be preserved across exec (for example bootstrap context, environment, file descriptors, or Mach rights)? Is there a documented way to preserve only the context required for the LaunchDaemon/Mach-service relationship without carrying unintended root-derived capabilities into the non-root executable? Would SMAppService.unregister() / normal launchd termination continue to treat the exec-replaced process as the same LaunchDaemon job? If this topology is not supported, is there an Apple-supported way to establish an exact supplementary-group set before a non-root SMAppService LaunchDaemon begins handling its Mach service? The goal is to avoid relying on undocumented launchd behavior, incidental supplementary groups, private APIs, or a long-lived privileged helper. I’m specifically looking for the supported contract here rather than whether this happens to work on a particular macOS release.