Running "docker nonexistent --version" printed the CLI version and
exited 0, so it couldn't be used to check whether a command or plugin
is available. Without "--version" the same invocation fails with an
"unknown command" error.
When no built-in command or plugin matches, runDocker falls through to
executing the root command, and cobra handles the "--version" flag
before the root command reports the unknown command. Unset the root
command's version in that fallback, so the standard unknown-command
error is returned.
A global "--version" flag ("docker --version nonexistent") is parsed
before the command name and still prints the version, as do
"docker --version" and "docker nonexistent --help".
Signed-off-by: Nimesh Kulkarni <167794819+GitNimay@users.noreply.github.com>
The plugin only used lazyregexp for two small, fixed name patterns.
Replaced it with regexp.MustCompile without changing validation.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Both entry points use NewRootCmd, which adds subcommands directly.
Removed the unused registry registration and constructor.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The plugin only needed progress display and an auxiliary callback.
Inlined that use while preserving cancellation and terminal handling.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Show installation guidance and a documentation link when the offload
plugin is missing or invalid. Handle this before command execution so
plugin-specific flags and --help also receive the guidance.
Signed-off-by: Nicolas Beck <nicolas.beck@docker.com>
Explain how to install the Offload plugin when --cloud cannot find it,
and link to the cloud flag documentation. Preserve diagnostic details
for invalid or incompatible plugins and limit installation guidance
to Offload.
Use standard default-value handling in the resolution tests to satisfy
the lint complexity limit without changing test coverage.
Co-authored-by: Allie Sadler <102604716+aevesdocker@users.noreply.github.com>
Signed-off-by: Nicolas Beck <nicolas.beck@docker.com>
Forward stdin and stderr to cloud context providers when both are
terminals, allowing prompts during --cloud resolution. Pass file handles
directly to preserve terminal detection and leave piped or redirected
input available to the requested command.
Use the standard console handles when Windows terminal wrappers hide
their underlying files. Keep stdout reserved for the JSON response.
Signed-off-by: Nicolas Beck <nicolas.beck@docker.com>
docker --cloud build rejected every BuildKit-only flag (--secret, --ssh,
--push, --output, ...) because cloudHelpRequest parsed remaining args
against the legacy build command's flag set before processAliases
rewrites build into a buildx invocation. Treat build/bake/builder/image
build the same as plugin commands: only recognize --help/-h immediately
after the resolved command path instead of validating flags.
Fixes#7350
Signed-off-by: Nick Sieger <nick@nicksieger.com>
Resolve it through the offload plugin by default, with a provider
override in features.cloud in the Docker config.
Require the selected plugin to declare the cloud-context-resolver
feature in its metadata before showing the flag in help and completion
or invoking its __resolve-context operation.
Resolve through WithContextResolver, after the config file and context
store are loaded but before client initialization, without wrapping or
re-executing Docker.
Forward --context to downstream plugins so they need not support
--cloud or repeat provisioning. Skip provisioning for help, version,
and completion requests. Report unknown flags and missing flag values
before provisioning, so a mistyped invocation fails without creating
cloud resources or contacting the engine selected before resolution.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Inline the sub-slice lookup into stringSliceReplaceAt and use
slices.Equal to compare candidate ranges. When a specific index is
required, check that position directly instead of searching the full
slice.
This also fixes overlapping matches and uses slices.Concat to construct
the replacement result.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Plugin hook output (such as Gordon's "What's next:" hint) was rendered
before the command's own error message because hooks were invoked inside
runDocker while the error was only printed in main() after runDocker
returned.
Print the error to stderr before invoking the hooks, and replace the
error with a status-only StatusError so main() does not print the same
message a second time. The original error message is captured up-front
and still passed to the plugin hooks.
The inline error-printing block in runDocker is extracted into a
printCommandError helper so the new behavior can be unit-tested
directly without spinning up runDocker.
TestPrintCommandError covers each branch of the helper: nil error,
generic error (printed and replaced with StatusError), StatusError
with/without message, context.Canceled (raw and wrapped), and
errCtxSignalTerminated.
Signed-off-by: Mohammed Olabie <olabiedev@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Bumps the go_modules group with 1 update in the /cmd/docker-trust directory: [golang.org/x/crypto](https://github.com/golang/crypto).
Updates `golang.org/x/crypto` from 0.50.0 to 0.52.0
- [Commits](https://github.com/golang/crypto/compare/v0.50.0...v0.52.0)
---
updated-dependencies:
- dependency-name: golang.org/x/crypto
dependency-version: 0.52.0
dependency-type: indirect
dependency-group: go_modules
...
Signed-off-by: dependabot[bot] <support@github.com>
- drop support for go1.24
- update vendor.mod to go1.25.0
- update //go:build tags to go1.25
The golang.org/x/ dependencies now require go1.25 as a minimum,
so updating our build tags accordingly.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When a plugin ignores context cancellation and the user sends 3 SIGINTs,
the CLI kills the plugin with SIGKILL. Previously the signal goroutine
called os.Exit(1) directly; a race existed where plugincmd.Run() could
return first (plugin was SIGKILL'd, so ws.ExitStatus() = -1) and the
main goroutine would call os.Exit(-1) = exit code 255 before the
goroutine reached os.Exit(1).
Fix by moving exit-code ownership to the main goroutine. The signal
goroutine closes forceExitCh before calling Kill(), guaranteeing the
channel is closed before plugincmd.Run() returns (the plugin can only
die after Kill() delivers SIGKILL; Run() only returns after the process
is reaped). The main goroutine checks forceExitCh after Run() returns
and performs the print + os.Exit(1) itself.
Also return from the signal goroutine after the force-kill to prevent
further loop iterations from calling close(forceExitCh) a second time
(which would panic), in case additional signals arrive while the kill
is in flight.
Fixes a flaky failure in TestPluginSocketCommunication/detached/
the_main_CLI_exits_after_3_signals where exit code 255 was observed
instead of 1 on loaded CI runners (RC Docker on Alpine).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Michael Zampani <michael.zampani@docker.com>
Hello gophers,
We have tagged version v0.45.0 of golang.org/x/crypto in order to address two
security issues.
This version fixes a vulnerability in the golang.org/x/crypto/ssh package and a
vulnerability in the golang.org/x/crypto/ssh/agent package which could cause
programs to consume unbounded memory or panic respectively.
SSH servers parsing GSSAPI authentication requests don't validate the number of
mechanisms specified in the request, allowing an attacker to cause unbounded
memory consumption.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-58181 and Go issue https://go.dev/issue/76363.
SSH Agent servers do not validate the size of messages when processing new
identity requests, which may cause the program to panic if the message is
malformed due to an out of bounds read.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-47914 and Go issue https://go.dev/issue/76364.
Cheers, Go Security team
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Create a copy of the registry package to use, so that code used only
for trust can be removed from the cli/internal package.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
move the `trust` subcommands to a plugin, so that the subcommands can
be installed separate from the `docker trust` integration in push/pull
(for situations where trust verification happens on the daemon side).
make binary
go build -o /usr/libexec/docker/cli-plugins/docker-trust ./cmd/docker-trust
docker info
Client:
Version: 28.2.0-dev
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.24.0
Path: /usr/libexec/docker/cli-plugins/docker-buildx
trust: Manage trust on Docker images (Docker Inc.)
Version: unknown-version
Path: /usr/libexec/docker/cli-plugins/docker-trust
docker trust --help
Usage: docker trust [OPTIONS] COMMAND
Extended build capabilities with BuildKit
Options:
-D, --debug Enable debug logging
Management Commands:
key Manage keys for signing Docker images
signer Manage entities who can sign Docker images
Commands:
inspect Return low-level information about keys and signatures
revoke Remove trust for an image
sign Sign an image
Run 'docker trust COMMAND --help' for more information on a command.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Various dependencies, including "golang.org/x/.." started to update
the minimum required version,so we should follow suit for the next
release.
Note that the `//go:build` directives not necesserily have to be
updated, but it's good to keep them in sync until we have a go.mod
to control this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Some tests had to be skipped as there's some issues to address, and
some of the result-types cannot be mocked / stubbed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
On Docker CLI versions before v28.0.0, using an unknown flag would print
the usage output, showing all available top-level flags and commands;
docker --badopt
unknown flag: --badopt
See 'docker --help'.
Usage: docker [OPTIONS] COMMAND
A self-sufficient runtime for containers
Options:
--config string Location of client config files (default "/root/.docker")
...
This output did not include plugin-commands, making the usage output
incomplete. That issue was fixed in [cli@40a6cf7], which loaded all
available cli-plugins, so that a stub was created for printing the
plugin commands in the usage output. Similarly, [cli@79a75da] added
code to hide experimental commands and commands not supported by the
daemon.
However, since 28.0.0 (commit [cli@f28fc7f]), the usage output was
removed for this error, so loading plugins is no longer needed;
docker --badopt
unknown flag: --badopt
Usage: docker [OPTIONS] COMMAND [ARG...]
Run 'docker --help' for more information
This patch removes the code added in [cli@40a6cf7] and [cli@79a75da].
With this patch, the output is still the same;
docker --unknown-flag buildx ls --no-such
unknown flag: --unknown-flag
Usage: docker [OPTIONS] COMMAND [ARG...]
Run 'docker --help' for more information
This function only handles flags defined by the CLI itself; invalid
flags for plugins are handled by the plugin itself, so are not
impacted;
docker buildx ls --no-such
unknown flag: --no-such
Usage: docker buildx ls
Run 'docker buildx ls --help' for more information
[cli@f28fc7f]: https://github.com/docker/cli/commit/f28fc7f82fc87d0ed521de452b6227cee76fd956
[cli@40a6cf7]: https://github.com/docker/cli/commit/40a6cf7c477cf328134b0b8dcdbd9a09d02f918b
[cli@79a75da]: https://github.com/docker/cli/commit/79a75da0fd97b02311676028c3406b242c785f7c
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Paweł Gronowski
Nimesh Kulkarni
Nicolas Beck
Sebastiaan van Stijn
Nick Sieger
Sebastiaan van Stijn
Mohammed Olabie
dependabot[bot]
Michael ZampaniandClaude Sonnet 4.6
Derek Misler