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 think we are, again [1], very much in implementation detail territory here. When I add productbuild to the ACL for a key, it ends up using the apple: as the partition ID, but I don’t think behaviour is actually documented anywhere.
Although, weirdly, the security man page specifically lists apple: as appropriate for codesign, so you could reasonably file a bug requesting that we document that it’s appropriate for productbuild as well.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] For those following along at home, fortens-dev has been asking a bunch of questions like this and they’re definitely bumping into the boundaries of what’s considered API. See my reply here for more context.