codesign
Create and manipulate code signatures
Options
| Name | Description |
|---|---|
--all-architectures | When verifying a code signature on code that has a universal ('fat') Mach-O binary, separately verify each architecture contained. This is the default unless overridden with the -a (--architecture) option |
-a, --architecture <architecture> | When verifying or displaying signatures, explicitly select the Mach-O architecture given |
--bundle-version <version-string> | When handling versioned bundles such as frameworks, explicitly specify the version to operate on |
-d, --display | Display information about the code at the path(s) given |
-D, --detached <file> | When signing, designates that a detached signature should be written to the specified file |
--deep | When signing a bundle, specifies that nested code content such as helpers, frameworks, and plug-ins, should be recursively signed in turn. Beware that all signing options you specify will apply, in turn, to such nested content |
--detached-database | When signing, specifies that a detached signature should be generated as with the --detached option, but that the resulting signature should be written into a system database, from where it is made automatically available whenever apparently unsigned code is validated on the system |
-f, --force | When signing, causes codesign to replace any existing signature on the path(s) given |
-h, --hosting | Constructs and prints the hosting chain of a running program |
-i, --identifier <identifier> | During signing, explicitly specify the unique identifier string that is embedded in code signatures |
-o, --options <version-string> | During signing, specifies a set of option flags to be embedded in the code signature |
-P, --pagesize <size> | Indicates the granularity of code signing. Pagesize must be a power of two |
-r, --requirements <requirements> | During signing, indicates that internal requirements should be embedded in the code path(s) as specified |
-R, --test-requirement <requirement> | During verification, indicates that the path(s) given should be verified against the code requirement specified |
-s, --sign <identity> | Sign the code at the path(s) given using this identity |
-v, --verify | Requests verification of code signatures |
--continue | Instructs codesign to continue processing path arguments even if processing one fails |
--dryrun | During signing, performs almost all signing operations, but does not actually write the result anywhere |
--entitlements <path> | When signing, take the file at the given path and embed its contents in the signature as entitlement data |
--extract-certificates <prefix> | When displaying a signature, extract the certificates in the embedded certificate chain and write them to individual files |
--file-list <file...> | When signing or displaying a signature, codesign writes to the given path a list of files that may have been modified as part of the signing process |
--ignore-resources | During static validation, do not validate the contents of the code's resources |
--keychain <filename> | During signing, only search for the signing identity in the keychain file specified |
--prefix <prefix> | If no explicit unique identifier is specified (using the -i option), and if the implicitly generated identifier does not contain any dot (.) characters, then the given string is prefixed to the identifier before use |
--preserve-metadata=list | When re-signing code that is already signed, reuse some information from the old signature |
--resource-rules <file> | During signing, this option overrides the default rules for identifying and collecting bundle resources and nested code to be sealed into the signature |
--timestamp [URL] | During signing, requests that a timestamp authority server be contacted to authenticate the time of signing |