This code is using a `bytes.Buffer` to render the stats, before writing
the results to the CLI's output. Let's try to use bytes where possible
instead of converting to a string;
- Use the buffer's `Write` (and `Out().Write`) to write directly to the
buffer/writer where possible.
- Use `io.WriteString` instead of `fmt.Printf`
- Use `bytes.SplitSeq` instead of `strings.SplitSeq`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Don't write lines back into the same buffer that's being read from when
clearing lines; add a separate output buffer to construct the output,
then write it to the CLI's output at once (to prevent terminal flicker).
Relates to / introduced in cb2f95ceee.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Update the GoDoc to better align with the actual implementation. The
"idOrName" is used for fuzzy-matching the container, which can result
in multiple stats for the same container:
docker ps --format 'table {{.ID}}\t{{.Names}}'
CONTAINER ID NAMES
b49e6c21d12e quizzical_maxwell
docker stats --no-stream quizzical_maxwell b49e6c21d12e b49e6
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
b49e6c21d12e quizzical_maxwell 0.10% 140.8MiB / 7.653GiB 1.80% 3.11MB / 13.4kB 115MB / 1.12MB 28
b49e6c21d12e quizzical_maxwell 0.10% 140.8MiB / 7.653GiB 1.80% 3.11MB / 13.4kB 115MB / 1.12MB 28
b49e6c21d12e quizzical_maxwell 0.10% 140.8MiB / 7.653GiB 1.80% 3.11MB / 13.4kB 115MB / 1.12MB 28
We should resolve the canonical ID once, then use that as reference
to prevent duplicates. Various parts in the code compare Container
against "ID" only (not considering "name" or "ID-prefix").
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `Context.preFormat` method normalizes the Format as given by the user,
and handles (e.g.) stripping the "table" prefix and replacing the "json"
format for the actual format (`{{json .}}`).
The method used a `finalFormat` field on the Context as intermediate,
and was required to be called before executing the format.
This patch adds a `Format.templateString()` method that returns the
parsed format instead of storing it on the Context. It is currently
not exported, but something we could consider in future.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
A tabwriter is backed by a buffer already, because it needs to re-flow columns
based on content written to it. This buffer was added in [moby@ea61dac9e6] as
part of a new feature to allow for custom delimiters; neither the patch, nor
code-review on the PR mention the extra buffer, so it likely was just overlooked.
This patch;
- removes the redundant buffer
- adds an early return for cases where no tabwriter is used.
[moby@ea61dac9e6]: https://github.com/moby/moby/commit/ea61dac9e6d04879445f9c34729055ac1bb15050
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Optimize formatting of container name(s);
- Inline `StripNamePrefix` in the loop, so that we don't have to
construct a new slice with names (in most cases only to pick
the first one).
- Don't use `strings.Split`, as it allocates a new slice and we only
used it to check if the container-name was a legacy-link (contained
slashes).
- Use a string-builder to concatenate names when not truncating instead
of using an intermediate slice (and `strings.Join`).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function is very specific to attaching to containers, and probably
helps clarity to inline it where used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When completing for commands that accept multiple arguments, we did
not remove suggestions that were already consumed. This could be
confusing if there was only 1 suggestion, in which case every `<tab>`
would automatically suggest the same name again:
docker rm -fv magical_lumiere magical_lumiere magical_lumiere
This patch adds a "Unique" helper to wrap a completion func to remove
completion results that are already consumed (i.e., appear in "args").
For example:
# initial completion: args is empty, so all results are shown
command <tab>
one two three
# "one" is already used so omitted
command one <tab>
two three
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- 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>
This package imports all "importable" packages, i.e., packages that:
- are not applications ("main")
- are not internal
- and that have non-test go-files
We do this to verify that our code can be consumed as a dependency
in "module mode". When using a dependency that does not have a go.mod
(i.e.; is not a "module"), go implicitly generates a go.mod. Lacking
information from the dependency itself, it assumes "go1.16" language
(see [DefaultGoModVersion]). Starting with Go1.21, go downgrades the
language version used for such dependencies, which means that any
language feature used that is not supported by go1.16 results in a
compile error;
# github.com/docker/cli/cli/context/store
/go/pkg/mod/github.com/docker/cli@v25.0.0-beta.2+incompatible/cli/context/store/storeconfig.go:6:24: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
/go/pkg/mod/github.com/docker/cli@v25.0.0-beta.2+incompatible/cli/context/store/store.go:74:12: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
These errors do NOT occur when using GOPATH mode, nor do they occur
when using "pseudo module mode" (the "-mod=mod -modfile=vendor.mod"
approach used in this repository).
As a workaround for this situation, we must include "//go:build" comments
in any file that uses newer go-language features (such as the "any" type
or the "min()", "max()" builtins).
From the go toolchain docs (https://go.dev/doc/toolchain):
> The go line for each module sets the language version the compiler enforces
> when compiling packages in that module. The language version can be changed
> on a per-file basis by using a build constraint.
>
> For example, a module containing code that uses the Go 1.21 language version
> should have a go.mod file with a go line such as go 1.21 or go 1.21.3.
> If a specific source file should be compiled only when using a newer Go
> toolchain, adding //go:build go1.22 to that source file both ensures that
> only Go 1.22 and newer toolchains will compile the file and also changes
> the language version in that file to Go 1.22.
This file is a generated module that imports all packages provided in
the repository, which replicates an external consumer using our code
as a dependency in go-module mode, and verifies all files in those
packages have the correct "//go:build <go language version>" set.
To test this package:
make shell
make -C ./internal/gocompat/
make: Entering directory '/go/src/github.com/docker/cli/internal/gocompat'
GO111MODULE=off go generate .
GO111MODULE=on go mod tidy
GO111MODULE=on go test -v
# github.com/docker/cli/templates
../../templates/templates.go:13:17: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
# github.com/docker/cli/cli/compose/template
../../cli/compose/template/template.go:98:45: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/template/template.go:105:27: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/template/template.go:141:28: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
# github.com/docker/cli/cli/compose/types
../../cli/compose/types/types.go:53:22: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/types/types.go:86:34: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/types/types.go:105:22: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/types/types.go:137:34: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/types/types.go:211:20: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/types/types.go:343:35: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/types/types.go:442:40: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/types/types.go:469:24: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/types/types.go:490:24: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/types/types.go:587:28: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/types/types.go:442:40: too many errors
# github.com/docker/cli/cli/context/store
../../cli/context/store/storeconfig.go:6:24: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/context/store/store.go:74:12: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/context/store/store.go:75:23: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/context/store/metadatastore.go:43:58: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/context/store/metadatastore.go:48:22: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/context/store/metadatastore.go:80:30: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
# github.com/docker/cli/cli/command/idresolver
../../cli/command/idresolver/idresolver.go:6:2: "github.com/docker/docker/api/types" imported and not used
../../cli/command/idresolver/idresolver.go:7:2: "github.com/docker/docker/api/types/swarm" imported and not used
../../cli/command/idresolver/idresolver.go:9:2: "github.com/pkg/errors" imported and not used
../../cli/command/idresolver/idresolver.go:28:49: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/command/idresolver/idresolver.go:58:53: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
# github.com/docker/cli/cli/compose/schema
../../cli/compose/schema/schema.go:20:46: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/schema/schema.go:27:53: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/schema/schema.go:45:32: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
../../cli/compose/schema/schema.go:66:33: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
FAIL gocompat [build failed]
make: *** [Makefile:3: verify] Error 1
make: Leaving directory '/go/src/github.com/docker/cli/internal/gocompat'
[DefaultGoModVersion]: https://github.com/golang/go/blob/58c28ba286dd0e98fe4cca80f5d64bbcb824a685/src/cmd/go/internal/gover/version.go#L15-L24
[2]: https://go.dev/doc/toolchain
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Document how multiple --filter flags interact in prune commands:
different filter keys are ANDed (all conditions must match), while
multiple values for the same key are ORed (any value can match).
This addresses a gap in the documentation where users could not
determine whether multiple filters were combined with AND or OR
logic, which is especially important for prune commands where
the wrong assumption could lead to unintended data removal.
Closes#5899
Signed-off-by: Yoan Wainmann <yoan@mreshet.co.il>
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>
When linking containers through legacy links, a container can get multiple
names; its own name, and a name for each link it's providing:
# create two containers with links between them
docker run -d --name one nginx:alpine
docker run -d --name two --link one:link1 --link one:link2 --link one:link3 nginx:alpine
docker rm --link <tab>
two/link1 two/link2 two/link3
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Inline StripNamePrefix and skip legacy links for completion.
Legacy links can be removed from a container, but only when
using `docker [container] rm --link <link-name>`.
When linking containers through legacy links, a container can get multiple
names; its own name, and a name for each link it's providing:
# create two containers with links between them
docker run -d --name one nginx:alpine
docker run -d --name two --link one:link1 --link one:link2 --link one:link3 nginx:alpine
# container "one" now has multiple names
docker ps --no-trunc --format '{{.Names}}'
two
one,two/link1,two/link2,two/link3
# running `docker rm --link` with a link-name removes a link:
docker rm --link two/link3
docker ps --no-trunc --format '{{.Names}}'
two
one,two/link1,two/link2
# but without `--link`, it resolves the linked container and removes it:
docker rm -fv two/link2
two/link2
docker ps --no-trunc --format '{{.Names}}'
two
Legacy links are deprecated, and this can be confusing, so let's not provide
completion for secondary names.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This code was assuming the API always returns container names with
a "/" prefix. While this is currently correct, we may at some point
stop doing so.
This patch changes the code to only trim "/" as prefix and not any
other character.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This code was assuming the API always returns container names with
a "/" prefix. While this is currently correct, we may at some point
stop doing so.
This patch changes the code to only trim "/" as prefix and not any
other character.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- skip aec to construct the formatting and use a const instead
- skip fmt.Println and write directly to the writer
- move newlines outside of the "bold" formatting
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This allows for slighly cleaner / more natural placeholders, as it
doesn't require the context (`.`) to be specified;
- `{{command}}` instead of `{{.Command}}` or `{{command .}}`
- `{{flagValue "my-flag"}}` instead of `{{.FlagValue "my-flag"}} or `{{flagValue . "my-flag"}}`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Define a local type for methods to expose to the template, instead of
passing the cobra.Cmd. This avoids templates depending on features
exposed by Cobra that are not part of the contract, and slightly
decouples the templat from the Cobra implementation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- use `%q` instead of manually quoting the string
- use `%d` instead of manually converting the number to a string
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- add basic unit-test for the template utilities
- make sure the template parsing tests test both the current
template produced by the utilities, as well as a fixture
- rewrite the printer test to use fixtures
- use blackbox testing ("hooks_test")
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These utilities are used by CLI-plugins; separate them from the render
code, which is used by teh CLI-plugin manager.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Rename the type to match the struct it's used for. Also;
- Fix the type of the NextSteps const
- Don't use iota for values; the ResponseType is used as
part of the "wire" format, which means that plugins using
the value can use a different version of the module code;
using iota increases the risk of (accidentally) changing
values, which would break the wire format.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Currently, the error was a plain "exit status 1"; make the error
message more informative if we need it :)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- update setHandler to accept multiple event-types
- pass a logger to the event-handlers with the common fields
already set.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Wire up the context explicitly instead of capturing it in the closures.
Also pass through the context to `watch` to replace the context.TODO()
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When copying files with `docker cp`, the success message now shows both
the actual content size and the transferred (tar stream) size when they
differ, making it easier to understand compression and overhead:
Successfully copied 2.01MB (transferred 2.53MB) to ctr:/dir
Extract copySummary helper to keep copyToContainer under the gocyclo
complexity threshold. Add unit tests for copySummary and stdin path.
Signed-off-by: 4RH1T3CT0R7 <iprintercanon@gmail.com>
Add linux/riscv64 to the bin-image-cross platforms list so that
official release images include riscv64 binaries.
riscv64 is already present in the _platforms variable (line 38) and
used by the cross, dynbinary-cross, and plugins-cross targets. CI
already builds riscv64 binaries, but they are excluded from the
release image because bin-image-cross has its own platform list.
Closes#6857
Signed-off-by: Bruno Verachten <gounthar@gmail.com>
- commit e8dc2fce32 modernized loops to
range over int, which requires go1.22 or later.
- commit 85ebca52fd modernized code to
use stdlib min/max, which requires go1.21 or later.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.25.8 (released 2026-03-05) includes security fixes to the html/template,
net/url, and os packages, as well as bug fixes to the go command, the compiler,
and the os package. See the Go 1.25.8 milestone on our issue tracker for details.
- 1.25.8 https://github.com/golang/go/issues?q=milestone%3AGo1.25.8+label%3ACherryPickApproved
- diff: https://github.com/golang/go/compare/go1.25.7...go1.25.8
- 1.26.1 https://github.com/golang/go/issues?q=milestone%3AGo1.26.1+label%3ACherryPickApproved
- diff: https://github.com/golang/go/compare/go1.26.0...go1.26.1
---
We have just released Go versions 1.26.1 and 1.25.8, minor point releases.
These releases include 5 security fixes following the security policy:
crypto/x509: incorrect enforcement of email constraints
- When verifying a certificate chain which contains a certificate containing
multiple email address constraints (composed of the full email address) which
share common local portions (the portion of the address before the '@'
character) but different domain portions (the portion of the address after the
'@' character), these constraints will not be properly applied, and only the
last constraint will be considered.
This can allow certificates in the chain containing email addresses which are
either not permitted or excluded by the relevant constraints to be returned by
calls to Certificate.Verify. Since the name constraint checks happen after chain
building is complete, this only applies to certificate chains which chain to
trusted roots (root certificates either in VerifyOptions.Roots or in the system
root certificate pool), requiring a trusted CA to issue certificates containing
either not permitted or excluded email addresses.
This issue only affects Go 1.26.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2026-27137 and Go issue https://go.dev/issue/77952.
- crypto/x509: panic in name constraint checking for malformed certificates
Certificate verification can panic when a certificate in the chain has an empty
DNS name and another certificate in the chain has excluded name constraints.
This can crash programs that are either directly verifying X.509 certificate
chains, or those that use TLS.
Since the name constraint checks happen after chain building is complete, this
only applies to certificate chains which chain to trusted roots (root
certificates either in VerifyOptions.Roots or in the system root certificate
pool), requiring a trusted CA to issue certificates containing malformed DNS
names.
This issue only affects Go 1.26.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2026-27138 and Go issue https://go.dev/issue/77953.
- html/template: URLs in meta content attribute actions are not escaped
Actions which insert URLs into the content attribute of HTML meta tags are not
escaped. This can allow XSS if the meta tag also has an http-equiv attribute
with the value "refresh".
A new GODEBUG setting has been added, htmlmetacontenturlescape, which can be
used to disable escaping URLs in actions in the meta content attribute which
follow "url=" by setting htmlmetacontenturlescape=0.
This is CVE-2026-27142 and Go issue https://go.dev/issue/77954.
- net/url: reject IPv6 literal not at start of host
The Go standard library function net/url.Parse insufficiently
validated the host/authority component and accepted some invalid URLs
by effectively treating garbage before an IP-literal as ignorable.
The function should have rejected this as invalid.
To prevent this behavior, net/url.Parse now rejects IPv6 literals
that do not appear at the start of the host subcomponent of a URL.
Thanks to Masaki Hara (https://github.com/qnighy) of Wantedly.
This is CVE-2026-25679 and Go issue https://go.dev/issue/77578.
- os: FileInfo can escape from a Root
On Unix platforms, when listing the contents of a directory using
File.ReadDir or File.Readdir the returned FileInfo could reference
a file outside of the Root in which the File was opened.
The contents of the FileInfo were populated using the lstat system
call, which takes the path to the file as a parameter. If a component
of the full path of the file described by the FileInfo is replaced with
a symbolic link, the target of the lstat can be directed to another
location on the filesystem.
The impact of this escape is limited to reading metadata provided by
lstat from arbitrary locations on the filesystem. This could be used
to probe for the presence or absence of files as well as gleaning
metadata like file sizes, but does not permit reading or writing files
outside the root.
The FileInfo is now populated using fstatat.
Thank you to Miloslav Trmač of Red Hat for reporting this issue.
This is CVE-2026-27139 and Go issue https://go.dev/issue/77827.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add support for the `bind-create-src` option in bind mounts, which
instructs the daemon to create the source mountpoint on the host if it
doesn't exist.
This allows to replace the legacy `-v /src/dir:/dst` with the `--mount`.
Usage:
--mount type=bind,src=/host/path,dst=/container/path,bind-create-src
--mount type=bind,src=/host/path,dst=/container/path,bind-create-src=true
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Preserve all whitespace and treat the secret as an opaque value,
leaving it to the registry to (in)validate. We still check for
empty values in some places.
This partially reverts a21a5f4243,
but checks for empty (whitespace-only) passwords without mutating
the value.
This better aligns with [NIST SP 800-63B §5.1.1.2], which describes
that the value should be treated as opaque, preserving any other whitespace,
including newlines. Note that trimming whitespace may still happen elsewhere
(see [NIST SP 800-63B (revision 4) §3.1.1.2]);
> Verifiers **MAY** make limited allowances for mistyping (e.g., removing
> leading and trailing whitespace characters before verification, allowing
> the verification of passwords with differing cases for the leading character)
[NIST SP 800-63B §5.1.1.2]: https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver
[NIST SP 800-63B (revision 4) §3.1.1.2]: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The code was using an intermediate map, indexed by name, for services
per file. Service-names should be unique per-file, so using an intermediate
map would not benefit us (we'd still have to loop over all of them to
produce the map, and again to iterate over the map)
Remove the intermediate map for overrides, and apply all overrides for
a service instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- construct merge-opts as a slice
- remove intermediate var for overrideServices
- use slices.SortFunc for sorting
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The existing code only sorted by PublishedPort (host port), and did
not account for multiple ports mapped to the same host-port, but
using a different protocol.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 880ef756b7 fixed static builds with
CGO, which included setting the `netgo` build-tag for static builds.
Starting with go1.19, the Go runtime on Windows now supports the `netgo` build-
flag to use a native Go DNS resolver. Prior to that version, the build-flag
only had an effect on non-Windows platforms. From the go1.19 release notes:
https://go.dev/doc/go1.19#net
> Resolver.PreferGo is now implemented on Windows and Plan 9. It previously
> only worked on Unix platforms. Combined with Dialer.Resolver and Resolver.Dial,
> it's now possible to write portable programs and be in control of all DNS name
> lookups when dialing.
>
> The net package now has initial support for the netgo build tag on Windows.
> When used, the package uses the Go DNS client (as used by Resolver.PreferGo)
> instead of asking Windows for DNS results. The upstream DNS server it discovers
> from Windows may not yet be correct with complex system network configurations,
> however.
This originally caused issues in the daemon, because the pure-go implementation
did not respect file-based resolution (`C:\Windows\System32\Drivers\etc\hosts`),
resulting in `localhost` not being resolvable, and custom entries in `.etc/hosts`
not being used.
That specific problem was resolved in go1.22 (through [golang/go@33d4a51]), but
other limitations may still apply, and resolver ordering may not respect VPN
adaptors (such as Twingate) and queries sent through the local network adapter
instead of the VPN tunnel, resulting in DNS resolution failures;
Get "https://example.com:2376/v1.52/containers/json": dial tcp: lookup example.com: i/o timeout
This patch unsets the `netgo` option when (cross-)compiling for Windows, similar
to the patch used for the daemon (see [moby/moby@53d1b12]).
[golang/go@33d4a51]: https://github.com/golang/go/commit/33d4a5105cf2b2d549922e909e9239a48b8cefcc
[moby/moby@53d1b12]: https://github.com/moby/moby/commit/53d1b12bc014b4243e9439fc2610eb4ef863659f
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.25.7 (released 2026-02-04) includes security fixes to the go command
and the crypto/tls package, as well as bug fixes to the compiler and the
crypto/x509 package. See the Go 1.25.7 milestone on our issue tracker for
details:
https://github.com/golang/go/issues?q=milestone%3AGo1.25.7+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.25.6...go1.25.7
From the security mailing list:
> Hello gophers,
>
> We have just released Go versions 1.25.7 and 1.24.13, minor point releases.
>
> These releases include 2 security fixes following the security policy:
>
> - cmd/cgo: remove user-content from doc strings in cgo ASTs
>
> A discrepancy between how Go and C/C++ comments
> were parsed allowed for code smuggling into the
> resulting cgo binary.
>
> To prevent this behavior, the cgo compiler
> will no longer parse user-provided doc
> comments.
>
> Thank you to RyotaK (https://ryotak.net) of
> GMO Flatt Security Inc. for reporting this issue.
>
> This is CVE-2025-61732 and https://go.dev/issue/76697.
>
> - crypto/tls: unexpected session resumption when using Config.GetConfigForClient
>
> Config.GetConfigForClient is documented to use the original Config's session
> ticket keys unless explicitly overridden. This can cause unexpected behavior if
> the returned Config modifies authentication parameters, like ClientCAs: a
> connection initially established with the parent (or a sibling) Config can be
> resumed, bypassing the modified authentication requirements.
>
> If ClientAuth is VerifyClientCertIfGiven or RequireAndVerifyClientCert (on the
> server) or InsecureSkipVerify is false (on the client), crypto/tls now checks
> that the root of the previously-verified chain is still in ClientCAs/RootCAs
> when resuming a connection.
>
> Go 1.26 Release Candidate 2, Go 1.25.6, and Go 1.24.12 had fixed a similar issue
> related to session ticket keys being implicitly shared by Config.Clone. Since
> this fix is broader, the Config.Clone behavior change has been reverted.
>
> Note that VerifyPeerCertificate still behaves as documented: it does not apply
> to resumed connections. Applications that use Config.GetConfigForClient or
> Config.Clone and do not wish to blindly resume connections established with the
> original Config must use VerifyConnection instead (or SetSessionTicketKeys or
> SessionTicketsDisabled).
>
> Thanks to Coia Prant (github.com/rbqvq) for reporting this issue.
>
> This updates CVE-2025-68121 and Go issue https://go.dev/issue/77217.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This splits the validation code from parsing code, potentially allowing
us to either fully deferring it to the daemon, or to perform validation
separately.
For reference; daemon-side validation currently (docker 29.2.0) produces;
docker run --rm --mount type=bind,src=/var/run,target=/foo,bind-recursive=writable alpine
docker: Error response from daemon: mount options conflict: !ReadOnly && BindOptions.ReadOnlyNonRecursive
docker run --rm --mount type=bind,src=/var/run,target=/foo,bind-recursive=readonly alpine
docker: Error response from daemon: mount options conflict: !ReadOnly && BindOptions.ReadOnlyForceRecursive
Validation for BindOptions.Propagation is currently missing on the daemon;
docker run --rm --mount type=bind,src=/var/run,target=/foo,bind-recursive=readonly,readonly alpine
# no error
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The daemon already validates the target, so we don't have to validate
if a target is set. Instead, we can ignore empty targets, but produce
an error if a target option was set, but set to an empty value.
With this patch applied, omitting a target option is ignored by the CLI,
but still invalidated by the daemon if the given mount-type requires a
mount target;
docker run --rm --mount type=bind,src=/var/run/docker.sock alpine
docker: Error response from daemon: invalid mount config for type "bind": field Target must not be empty
docker run --rm --mount type=bind,src=/var/run/docker.sock,dst=../foo alpine
docker: Error response from daemon: invalid mount config for type "bind": invalid mount path: '../foo' mount path must be absolute
When passing a target option (`target`, `dst`, or `destination`), the
CLI produces an error if the value is empty;
docker run --rm --mount type=bind,src=/var/run/docker.sock,dst= alpine
invalid argument "type=bind,src=/var/run/docker.sock,dst=" for "--mount" flag: invalid value for 'dst': mount target must be a non-empty value
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this patch:
docker run --rm --mount "" busybox
invalid argument "" for "--mount" flag: EOF
With this patch:
docker run --rm --mount "" busybox
invalid argument "" for "--mount" flag: value is empty
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Setting the source and target paths is not tied to the mount-type,
so these tests where covering the same code.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add a custom join function that allows for non-string slices to be
joined, following the same rules as "fmt.Sprint", it will use the
fmt.Stringer interface if implemented, or "error" if the type has
an "Error()".
For maps, it joins the map-values, for example:
docker image inspect --format '{{join .Config.Labels ", "}}' ubuntu
24.04, ubuntu
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Prior to 1a502e91c9, failing to write the
container-ID to a file would return an error. After that change, we could
end up in a situation where the container was created successfully, but
we failed to inject the `config.json`. This failure would be returned as
an error, but the container was created (but no ID returned due to the error).
This patch changes the error to a warning; while not "ideal" (the container
is created, but in a "partial" state), we also shouldn't consider it to be
a hard failure; proceed as normal, to allow the user to either use the
container as-is, or to delete the container and try again.
Alternatively, we could join these errors, but the result will be ambiguous
in either case (container created, but an error occurred after the fact).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Ignore errors when trying to remove a CID-file that no longer exists;
also remove the path from the custom error as os.Remove already returns
a os.PathError, which includes the path.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Include the container-ID in the error message when failing to write
the ID to a file, so that the user can still find the ID of the container
that was created.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This releases includes 6 security fixes following the security policy:
- archive/zip: denial of service when parsing arbitrary ZIP archives
archive/zip used a super-linear file name indexing algorithm that is invoked the first time a file in an archive is opened. This can lead to a denial of service when consuming a maliciously constructed ZIP archive.
Thanks to Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-61728 and Go issue https://go.dev/issue/77102.
- net/http: memory exhaustion in Request.ParseForm
When parsing a URL-encoded form net/http may allocate an unexpected amount of
memory when provided a large number of key-value pairs. This can result in a
denial of service due to memory exhaustion.
Thanks to jub0bs for reporting this issue.
This is CVE-2025-61726 and Go issue https://go.dev/issue/77101.
- crypto/tls: Config.Clone copies automatically generated session ticket keys, session resumption does not account for the expiration of full certificate chain
The Config.Clone methods allows cloning a Config which has already been passed
to a TLS function, allowing it to be mutated and reused.
If Config.SessionTicketKey has not been set, and Config.SetSessionTicketKeys has
not been called, crypto/tls will generate random session ticket keys and
automatically rotate them. Config.Clone would copy these automatically generated
keys into the returned Config, meaning that the two Configs would share session
ticket keys, allowing sessions created using one Config could be used to resume
sessions with the other Config. This can allow clients to resume sessions even
though the Config may be configured such that they should not be able to do so.
Config.Clone no longer copies the automatically generated session ticket keys.
Config.Clone still copies keys which are explicitly provided, either by setting
Config.SessionTicketKey or by calling Config.SetSessionTicketKeys.
This issue was discoverd by the Go Security team while investigating another
issue reported by Coia Prant (github.com/rbqvq).
Additionally, on the server side only the expiration of the leaf certificate, if
one was provided during the initial handshake, was checked when considering if a
session could be resumed. This allowed sessions to be resumed if an intermediate
or root certificate in the chain had expired.
Session resumption now takes into account of the full chain when determining if
the session can be resumed.
Thanks to Coia Prant (github.com/rbqvq) for reporting this issue.
This is CVE-2025-68121 and Go issue https://go.dev/issue/77113.
- cmd/go: bypass of flag sanitization can lead to arbitrary code execution
Usage of 'CgoPkgConfig' allowed execution of the pkg-config
binary with flags that are not explicitly safe-listed.
To prevent this behavior, compiler flags resulting from usage
of 'CgoPkgConfig' are sanitized prior to invoking pkg-config.
Thank you to RyotaK (https://ryotak.net) of GMO Flatt Security Inc.
for reporting this issue.
This is CVE-2025-61731 and go.dev/issue/77100.
- cmd/go: unexpected code execution when invoking toolchain
The Go toolchain supports multiple VCS which are used retrieving modules and
embedding build information into binaries.
On systems with Mercurial installed (hg) downloading modules (e.g. via go get or
go mod download) from non-standard sources (e.g. custom domains) can cause
unexpected code execution due to how external VCS commands are constructed.
On systems with Git installed, downloading and building modules with malicious
version strings could allow an attacker to write to arbitrary files on the
system the user has access to. This can only be triggered by explicitly
providing the malicious version strings to the toolchain, and does not affect
usage of @latest or bare module paths.
The toolchain now uses safer VCS options to prevent misinterpretation of
untrusted inputs. In addition, the toolchain now disallows module version
strings prefixed with a "-" or "/" character.
Thanks to splitline (@splitline) from DEVCORE Research Team for reporting this
issue.
This is CVE-2025-68119 and Go issue https://go.dev/issue/77099.
- crypto/tls: handshake messages may be processed at the incorrect encryption level
During the TLS 1.3 handshake if multiple messages are sent in records that span
encryption level boundaries (for instance the Client Hello and Encrypted
Extensions messages), the subsequent messages may be processed before the
encryption level changes. This can cause some minor information disclosure if a
network-local attacker can inject messages during the handshake.
Thanks to Coia Prant (github.com/rbqvq) for reporting this issue.
This is CVE-2025-61730 and Go issue https://go.dev/issue/76443
View the release notes for more information:
https://go.dev/doc/devel/release#go1.25.6
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Before this patch, lintian would complain about some lines being too long:
lintian ./*.deb
...
W: docker-ce-cli: groff-message troff:<standard input>:642: warning [p 8, 10.2i, div '3tbd1,1', 0.0i]: cannot break line [usr/share/man/man1/docker-run.1.gz:1]
groff -t -man ./docker-run.1 > /dev/null
troff:./docker-run.1:602: warning [p 9, 2.8i]: cannot adjust line
troff:./docker-run.1:669: warning [p 10, 2.5i, div '3tbd1,1', 0.0i]: cannot break line
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- remove constructor
- fix mixed pointer/non-pointer receivers
- just embed the error we want to produce
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this change, the detach-keys were not validated, and the code either
fell back to the default sequence, or returned an obscure error if the
invalid sequence would produce an error on the daemon;
Before this patch:
docker run -it --rm --detach-keys=shift-a,b busybox
unable to upgrade to tcp, received 400
With this patch:
docker run -it --rm --detach-keys=shift-a,b busybox
invalid detach keys (shift-a,b): Unknown character: 'shift-a'
Note that the "unable to upgrade to tcp, received 400" error is still
something to be looked into; the client currently discards error messages
coming from the daemon.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use a more generic "clientOptions" field to store options to apply
when constructing the API client, instead of a dedicated field for
user-agent.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Changed the environment variables section description from:
"The following list of environment variables are supported by the `docker` command line:"
To:
"The following environment variables control the behavior of the `docker` command-line client:"
This makes it clearer that these variables control Docker's behavior, and uses the more precise term "command-line client" instead of "command line".
Signed-off-by: Andrew Hopp <andrew.hopp@me.com>
`go list` expects a module to be valid, which means that dependencies must
either be vendored, or downloaded in the module cache. However, when working
in GOPATH mode, `go.mod` files are ignored, which means that `go list` will
traverse subdirectories, even if those are a separate module, and those modules
may not have their dependencies present.
In our case, we try to exclude those modules from paths to be tested, but
do so based on the _result_ of `go list`, which already produces errors before
we filter.
These errors do not impact out tests, as we don't run tests for those paths,
but do produce noise in CI, which can be confusing;
go test -coverprofile=/tmp/coverage.txt $(go list ./... | grep -vE '/vendor/|/e2e/|/cmd/docker-trust')
cmd/docker-trust/internal/trust/trust.go:28:2: cannot find package "github.com/theupdateframework/notary" in any of:
/go/src/github.com/docker/cli/vendor/github.com/theupdateframework/notary (vendor tree)
/usr/local/go/src/github.com/theupdateframework/notary (from $GOROOT)
/go/src/github.com/theupdateframework/notary (from $GOPATH)
cmd/docker-trust/internal/trust/trust.go:29:2: cannot find package "github.com/theupdateframework/notary/client" in any of:
/go/src/github.com/docker/cli/vendor/github.com/theupdateframework/notary/client (vendor tree)
/usr/local/go/src/github.com/theupdateframework/notary/client (from $GOROOT)
/go/src/github.com/theupdateframework/notary/client (from $GOPATH)
This patch adds a symlink for `go.mod` and `go.sum`, so that listing the
packages happens in go modules mode, and doesn't traverse to other modules,
such as `cmd/docker-trust`.
- updates 06914dd0ff, which attempted to
exclude the docker-trust plugin
- similar to cee9ea67fc, which made this
change for the linter.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- trace: fix data race in RenderEvents
- http2, webdav, websocket: fix %q verb uses with wrong type
- http2: don't PING a responsive server when resetting a stream
- http2: support net/http.Transport.NewClientConn
full diff: https://github.com/golang/net/compare/v0.47.0...v0.48.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was introduced in 9c10a9c9ac, which added
use of the network.ParsePortRange.All method, which uses an iterator and
requires go1.23;
opts/swarmopts/port.go:172:18: cannot range over pr.All() (value of func type iter.Seq[network.Port]): requires go1.23 or later (-lang was set to go1.16; check go.mod)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 4d3a76d71e updated the list of directories
for discovering CLI plugins, adding `%ProgramFiles%\Docker\cli-plugins` for
system-wide plugins.
For backward compatibility, the `%PROGRAMDATA%\Docker\cli-plugins` was kept,
however, this location is no longer used, and not generally recommended for
storing non-data content (such as CLI plugin binaries). From the [ProgramData]
documentation:
> ProgramData specifies the path to the program-data folder (normally C:\ProgramData).
> Unlike the Program Files folder, this folder can be used by applications to store
> data for standard users, because it does not require elevated permissions.
It also mentions "It can’t contain any serviceable components.", effectively
meaning that these paths should not contain data that is managed (through
updates etc.), making it a poor choice for installing "system wide" CLI plugins.
This patch removes the path from the list, given that this location is no longer
used by Docker Desktop, and the CLI-plugin API is considered an internal
implementation (since 459c6082f8).
[ProgramData]: https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-folderlocations-programdata
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The --all flag description was misleading by only mentioning
intermediate images, when it actually also controls the visibility of
dangling (untagged) images.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This reverts part of the logic introduced in 207bf52c27 which
incorrectly gated untagged images behind the --all flag in non-expanded
view.
The original fix was addressing the wrong layer of the problem.
The actual issue was that dangling images were being incorrectly passed
to the tree code in the first place.
This was properly fixed in 67f5e3413 which corrected the dangling image
detection logic to properly filter them out before reaching the tree
display code.
Now that dangling images are correctly filtered upstream, untagged
images that reach the tree view should be displayed regardless of the
--all flag setting.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
When calculating column widths for the tree view, untagged images
weren't being properly accounted for in the width calculation.
This caused layout issues when there were tagged images were shorter
than the `<untagged>` string.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The isDangling function was incorrectly identifying images as dangling
when they had no RepoTags but had valid RepoDigests.
This can occur when the graphdrivers are used instead of the containerd
image store.
An image should only be considered dangling if it has no RepoTags,
regardless of whether it has RepoDigests.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Some validation steps done by `docker create` (and `docker run`) are platform-
specific, and need to know the daemon's OS.
To get this information, the CLI.ServerInfo() method was used, which
discards connection errors, resulting in an empty OS, which causes
validation to fail with an "unknown server OS" error message.
This patch changes it to use the Client.Ping so that we can error when
failing to connect.
We should look if we can reduce the platform-specific validation and parsing
on the client-side, but at least this change should produce a more useful
error.
Before this patch:
DOCKER_HOST=tcp://example.invalid docker run -it --rm --device=/dev/dri alpine
docker: unknown server OS:
Run 'docker run --help' for more information
With this patch:
DOCKER_HOST=tcp://example.invalid docker run -it --rm --device=/dev/dri alpine
failed to connect to the docker API at tcp://example.invalid:2375: lookup example.invalid on 192.168.65.7:53: no such host
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
With this patch:
docker stack deploy -c<TAB>
.codecov.yml contrib/ e2e/ pkg/
.git/ build/ debian/ experimental/
...
docker stack deploy -c contrib/otel/<TAB>
compose.yaml otelcol.yaml prom.yaml
Note that filtering for the file-extension only appears to be functional
on bash, but not (currently) working on other shells (at least not on Fish).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These releases include 2 security fixes following the security policy:
- crypto/x509: excessive resource consumption in printing error string for host certificate validation
Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out.
Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime.
Therefore, a certificate provided by a malicious actor can result in excessive resource consumption.
HostnameError.Error() now limits the number of hosts and utilizes strings.Builder when constructing an error string.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2025-61729 and Go issue https://go.dev/issue/76445.
- crypto/x509: excluded subdomain constraint does not restrict wildcard SANs
An excluded subdomain constraint in a certificate chain does not restrict the
usage of wildcard SANs in the leaf certificate. For example a constraint that
excludes the subdomain test.example.com does not prevent a leaf certificate from
claiming the SAN *.example.com.
This is CVE-2025-61727 and Go issue https://go.dev/issue/76442.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.25.5
Signed-off-by: Paweł Gronowski <pawel.gronowski@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>
- cpu: add HPDS, LOR, PAN detection for arm64
- cpu: also use MRS instruction in getmmfr1
- cpu: use MRS instruction to read arm64 system registers
- unix: add consts for ELF handling
- unix: add SetMemPolicy and its mode/flag values
- unix: add SizeofNhmsg and SizeofNexthopGrp
- windows: add iphlpapi routing functions
full diff: https://github.com/golang/sys/compare/v0.37.0...v0.38.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Users were experiencing poor UX when image names were truncated in the
table output.
Instead of cutting off long image names with ellipsis, the names now
wrap to the next line to ensure full visibility.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Setting a custom format in the cli cofig should still be supported,
and not produce an error when specifying "--tree". Specifyihg both
"--tree" and "--format" still produces an error, but we could consider
allowing "json" format in a future update.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Introduced by bff56f0 (cli/command/system: define struct for
formatting version).
In the "docker info" result, the Engine component's BuildTime should
be in time.ANSIC format, but the top level BuildTime field should use
time.RFC3339Nano.
Signed-off-by: Rob Murray <rob.murray@docker.com>
In non-expanded view, untagged images should only be displayed when the
--all flag is explicitly provided by the user.
Previously, untagged images were accidentally always shown in the
non-expanded view regardless of the --all flag setting.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Previously when no terminal was attached the width was assumed to be 80.
This is too short for most image names which truncated the names when
output was redirect (for example to `grep`).
This disabled the name truncation if the terminal width can't be
determined.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
In the expanded view there is a separate image entry per each tag.
Fix a bug which caused no entry to be added for untagged images.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The client.ServerVersion method in the moby/client module defines
an output struct that's separate from the API response. These output
structs are not designed to be marshaled as JSON, but the CLI depended
on them defining `json` labels, which it used to format the output
as JSON (`docker version --format=json`); as a result, the JSON output
changed in docker v29, as it would now use the naming based on the Go
struct's fields (`APIVersion` instead of `ApiVersion`).
In future, we should consider having a `--raw` (or similar) option for
the CLI to print API responses as-is, instead of using client structs
or CLI structs for this (this would also make sure the JSON output does
not inherit client-side formatting of fields).
For now, let's create a struct for formatting the output, similar to what
we do for the client-side information.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These were originally added in 6f61cf053a,
but at the time, the error wasn't returned. Now that it is, we shouldn't
log _and_ return the error.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adds support for setting memory swap settings on Swarm services
* Adds flags `memory-swap` and `memory-swappiness` to `docker service
create` and `docker service update` commands.
* Adds compose fields `memswap_limit` and `mem_swappiness` for `docker
stack` commands.
Signed-off-by: Drew Erny <derny@mirantis.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Prevent the linter from recursing to other modules (cmd/docker-trust),
which don't have their dependencies vendored.
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>
- term: remove duplicate flag and add comment on windows
- term: allow multi-line bracketed paste to not create single line
with verbatim LFs (fixes "x/term: multi line bracketed paste fails"
to issue line by line commands
full diff: https://github.com/golang/term/compare/v0.32.0...v0.36.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This code was using swarmkit's genericresource package as intermediate;
add a local copy of that code that skips the protobufs as intermediate.
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>
- Add WS2025 to Windows matcher and code optimizations
- use windowsMatchComparer for OSVersion match order
Windows OS version should match based on the full OSVersion. When
sorting a manifest, the entries should be sorted using the `Less`
function.
full diff: https://github.com/containerd/platforms/compare/v1.0.0-rc.1...v1.0.0-rc.2
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was introduced in dad1d367c8, which
did not add a `//go:build` constraint to enable the use of generics (`any`).
Which causes an error when used;
could not import github.com/docker/cli/cli/command/container (-: # github.com/docker/cli/cli/command/container
/Users/thajeztah/go/pkg/mod/github.com/docker/cli@v29.0.0-rc.2+incompatible/cli/command/container/stats.go:148:39: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The allManagementSubCommands function is used to present plugin-commands
in the docker --help output; these commands are included in the "management
commands" section, but for plugins we don't know if they have sub-commands.
However, plugin stubs may be hidden (for placeholders that are not yet loaded),
or not be runnable, which was previously ignored.
This patch treats plugin-stubs the same as other commands, with the exception
of checking if they have subcommands (which is not yet known for plugin-stubs).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
about:"General Docker Desktop issues (installation, upgrades, UI, networking on macOS/Windows, WSL2, etc.) should be filed in the Docker Desktop feedback tracker (not docker/cli)."
os-chdir:false# FIXME(thaJeztah): Disable `os.Chdir()` detections; should be automatically disabled on Go < 1.24; see https://github.com/docker/cli/pull/5835#issuecomment-2665302478
context-background:false# FIXME(thaJeztah): Disable `context.Background()` detections; should be automatically disabled on Go < 1.24; see https://github.com/docker/cli/pull/5835#issuecomment-2665302478
context-todo:false# FIXME(thaJeztah): Disable `context.TODO()` detections; should be automatically disabled on Go < 1.24; see https://github.com/docker/cli/pull/5835#issuecomment-2665302478
exclusions:
# We prefer to use an "linters.exclusions.rules" so that new "default" exclusions are not
# automatically inherited. We can decide whether or not to follow upstream
@@ -223,13 +220,10 @@ linters:
linters:
- staticcheck
# Ignore deprecation linting for cli/command/stack/*.
#
# FIXME(thaJeztah): remove exception once these functions are un-exported or internal; see https://github.com/docker/cli/pull/6389
- text:'^(SA1019):'
path:"cli/command/stack"
# TODO(thaJeztah): remove once https://github.com/leighmcculloch/gocheckcompilerdirectives/issues/7 is fixed.
test-unit:## run unit tests, to change the output format use: GOTESTSUM_FORMAT=(dots|short|standard-quiet|short-verbose|standard-verbose) make test-unit
gotestsum -- $${TESTDIRS:-$(shell go list ./... | grep -vE '/vendor/|/e2e/')}$(TESTFLAGS)
gotestsum -- $${TESTDIRS:-$(shell go list ./... | grep -vE '/vendor/|/e2e/|/cmd/docker-trust')}$(TESTFLAGS)
.PHONY:test-coverage
test-coverage:## run test coverage
mkdir -p $(CURDIR)/build/coverage
gotestsum -- $(shell go list ./... | grep -vE '/vendor/|/e2e/') -coverprofile=$(CURDIR)/build/coverage/coverage.txt
gotestsum -- $(shell go list ./... | grep -vE '/vendor/|/e2e/|/cmd/docker-trust') -coverprofile=$(CURDIR)/build/coverage/coverage.txt
.PHONY:lint
lint:## run all the lint tools
@@ -52,7 +52,7 @@ shellcheck: ## run shellcheck validation
.PHONY:fmt
fmt:## run gofumpt (if present) or gofmt
@if command -v gofumpt > /dev/null;then\
gofumpt -w -d -lang=1.23 . ;\
gofumpt -w -d -lang=1.24 . ;\
else\
go list -f {{.Dir}} ./... | xargs gofmt -w -s -d ;\
pCmd:=exec.CommandContext(ctx,p.Path,p.Name,metadata.HookSubcommandName,string(hDataBytes))// #nosec G204 -- ignore "Subprocess launched with a potential tainted input or cmd arguments"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
