Command: verify componentversions
On this page
Usage
ocm verify componentversions [<options>] {<component-reference>}
Options
--ca-cert stringArray Additional root certificates
-c, --constraints constraints version constraint
-h, --help help for componentversions
--latest restrict component versions to latest
-L, --local verification based on information found in component versions, only
--lookup stringArray repository name or spec for closure lookup fallback
-k, --public-key stringArray public key setting
--repo string repository name or spec
-s, --signature stringArray signature name
-V, --verify verify existing digests
Description
Verify signature of 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 type supported by the linked library can be used:
Dedicated OCM repository types:
ComponentArchive
OCI Repository types (using standard component repository to OCI mapping):
ArtifactSet
CommonTransportFormat
DockerDaemon
Empty
OCIRegistry
oci
ociRegistry
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 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.
Examples
$ ocm verify componentversion --signature mandelsoft --public-key=mandelsoft.key ghcr.io/mandelsoft/kubelink
See Also
- ocm verify — Verify component version signatures