Feature or enhancement request details
When I ran container system start for the first time, container asked me if I want to download the kernel https://github.com/kata-containers/kata-containers/releases/download/3.28.0/kata-static-3.28.0-arm64.tar.zst. I suppose I do want to do that. But, I would also like some reassurance that the downloaded file kata-static-3.28.0-arm64.tar.zst hasn't been tampered with. Reading the source code, there isn't any sha256 hash or other integrity mechanism used to ensure this. Instead, we're relying on HTTPS security, GitHub's mechanisms to ensure integrity of downloads, and the GitHub & maintainers of the kata-containers project to ensure that the 3.28.0 release artifacts aren't updated (maliciously).
Especially for the default kernel, a high level of assurance of the integrity of what is being used is warranted.
Here is how I did this manually (modulo error handling):
$ mkdir kernels
$ curl --proto '=https' --tlsv1.2 -sSf --location --output-dir kernels -O https://github.com/kata-containers/kata-containers/releases/download/3.28.0/kata-static-3.28.0-arm64.tar.zst
$ echo "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 kernels/kata-static-3.28.0-arm64.tar.zst" > kernels/hashes
$ shasum --algorithm 256 --check kernels/hashes
$ container system kernel set --binary opt/kata/share/kata-containers/vmlinux.container --tar $PWD/kernels/kata-static-3.28.0-arm64.tar.zst
I noticed that the tool seems to allow URLs wherever paths are accepted for kernels, and the ability to indicate the expected file contents' digest when supplying a URL on any command line or in any configuration file would be best. IMO this is less urgent than dealing with the default. For example, it looks like container system kernel set accepts a URL, in which case it should also accept a digest to use to verify integrity.
Code of Conduct
Feature or enhancement request details
When I ran
container system startfor the first time,containerasked me if I want to download the kernel https://github.com/kata-containers/kata-containers/releases/download/3.28.0/kata-static-3.28.0-arm64.tar.zst. I suppose I do want to do that. But, I would also like some reassurance that the downloaded filekata-static-3.28.0-arm64.tar.zsthasn't been tampered with. Reading the source code, there isn't any sha256 hash or other integrity mechanism used to ensure this. Instead, we're relying on HTTPS security, GitHub's mechanisms to ensure integrity of downloads, and the GitHub & maintainers of the kata-containers project to ensure that the 3.28.0 release artifacts aren't updated (maliciously).Especially for the default kernel, a high level of assurance of the integrity of what is being used is warranted.
Here is how I did this manually (modulo error handling):
I noticed that the tool seems to allow URLs wherever paths are accepted for kernels, and the ability to indicate the expected file contents' digest when supplying a URL on any command line or in any configuration file would be best. IMO this is less urgent than dealing with the default. For example, it looks like
container system kernel setaccepts a URL, in which case it should also accept a digest to use to verify integrity.Code of Conduct