If docker in the host is configured to use the containerd image format,
then the docker pull/save commands above download the multi-platform
image. IOW, the index.json has references to the other platforms SHAs.
This references to things that are not present (the artifacts for other
platforms) is what make `ctr` fail. However, if we specify a platform,
then ctr ignores the other platforms and the import works just fine.
To try this locally, you can:
$ docker pull ghcr.io/containerd/busybox:1.36
$ docker save ghcr.io/containerd/busybox:1.36 -o image.tar
$ ctr images import --local=true image.tar
The last command will fail if you are using the containerd image store
in docker. If you specify the platform with --platform, it works fine.
With docker overlayfs2 storage driver, if you untar the image you get only
things relevant for your platform:
```
$ cat index.json | jq
{
"schemaVersion": 2,
"mediaType": "application/vnd.oci.image.index.v1+json",
"manifests": [
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"digest": "sha256:4d6b13f2ddbe87da8d9dee3719df1723a6d768e511802e70d42ab15370c6eb24",
"size": 401,
"annotations": {
"io.containerd.image.name": "ghcr.io/containerd/busybox:1.36",
"org.opencontainers.image.ref.name": "1.36"
}
}
]
}
$ cat blobs/sha256/4d6b13f2ddbe87da8d9dee3719df1723a6d768e511802e70d42ab15370c6eb24 | jq
{
"schemaVersion": 2,
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"config": {
"mediaType": "application/vnd.oci.image.config.v1+json",
"digest": "sha256:66ba00ad3de8677a3fa4bc4ea0fc46ebca0f14db46ca365e7f60833068dd0148",
"size": 1457
},
"layers": [
{
"mediaType": "application/vnd.oci.image.layer.v1.tar",
"digest": "sha256:b64792c17e4ad443d16b218afb3a8f5d03ca0f4ec49b11c1a7aebe17f6c3c1d2",
"size": 5096448
}
]
}
```
But with the other you get for lot of other platforms too:
```
$ cat index.json | jq
{
"schemaVersion": 2,
"mediaType": "application/vnd.oci.image.index.v1+json",
"manifests": [
{
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"digest": "sha256:7b3ccabffc97de872a30dfd234fd972a66d247c8cfc69b0550f276481852627c",
"size": 2295,
"annotations": {
"containerd.io/distribution.source.ghcr.io": "containerd/busybox",
"io.containerd.image.name": "ghcr.io/containerd/busybox:1.36",
"org.opencontainers.image.ref.name": "1.36"
}
}
]
}
$ cat blobs/sha256/7b3ccabffc97de872a30dfd234fd972a66d247c8cfc69b0550f276481852627c | jq
{
"manifests": [
{
"digest": "sha256:907ca53d7e2947e849b839b1cd258c98fd3916c60f2e6e70c30edbf741ab6754",
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"platform": {
"architecture": "amd64",
"os": "linux"
},
"size": 528
},
{
"digest": "sha256:dde8e930c7b6a490f728e66292bc9bce42efc9bbb5278bae40e4f30f6e00fe8c",
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"platform": {
"architecture": "arm",
"os": "linux",
"variant": "v5"
},
"size": 528
},
{
...
```
You can switch to the containerd snapshotter in docker by adding this to the daemon.json:
```
{
"features": {
"containerd-snapshotter": true
}
}
```
Signed-off-by: Rodrigo Campos <rodrigo@amutable.com>
This is effectively a revert of 2ac9968401, which
switched from os/exec to the golang.org/x/sys/execabs package to mitigate
security issues (mainly on Windows) with lookups resolving to binaries in the
current directory.
from the go1.19 release notes https://go.dev/doc/go1.19#os-exec-path
> ## PATH lookups
>
> Command and LookPath no longer allow results from a PATH search to be found
> relative to the current directory. This removes a common source of security
> problems but may also break existing programs that depend on using, say,
> exec.Command("prog") to run a binary named prog (or, on Windows, prog.exe) in
> the current directory. See the os/exec package documentation for information
> about how best to update such programs.
>
> On Windows, Command and LookPath now respect the NoDefaultCurrentDirectoryInExePath
> environment variable, making it possible to disable the default implicit search
> of “.” in PATH lookups on Windows systems.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The io/ioutil package has been deprecated as of Go 1.16, see
https://golang.org/doc/go1.16#ioutil. This commit replaces the existing
io/ioutil functions with their new definitions in io and os packages.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
Go 1.15.7 contained a security fix for CVE-2021-3115, which allowed arbitrary
code to be executed at build time when using cgo on Windows. This issue also
affects Unix users who have “.” listed explicitly in their PATH and are running
“go get” outside of a module or with module mode disabled.
This issue is not limited to the go command itself, and can also affect binaries
that use `os.Command`, `os.LookPath`, etc.
From the related blogpost (ttps://blog.golang.org/path-security):
> Are your own programs affected?
>
> If you use exec.LookPath or exec.Command in your own programs, you only need to
> be concerned if you (or your users) run your program in a directory with untrusted
> contents. If so, then a subprocess could be started using an executable from dot
> instead of from a system directory. (Again, using an executable from dot happens
> always on Windows and only with uncommon PATH settings on Unix.)
>
> If you are concerned, then we’ve published the more restricted variant of os/exec
> as golang.org/x/sys/execabs. You can use it in your program by simply replacing
This patch replaces all uses of `os/exec` with `golang.org/x/sys/execabs`. While
some uses of `os/exec` should not be problematic (e.g. part of tests), it is
probably good to be consistent, in case code gets moved around.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Most of the tests creating and using Pod Sandboxes in the same way. We can create
a common function that will do that for us, so we can have less duplicated code,
and make it easier to add new tests in the future.
Signed-off-by: Claudiu Belu <cbelu@cloudbasesolutions.com>
Currently, the cri-integration tests do not work on Windows due to various reasons.
One of the reasons is because all the tests are using Linux-specific images.
Previous commits refactored the image pulling / usage in the cri-integration tests,
making it easier to update, and easier to configure a custom registry to pull images
with Windows support.
For Windows runs, custom registries can be created, which will also contain Windows
images, and the cri-integration tests can be configured to use those registries by
specifying the "--repo-list" argument, a YAML file which will contain an alternative
mapping of the default registries. This is similar to how E2E tests are handled for
Windows runs in Kubernetes.
Some of the tests are Skipped, as they do not pass yet on Windows.
Windows does not collect inodes used stats, thus, the tests that were expecting non-zero
inodes stats were failing.
Signed-off-by: Claudiu Belu <cbelu@cloudbasesolutions.com>
Currently, the cri-integration tests do not work on Windows due to various reasons.
One of the reasons is because all the tests are using Linux-specific images. This
commit refactors the image pulling / usage in the cri-integration tests, making it
easier to update, and easier to configure the a custom registry to pull those images
from.
For Windows runs, custom registries can be created, which will also contain Windows
images, and the cri-integration tests can be configured to use those registries by
specifying the "--image-list" argument, a TOML file which will contain an alternative
mapping of the default images.
Signed-off-by: Claudiu Belu <cbelu@cloudbasesolutions.com>
Sebastiaan van Stijn