The Docker CLI supports storing/managing credentials without a
credential-helper, in which case credentials are fetched from/saved to
the CLI config file (`~/.docker/config.json`). This is all managed
entirely by the CLI itself, without resort to a separate binary.
There are a few issues with this approach – for one, saving the
credentials together with all the configurations make it impossible to
share one without the other, so one can't for example bind mount the
config file into a container without also including all configured
credentials.
Another issue is that this has made it so that any other clients
accessing registry credentials (such as
https://github.com/google/go-containerregistry) all have to both:
- read/parse the CLI `config.json`, to check for credentials there,
which also means they're dependent on this type and might break if the
type changes/we need to be careful not to break other codebases parsing
this file, and can't change the location where plaintext credentials
are stored.
- support the credential helper protocol, so that they can access
credentials when users do have configured credential helpers.
This means that if we want to do something like support oauth
credentials by having credential-helpers refresh oauth tokens before
returning them, we have to both implement that in each credential-helper
and in the CLI itself, and any client directly reading `config.json`
will also need to implement this logic.
This commit turns the Docker CLI binary into a multicall binary, acting
as a standalone credentials helper when invoked as
`docker-credential-file`, while still storing/fetching credentials from
the configuration file (`~/.docker/config.json`), and without any
further changes.
This represents a first step into aligning the "no credhelper"/plaintext
flow with the "credhelper" flow, meaning that instead of this being an
exception where credentials must be read directly from the config file,
credentials can now be accessed in the exact same way as with other
credential helpers – by invoking `docker-credential-[credhelper name]`,
such as `docker-credential-pass`, `docker-credential-osxkeychain` or
`docker-credential-wincred`.
This would also make it possible for any other clients accessing
credentials to untangle themselves from things like the location of the
credentials, parsing credentials from `config.json`, etc. and instead
simply support the credential-helper protocol, and call the
`docker-credential-file` binary as they do others.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit implements a validation
method for the port mappings.
Also, it removes the ports validation
method from the expose property
since they do not accept the
same type of values.
Signed-off-by: Stavros Panakakis <stavrospanakakis@gmail.com>
When running tests from my IDE, it compiles the tests before running,
then executes the compiled binary to run the tests. Cobra doesn't like that,
because in that situation os.Args is taken as argument for the command that's
executed. The command that's tested now sees the `test-` flags as arguments
(`-test.v -test.run ..`), which causes various tests to fail ("Command XYZ
does not accept arguments").
# compile the tests:
go test -c -o foo.test
# execute the test:
./foo.test -test.v -test.run TestFoo
=== RUN TestFoo
Error: "foo" accepts no arguments.
Set arguments to an empty slice to make sure it doesn't inherit arguments
from the test-binary.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This test was added in [moby@b2551c6] as part of a larger PR that implemented
unit tests in various packages. In this specific test, it looks like the
`imageSaveFunc` that's defined in the test-table was forgotten to be wired
up, causing all tests to effectively be skipped.
This patch wires up the function so that it's used in the test.
[moby@b2551c6]: b2551c619d
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
With this patch, completion is provided for `--platform` flags:
docker pull --platform<TAB>
linux linux/amd64 linux/arm/v5 linux/arm/v7 linux/arm64/v8 linux/riscv64 wasip1 windows
linux/386 linux/arm linux/arm/v6 linux/arm64 linux/ppc64le linux/s390x wasip1/wasm windows/amd64
Note that `docker buildx build` (with BuildKit) does not yet provide completion;
it's provided through buildx, and uses a different format (accepting multiple
comma-separated platforms). Interestingly, tab-completion for `docker build`
currently uses completion for non-buildkit, and has some other issues that may
have to be looked into.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
With this patch, completion is provided for `--platform` flags:
docker run --platform<TAB>
linux linux/amd64 linux/arm/v5 linux/arm/v7 linux/arm64/v8 linux/riscv64 wasip1 windows
linux/386 linux/arm linux/arm/v6 linux/arm64 linux/ppc64le linux/s390x wasip1/wasm windows/amd64
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add a utility for completing platform strings.
Platforms offers completion for platform-strings. It provides a non-exhaustive
list of platforms to be used for completion. Platform-strings are based on
[runtime.GOOS] and [runtime.GOARCH], but with (optional) variants added. A
list of recognised os/arch combinations from the Go runtime can be obtained
through "go tool dist list".
Some noteworthy exclusions from this list:
- arm64 images ("windows/arm64", "windows/arm64/v8") do not yet exist for windows.
- we don't (yet) include `os-variant` for completion (as can be used for Windows images)
- we don't (yet) include platforms for which we don't build binaries, such as
BSD platforms (freebsd, netbsd, openbsd), android, macOS (darwin).
- we currently exclude architectures that may have unofficial builds,
but don't have wide adoption (and no support), such as loong64, mipsXXX,
ppc64 (non-le) to prevent confusion.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit adds tests for the commands
docker kill, docker commit, and docker
pause. Also, it creates the mock methods
of the docker client ContainerCommit and
ContainerPause so they can
be used in the tests.
For docker kill, it covers the
cases that:
- the command runs successfully
- the client returns an error
For docker commit, it covers
the cases that:
- the command runs successfully
- the client returns an error
For docker pause, it covers
the cases that:
- the command runs successfully
- the client returns an error
Signed-off-by: Stavros Panakakis <stavrospanakakis@gmail.com>
Laura Brehm
Sebastiaan van Stijn
Sebastiaan van Stijn
Harald Albers
Paweł Gronowski
Stavros Panakakis
David Karlsson
Paul Rogalski
Austin Vazquez