(This is a very quick attempt at "what this will look like")
This repository provides both command-line utilities, and a module for external
consumers.
Currently, both are part of the same module; as a result, dependencies of both
the module *and* the command-line utilities are listed in the repositories go.mod.
This affects consumers of this project, because (due to go module's nature of
dependency (version) resolution), those consumers will inherit all dependencies,
or will be "forced" to use the same version of the CLI dependencies.
This is a very quick attempt at separating the CLI utilities from the "module",
by creating a separate go.mod (and module) for the CLI utilities.
I'm not fond of the name (github.com/containerd/imgcrypt/cmd) for that module
(possibly renaming to github.com/containerd/imgcrypt/cli would be slightly
clearer).
This change _will_ add some additional work when tagging releases; a separate tag
should be created for the cli utilities (tagging as `cmd/vX.Y.Z`), and the
"github.com/containerd/imgcrypt" dependency in the go.mod inside the cmd directory
may need to be updated to reflect the latest version of the main module when tagging
new releases (as the replace rule is non-transitional); something like:
1. update `github.com/containerd/imgcrypt` version in cmd/go.mod to "next release"
2. tag both `v<new release>` and `cmd/v<new version>` in tandem.
CI / validation also needs to be updated to verify both `go.mod` and `go.sum`
files are correct / up-to-date. Possibly checks should be added to make sure the
main module is isolated from the cmd module (i.e., the "module" should not import
any path from the cmd directory: the reverse is of course OK (and expected)).
Finally; use of the 'vendor' directory may need to be discussed; it is common
to only use a vendor directory for projects that produce binaries, but omit the
vendor directory for "library" projects. In this case (if vendoring is still
desired), the vendor directory should be removed from the root of the repository,
and moved inside the `cmd` directory.
Originally-from: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
The import of an encrypted image requires the decryption key as proof
that one posses one of the decryption keys of the image. However, the
image will not be decrypted as part of the import. The alternative path
that does not require the decryption key is to pull the image from a
repository.
The underlying reason why one needs the key is because containerd sends
an encrypted layer to ctd-decoder which needs the decryption key for the
decryption of that layer and for the import to succeed.
It is not currently clear what the layer represents and why it is part
of an exported image. The layer that is sent for the current alpine
image is the layer with the hash ff7f8bb.. from here:
./blobs/sha256/8a1591...:
{"architecture":"amd64",[...]
{"type":"layers",
"diff_ids":
["sha256:ff7f8bbf1c81b508f82b1c59e8c2467175c0b33e58a79507f4fde8067d6f1897",
"sha256:c32387d564776805eb144718cd41629761e1980280c9d512df358b60f9fe6ba3"]
}
}
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
containerd is migrating off from github.com/gogo/protobuf
(see https://github.com/containerd/containerd/issues/6564).
However imgcrypt depends containerd and containerd also depends
imgcrypt, which makes changing this signature complicated.
This change workarounds the issue by using Go's reflect package.
Signed-off-by: Kazuyoshi Kato <katokazu@amazon.com>
Decouple `CreateCryptoConfig()` from `github.com/urfave/cli`, so that it
can be called from other applications that do not use `github.com/urfave/cli`.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Update to the latest ocicrypt and adjust the code accordingly. Ocicrypt
now gets the user-provided configuration for pkcs11 only if a pkcs11 key
in yaml format is provided. This avoids unnecessary error messages if for
example an image is pulled but doesn't need pkcs11 configuration since
no keys are needed since it doesn't need to be decrypted. Also, the helper
functions ending in 'WithOpts' do not exist anymore and so we roll back some
of the previous changes.
Also, due to the changes, the config file is searched for in this order:
- ${OCICRYPT_CONFIG}="internal": use an internal allow-all policy
- ${OCICRYPT_CONFIG}
- ${XDG_CONFIG_HOME}/ocicrypt.conf
- ${HOME}/.config/ocicrypt.conf
- /etc/ocicrypt.conf
The previously used IMGCRYPT_CONFIG variable is not used anymore.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
While ocicrypt's pkcs11 support is experimental we display a warning when using
pkcs11 keys for encryption.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Extend the parse_helpers with pkcs11 support.
We introduce a configuration file from which pkcs11 parameters are read. A config file
may look like this:
pkcs11:
module-directories:
- /usr/lib64/pkcs11/
allowed-module-paths:
- /usr/lib64/pkcs11/libsofthsm2.so
The module-directories enumerates directories in which to look for pkcs11 modules.
The allowed-module-paths restricts the pkcs11 modules that can be used.
The config file is searched for in this order:
- ${IMGCRYPT_CONF}
- ${XDG_CONFIG_HOME}/imgcrypt.conf
- ${HOME}/.config/imgcrypt.conf
- /etc/imgcrypt.conf
If no config file can be found then an internal default configuration is used.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
ocicrypt has a parse_helpers.go that has similar functions as those in
crypt_utils.go. To resemble ocicrypt's parse_helpers.go move functions
out of crypt_utils.go into our own parse_helpers.go. Ultimately we should
be using ocicrypt's parse_helpers.go and get rid of ours.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
The mediatype we used before was only experimental:
application/vnd.docker.image.rootfs.diff.tar.gzip+enc
The newer one is
application/vnd.oci.image.layer.v1.tar+gzip+enc
Update to latest containerd and adjust code to it.
We need to update the mediatypes being used by GetImageLayerDescriptors,
so we move the function into our own directory.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
dependabot[bot]