ocm sign componentversions [<options>] {<component-reference>}
componentversions, componentversion, cv, components, component, comps, comp, c
-S, --algorithm string signature handler (default "RSASSA-PKCS1-V1_5")
--ca-cert stringArray additional root certificate authorities (for signing certificates)
-c, --constraints constraints version constraint
-H, --hash string hash algorithm (default "SHA-256")
-h, --help help for componentversions
-I, --issuer stringArray issuer name or distinguished name (DN) (optionally for dedicated signature) ([<name>:=]<dn>
--keyless use keyless signing
--latest restrict component versions to latest
--lookup stringArray repository name or spec for closure lookup fallback
-N, --normalization string normalization algorithm (default "jsonNormalisation/v1")
-K, --private-key stringArray private key setting
-k, --public-key stringArray public key setting
-R, --recursive recursively sign component versions
--repo string repository name or spec
-s, --signature stringArray signature name
--tsa use timestamp authority (default server: http://timestamp.digicert.com)
--tsa-url string TSA server URL
--update update digest in component versions (default true)
-V, --verify verify existing digests (default true)
Sign specified component versions.
If the option --constraints
is given, and no version is specified
for a component, only versions matching the given version constraints
(semver https://github.com/Masterminds/semver) are selected.
With --latest
only
the latest matching versions will be selected.
If the --repo
option is specified, the given names are interpreted
relative to the specified repository using the syntax
<component>[:<version>]
If no --repo
option is specified the given names are interpreted
as located OCM component version references:
[<repo type>::]<host>[:<port>][/<base path>]//<component>[:<version>]
Additionally there is a variant to denote common transport archives and general repository specifications
[<repo type>::]<filepath>|<spec json>[//<component>[:<version>]]
The --repo
option takes an OCM repository specification:
[<repo type>::]<configured name>|<file path>|<spec json>
For the Common Transport Format the types directory
,
tar
or tgz
is possible.
Using the JSON variant any repository types supported by the linked library can be used:
Dedicated OCM repository types:
ComponentArchive
: v1
OCI Repository types (using standard component repository to OCI mapping):
CommonTransportFormat
: v1OCIRegistry
: v1oci
: v1ociRegistry
The --public-key
and --private-key
options can be
used to define public and private keys on the command line. The options have an
argument of the form [<name>=]<filepath>
. The optional name
specifies the signature name the key should be used for. By default, this is the
signature name specified with the option --signature
.
Alternatively a key can be specified as base64 encoded string if the argument
start with the prefix !
or as direct string with the prefix
=
.
If in signing mode a public key is specified, existing signatures for the given signature name will be verified, instead of recreated.
The following signing types are supported with option --algorithm
:
RSASSA-PKCS1-V1_5
(default)RSASSA-PSS
rsa-signingservice
rsapss-signingservice
sigstore
The following normalization modes are supported with option --normalization
:
jsonNormalisation/v1
(default)jsonNormalisation/v2
The following hash modes are supported with option --hash
:
NO-DIGEST
SHA-256
(default)SHA-512
If a component lookup for building a reference closure is required
the --lookup
option can be used to specify a fallback
lookup repository. By default, the component versions are searched in
the repository holding the component version for which the closure is
determined. For Component Archives this is never possible, because
it only contains a single component version. Therefore, in this scenario
this option must always be specified to be able to follow component
references.
$ ocm sign componentversion --signature mandelsoft --private-key=mandelsoft.key ghcr.io/mandelsoft/kubelink