The runtime directory is needed a few times during the course of
commonly used Toolbx commands. It's used at start-up for all commands
except 'completion' and 'init-container' to synchronize the invocation
of 'podman system migrate'. The entry point (ie., 'init-container')
uses it to read the generated Container Device Interface specification
and create the initialization stamp file. The 'enter' and 'run'
commands use it to write the CDI specification and twice to detect the
creation of the initialization stamp file.
Since the runtime directory is always the same within a process, there's
no need to repeatedly go through all the steps of parsing the user and
group IDs, creating the directory, setting its ownership, and logging
the name of directory. Once the directory is successfully created, it's
path can be cached and returned for subsequent use.
In case an error occurred while setting up the runtime directory,
subsequent attempts to get it will go through all the steps again. This
doesn't matter much in practice because toolbox(1) can't continue in the
absence of a working runtime directory.
https://github.com/containers/toolbox/pull/1624
... for CVE-2024-0135 or GHSA-9v84-cc9j-pxr6, CVE-2024-0136 or
GHSA-vcfp-63cx-4h59, and CVE-2024-0137 or GHSA-frhw-w3wm-6cw4.
The src/go.sum file was updated with 'go mod tidy'.
https://github.com/containers/toolbox/pull/1614
The indirect dependencies in the src/go.mod file, and the src/go.sum
file were updated with 'go mod tidy'.
The src/go.sum file was skipped from the codespell test because it's
generated with 'go mod tidy'. Otherwise codespell would complain:
: github.com/spf13/viper v1.15.0
h1:js3yy885G8xwJa6iOISGFwd+qlUo5AvyXb7CiihdtiU=
> github.com/spf13/viper v1.15.0/go.mod
h1:fFcTBJxvhhzSJiZy8n+PeW6t8l+KeT/uTARa0jHOQLA=
: github.com/stretchr/objx v0.1.0/go.mod
h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
./src/go.sum:384: KeT ==> key, kept
https://github.com/containers/toolbox/pull/1612
Currently, the CI is failing because 'go mod download' is encountering an
expired TLS certificate:
$ go mod download
go: github.com/spf13/viper@v1.10.1 requires
go.opencensus.io@v0.23.0: unrecognized import path "go.opencensus.io":
https fetch: Get "https://go.opencensus.io/?go-get=1": tls: failed to
verify certificate: x509: certificate has expired or is not yet valid:
current time 2025-01-23T17:00:16+01:00 is after 2025-01-21T03:43:04Z
Therefore, disable the TLS certificate check until the certificate gets
updated or the dependency gets removed [1].
[1] https://pkg.go.dev/cmd/go#hdr-Environment_variableshttps://github.com/containers/toolbox/pull/1611
The system tests can be very I/O intensive, because many of them copy
OCI images from the test suite's image cache directory to its local
container/storage store, create containers, and then delete everything
to run the next test with a clean slate. This makes them slow.
In the case of these two particular tests, toolbox(1) is supposed to
validate the command line options before trying to find the image. So,
there's no need to copy the image from the test suite's image cache
directory to its local container/storage store.
If the toolbox(1) code breaks, then either it won't throw the expected
error or it will download the image before validating the command line
options. The first possibility will be easily detected. The other
could have been harder to notice, but, fortunately, commit
55c0e63786 added variants of these tests without the --assumeyes
option and there are other tests to ensure that images cannot be
downloaded without that option. So, any unexpected attempts to download
the image will be caught by those variants of these tests.
Fallout from 32b147b9ffhttps://github.com/containers/toolbox/pull/1595
It shouldn't be necessary to use the --assumeyes option when creating a
Toolbx container, if the corresponding image is already present in the
local containers/storage image store. It's harmful to test it with the
option, even when it shouldn't be needed, because it's off by default
and most users won't enable it.
Therefore, it's better to test the most common scenario that most users
will encounter.
https://github.com/containers/toolbox/pull/1595
The toolbox(1) binary always relies on the PATH environment variable to
find the podman(1) and skopeo(1) binaries. There's no way to override
those with the PODMAN and SKOPEO environment variables, and they only
affect any direct use of podman(1) and skopeo(1) within the test suite.
Therefore, offering the PODMAN and SKOPEO environment variables in their
current form is needlessly confusing and misleading, and can lead to
surprises arising from different podman(1) and skopeo(1) binaries being
used in different places. Either toolbox(1) should also honour them or
the test suite shouldn't offer them. The former is more complicated
without any obvious need for it, so the latter was chosen.
https://github.com/containers/toolbox/pull/1592
Debarshi Ray
Penn Bauman