Add support for more codesign arguments

[matiaskorhonen]

I'm slowly figuring out what I'd need to be able to notarize my CLI tool. To that end I'd like to get support for two more codesign options:

The prefix argument:

--prefix string
    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. If the implicit identifier contains a dot, it is used as-is. Typically,
    this is used to deal with command tools without Info.plists, whose default identifier is simply the command's filename; the conventional prefix used
    is com.domain. (note that the final dot needs to be explicit).

Options flags:

-o, --options flag,...
        During signing, specifies a set of option flags to be embedded in the code signature. The value takes the form of a comma-separated list of names
        (with no spaces). Alternatively, a numeric value can be used to directly specify the option mask (CodeDirectory flag word). See OPTION FLAGS below.

OPTION FLAGS

OPTION FLAGS
     When signing, a set of option flags can be specified to change the behavior of the system when using the signed code. The following flags are recognized by
     codesign; other flags may exist at the API level. Note that you can specify any valid flags by giving a (single) numeric value instead of a list of option
     names.

     kill     Forces the signed code's kill flag to be set when the code begins execution.  Code with the kill flag set will die when it becomes dynamically
              invalid. It is therefore safe to assume that code marked this way, once validated, will have continue to have a valid identity while alive.

     hard     Forces the signed code's hard flag to be set when the code begins execution.  The hard flag is a hint to the system that the code prefers to be
              denied access to resources if gaining such access would invalidate its identity.

     host     Marks the code as capable of hosting guest code. You must set this option if you want the code to act as a code signing host, controlling
              subsidiary ("guest") code. This flag is set automatically if you specify an internal guest requirement.

     expires  Forces any validation of the code to consider expiration of the certificates involved. Code signatures generated with this flag will fail to verify
              once any of the certificates in the chain has expired, regardless of the intentions of the verifier. Note that this flag does not affect any other
              checks that may cause signature validation to fail, including checks for certificate revocation.

     library  Forces the signed code's library validation flag to be set when the code begins execution.  The code will only be able to link against system
              libraries and frameworks, or libraries, frameworks, and plug-in bundles with the same team identifier embedded in the code directory.  Team
              identifiers are automatically recorded in signatures when signing with suitable Apple-issued signing certificates.  Note that the flag is not
              supported for i386 binaries, and only applies to the main executable.  The flag has no effect when set on frameworks and libraries.

     runtime  On macOS versions >= 10.14.0, opts signed processes into a hardened runtime environment which includes runtime code signing enforcement, library
              validation, hard, kill, and debugging restrictions.  These restrictions can be selectively relaxed via entitlements. Note: macOS versions older
              than 10.14.0 ignore the presence of this flag in the code signature.

     linker-signed
              Identifies a signature as signed by the linker. Linker signatures are very similar to adhoc signatures, except:

              •   linker signatures can be replaced without using the --force option.

              •   linker signatures are never preserved regardless of the use of the --preserve-metadata option.

              •   linker signatures will usually not contain any embedded code requirements including a designated requirement.

     Note that code can set the hard and kill flags on itself at any time. The signing options only affect their initial state. Once set by any means, these
     flags cannot be cleared for the lifetime of the code. Therefore, specifying such flags as signing options guarantees that they will be set whenever the
     signed code runs.

     If the code being signed has an Info.plist that contains a key named CSFlags, the value of that key is taken as the default value for the options. The value
     of CSFlags can be a string in the same form as the --options option, or an integer number specifying the absolute numeric value. Note however that while you
     can abbreviate flag names on the command lines, you must spell them out in the Info.plist.

[taiki-e]

Thanks! Could you add these options to the "Inputs" table in readme?

[matiaskorhonen]

I added the options to the README. I didn't reformat the markdown table to avoid causing an unnecessarily large diff…

[taiki-e]

Thanks!

[taiki-e]

Published in 1.22.0.