The DCO policy used here appears to have been derived from the Linux
kernel's guidance. In 2023, that guidance changed to relax the "real
name" requirement to a "known identity".
The DCO sign-off identifies the person certifying that they have the
right to submit a contribution. The previous wording required a "real
name" and rejected pseudonyms, which could discourage contributors
whose preferred or community name is the identity by which they can be
known.
The requirement is not anonymity: the identity in the sign-off must be
known enough for the project to follow up about the contribution if a
question arises. It does not require a legal name or a government-issued
identity. Use the clarified wording from the Linux kernel so known
pseudonyms and preferred names remain acceptable while anonymous
contributions remain excluded.
This also reflects concerns raised in the CNCF community about whether
"real name" means a legal name, a government-issued identity, or a
public identity that is sufficient to identify and contact a
contributor. The discussion emphasized that attribution and future
accountability do not require publishing a legal identity, and that
strict public-name rules can exclude people who cannot safely contribute
under that name.
Source: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4563201f33a022fc035
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This release includes a fix to address a breakage affecting unencrypted
HTTP/2 (h2c) connections caused by a security patch included in last
patch release.
See go.dev/issue/80876 for details.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Notable changes:
- Add bidirectional `log/slog` integration with a Logrus hook and `slog.Handler`.
- Add minimal, composable logging interfaces for individual log levels.
- Fix reentrant logging deadlocks and improve concurrency safety around formatters, hooks, and entries.
- Fix generic `Log`, `Logf`, `Logln`, and `LogFn` methods unexpectedly panicking at `PanicLevel`.
- Allow `Entry.Caller` to be set explicitly and preserved across derived entries.
- Improve `TextFormatter` performance and reduce allocations significantly.
- Improve common Logger and Entry hot paths and caller-reporting performance.
- Update `TextFormatter` handling for `[]byte`, debug/trace colors, and Windows ANSI terminals.
- Raise the minimum supported Go version to Go 1.23.
- Deprecate `Entry.HasCaller` and `MutexWrap`.
release-notes: https://github.com/sirupsen/logrus/releases/tag/v1.10.0
release-notes: https://github.com/sirupsen/logrus/releases/tag/v1.10.1
full diff: https://github.com/sirupsen/logrus/compare/v1.9.4...v1.10.1
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This release includes 10 security fixes following the security policy:
- x/mod/sumdb/tlog: fix transparency log tile verification bypass
A malicious GOPROXY was previously capable of forging
up to two sumdb tiles that allow for a requested module
to bypass the GOSUMDB check and persist attacker-controlled
module content to a local Go module cache.
This attack allows for a malicious GOPROXY to serve
malicious module content that cannot be detected
by evaluating the transparency log.
All tiles are now correctly verified against their parents.
In order to determine if you have been affected:
rm -r go.sum go.work.sum vendor/ && go mod tidy
Thanks to Filippo Valsorda (Geomys) for reporting this issue.
This is CVE-2026-56865 and Go issue https://go.dev/issue/80744.
- x/mod/sumdb: ignore unrelated, unauthenticated hashes in Lookup
A malicious GOSUMDB was capable of serving arbitrary
module content not contained within the transparency
log.
This attack allows for a coordinating GOPROXY and
GOSUMDB to serve a client malicious module content
that cannot be detected by evaluating the transparency
log.
In order to determine if you have been affected:
rm -r go.sum go.work.sum vendor/ && go mod tidy
Thanks to mundur for reporting this issue.
This is CVE-2026-56864 and Go issue https://go.dev/issue/80745.
- encoding/xml: add recursion depth guard during decode
Previously, DecodeElement would reset the depth counter
causing it to never fire; this could lead to stack
exhaustion.
This is CVE-2026-56859 and Go issue https://go.dev/issue/80481.
net/http: apply ReadHeaderTimeout when doing unencrypted HTTP/2 check
When a server is configured to support unencrypted HTTP/2, it reads a
few bytes from each new connection to see if they contain the HTTP/2
client preface. Previously, this was being done with no timeout applied.
ReadHeaderTimeout is now applied for this.
This is CVE-2026-56853 and Go issue https://go.dev/issue/80205.
- net/url: avoid quadratic complexity in resolvePath
Previously, resolving relative paths containing parent directory (..) segments performed string conversions and buffer rewrites on each step, resulting in quadratic time complexity and high memory allocation overhead.
Now, path resolution operates on a byte buffer using index-based backtracking for .. segments, eliminating the quadratic time complexity and significantly reducing memory allocations.
This is CVE-2026-56860 and Go issue https://go.dev/issue/80494.
- golang.org/x/net/dns/dnsmessage: panic when parsing invalid SVCB record
Parsing an invalid SVCB or HTTPS RR can panic when
the size of a parameter value overflows the message buffer.
Thanks to Mundur (https://github.com/M0nd0R) for reporting this issue.
This is CVE-2026-46600 and Go issue https://go.dev/issue/79795.
- crypto/tls: limit handshake messages we are willing to accept post-handshake
Previously, we always counted handshake messages, such as KeyUpdate, as
state-advancing, regardless of whether a handshake has been completed or
not. As a result, a malicious client can keep sending KeyUpdate messages
to force the server to keep performing key derivation operations
indefinitely.
Thanks to Qi Deng of Aurascape.ai for reporting this issue.
This is CVE-2026-56862 and Go issue https://go.dev/issue/80528.
- html/template: fix Javascript regexp context tracking
Previously, pathological inputs could close an
unescaped / early, allowing for attack-controlled
data to inject arbitrary content, potentially
leading to XSS.
Thanks to Ali Sherif for reporting this issue.
This is CVE-2026-56858 and Go issue https://go.dev/issue/80435.
- x/net/idna: failure to reject ASCII-only Punycode-encoded labels
The ToASCII and ToUnicode functions incorrectly accepted Punycode-encoded labels
that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com")
incorrectly returned the name "example.com" rather than an error.
The idna package implements the processing algorithm from UTS 46.
Older versions of UTS 46 included a specification bug which permitted
multiple ASCII labels to decode to the same Unicode label.
UTS 46 revision 33 fixed the specification bug.
The idna package now implements the updated specification.
This behavior can lead to privilege escalation in programs using the idna package.
For example, a program which performs privilege checks on the ASCII hostname
may reject "example.com" but permit "xn--example-.com". If that program subsequently
converts the ASCII hostname to Unicode, it will inadvertently permits access
to the Unicode name "example.com".
Thanks to KC1zs4 (https://github.com/KC1zs4) for reporting this issue.
This is CVE-2026-39821 and Go issue https://go.dev/issue/78760.
- encoding/asn1: enforce maximum recursion depth
Enforce a recursion limit in Unmarshal to prevent stack exhaustion
when parsing deeply-nested, recursive structures.
Thanks to Marwan Atia (marwans...@gmail.com) for reporting this issue.
This is CVE-2026-33818 and Go issue https://go.dev/issue/80405.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 55fcffe743 added normalization
in config/configfile, so it's no longer needed to normalize here as
well.
updates 55fcffe743
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
`comparePorts` compared host IPs with `i.IP.String() < j.IP.String()`, which
sorts them lexicographically, so "10.0.0.2" ordered before "9.0.0.1" in
`docker ps` output.
This also avoids formatting both addresses as strings on every comparison.
ports before after
64 1540 allocs/op 394 allocs/op
256 5364 allocs/op 1548 allocs/op
That's a ~74% (3.9x) reduction in allocations.
Signed-off-by: Hamir <hirehamir@gmail.com>
Both makeEnv and updateHosts removed elements from a slice while ranging
over that same slice. The range expression is evaluated once, so after a
removal the loop keeps using the original length: it reads stale elements
that shifted down, skips a live element, and can slice past the end of the
shrunken slice, which panics.
In makeEnv, the "no update required" continue also applied to the inner
loop instead of skipping the re-append, so an env-var passed twice with
the same value was stored twice. A third occurrence with a different value
then tried to remove both entries and panicked:
docker service create --env A=1 --env A=1 --env A=2 --name repro nginx
panic: runtime error: slice bounds out of range [2:1]
The same happens with an env-file that lists a variable twice, and the
panic occurs before any API call, so no daemon is needed to hit it.
updateHosts has the same problem when a hostname is listed more than once
in a single entry: --host-rm either leaves a copy behind or panics with
"slice bounds out of range". That needs a spec written through the API or
swarmkit directly, as the CLI does not produce such entries itself, so it
is less likely to be hit in practice.
Use slices.DeleteFunc for both, which removes every match in one pass, and
add tests for makeEnv, which had no coverage.
Signed-off-by: Madan Kumar <winklemad@outlook.com>
full diff: https://github.com/moby/go-archive/compare/v0.2.1...v0.3.0
v0.3.0
This release fixes CVE-2026-17106 / GHSA-hfg8-hc9c-6c3h, where a crafted
tar archive could use links to cause extraction operations to create or
overwrite files outside the intended destination directory.
The issue affected Unpack, UnpackLayer, Untar, UntarUncompressed, and the
ApplyLayer helpers. Users should upgrade and avoid extracting untrusted
archives with earlier versions.
What's Changed
* archive: harden tar extraction against path traversal
* archive: do not follow reparse points in chtimes
* archive: fix creation time updates on Windows
* archive: minor cleanups and godoc touch-up
* archive: RebaseArchiveEntries: fix archive path rebasing
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Relevant changes (in vendor):
- bpf: add security considerations to package docs
- http2: initialize Transport on NewClientConn
fixes: x/net/http2: zero Transport not ready for use
- idna: reject all-ASCII xn-- labels on all Go versions
fixes x/net/idna: ToUnicode accepts Punycode labels encoding pure ASCII labels
full diff: https://github.com/golang/net/compare/v0.56.0...v0.57.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- cpu: handle vendor suffixes in parseRelease
- unix: update glibc to 2.43
- unix: use epoll_pwait rather than epoll_wait
- windows: avoid length overflow in NewNTString
- windows: document safe usage of TrusteeValue
full diff: https://github.com/golang/sys/compare/v0.46.0...v0.47.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The migration to the generated (V2) shell completions dropped the
"--filter" key/value suggestions that the legacy bash completion used to
provide for the swarm commands, so e.g. "docker service ps <service>
--filter <TAB>" no longer completed anything.
Register filter completions for "docker service ps", "docker service
ls", and "docker node ps", following the same approach as the existing
completion for "docker events --filter".
Signed-off-by: Jess Thrysoee <jess@thrysoee.dk>
opts/weightdevice.go and opts/throttledevice.go had no tests, unlike the
sibling opts. Add table-driven coverage for ValidateWeightDevice,
ValidateThrottleBpsDevice, ValidateThrottleIOpsDevice and the Set/GetList
paths, including boundary (weight 0/10/1000/overflow) and error cases.
Signed-off-by: Nikolaus Schuetz <nikolauspschuetz@gmail.com>
The development and e2e containers hard-code /var/run/docker.sock, so
rootless and other local contexts cannot expose their daemon socket.
Resolve the active context's Docker endpoint and strip the unix scheme
before using it as the bind source.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
`workflows` is not a supported GITHUB_TOKEN permission key, so GitHub
rejects the workflow definition. Use the valid `actions` permission
for both jobs.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Without it GitHub rejects the push:
```
refusing to allow a GitHub App to create or update workflow `.github/workflows/build.yml` without `workflows` permission
```
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The workflow previously inferred its target from the dispatch ref,
requiring operators to always sync the release branch with the
workflow/scripts on master.
Accept the release branch as an input, keep the dispatched master
checkout as the script source, and merge in a detached worktree at the
selected release revision.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The project was sunset;
> After more than a decade of serving the ecosystem, the time
> has come to sunset Go Report Card. Following the loss of our
> primary infrastructure sponsor, maintaining the web app is
> no longer sustainable.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add a manually dispatched workflow for maintainers to sync a Docker
release branch to a selected release tag.
The sync-release-branch job checks out the release branch, computes
the list of unmerged tags up to the requested tag via
scripts/unmerged-tags, merges them in order via scripts/sync-branch
using git merge --no-ff (resolving conflicts by taking the tag's
content), then pushes the result to a temporary branch.
The push-release-branch job runs after manual approval via the
docker-releases environment. It verifies that neither the release
branch nor the temporary branch moved since the sync job ran before
force-advancing the release branch and deleting the temporary branch.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
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>
go1.26.5 (released 2026-07-07) includes security fixes to the crypto/tls
and os packages, as well as bug fixes to the compiler, the runtime, the
go command, and the net, os, and syscall packages. See the Go 1.26.5
milestone on our issue tracker for details;
- https://github.com/golang/go/issues?q=milestone%3AGo1.26.5+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.26.4...go1.26.5
From the security announcement:
We have just released Go versions 1.26.5 and 1.25.12, minor point releases.
These releases include 2 security fixes following the security policy:
- os: Root escape via symlink plus trailing slash
On Unix systems, opening a file in an os.Root improperly
followed symlinks to locations outside of the Root when
the final path component of the a path is a symbolic link
and the path ends in /.
For example, root.Open("symlink/") would open "symlink"
even when "symlink" is a symbolic link pointing outside of the root.
On Unix, openat(fd, path, O_NOFOLLOW) will follow symlinks
in path when path ends in a /. Root failed to account for
this behavior, permitting paths with a trailing / to escape.
It now properly sanitizes the path parameter provided to openat.
hanks to Mundur for reporting this issue.
This is CVE-2026-39822 and Go issue https://go.dev/issue/79005.
- crypto/tls: Encrypted Client Hello privacy leak
he Encrypted Client Hello implementation would leak the pre-shared key
dentities during the handshake, allowing a passive network observer who can
ollect handshakes to de-anonymize the hostname of the server, even when ECH was
eing used.
Thanks to Coia Prant (github.com/rbqvq) for reporting this issue.
This is CVE-2026-42505 and Go issue https://go.dev/issue/79282.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
PromptUserForCredentials accepted a Cli as argument so that it could swap
the input stream on Windows (cli.SetIn).
Given that we only require this swap for the duration of this function (if
needed at all), we can use a local variable that either uses cli.In() or
os.Stdin (on Windows).
We currently still need to wrap the os.Stdin into a streams.In, but can use
the raw os.Stdin (and/or cli.In().File()) once prompt.DisableInputEcho is
updated.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add a concurrency group keyed on PR number to prevent duplicate reviews
from simultaneous review_requested events.
Remove the sender.type != 'Bot' guard so Dependabot PRs remain
reviewable — per maintainer feedback, those reviews are useful for
catching behavior changes in dependency updates.
Signed-off-by: Derek Misler <derek.misler@docker.com>
- user: prevent possible DoS via unbounded parsing of user and group
database files in GHSA-mjcv-p78q-w5fw. This fixes a similar issue
as CVE-2026-47262 in containerd.
- user: prevent falling back to looking up numeric usernames
Improve handling of numeric user/group to prevent looking up numeric
values as usernames. This fixes a similar issue as [CVE-2026-46680] in
containerd.
- user: update minimum go version to go1.18
- assorted testing and linting fixes.
[CVE-2026-46680]: https://github.com/advisories/GHSA-fqw6-gf59-qr4w
full diff: https://github.com/moby/sys/compare/user/v0.4.0...user/v0.4.1
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds an e2e regression test for authenticated pull/push against a private registry, covering the auth regression reported in docker/cli#5963.
Includes:
- New privateregistry service in the e2e Compose stack with htpasswd auth on port 5001, and --insecure-registry for the engine container.
- TestPullPushPrivateRepository test that verifies authenticated push/pull and rejects unauthenticated operations.
- Auth config and test credentials in e2e/testdata/registry/.
- 90-second retry loop for transient DNS/container startup races.
- Service health wait loop in scripts/test/e2e/run.
- Increase TestProcessTermination timeout from 10s to 20s for connhelper-ssh + engine 25 combination.
- Connhelper-ssh engine Dockerfile for private registry integration.
Signed-off-by: Lohit Kolluri <lohitkolluri@gmail.com>
Make sure the symlinks point to the same file; not if both are
identical (absolute or relative symlink); it's only for suppressing
the warning so not critical.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While the "-modfile=vendor.mod" is slightly more correct, using a
symlink allows for most of the go tools to work "as usual", just
without an acual `go.mod` being committed in the repository.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Follow-up to 8f7dc04070, which updated the
minimum Go version in vendor.mod, but did not adjust this script.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- update minimum go version to 1.24
- use os.OpenFile with O_FILE_FLAG_SEQUENTIAL_SCAN on Go 1.26+
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This release include 3 security fixes following the security policy:
- mime: quadratic complexity in WordDecoder.DecodeHeader
Decoding a maliciously-crafted MIME header containing many invalid
encoded-words could consume excessive CPU.
The MIME decoder now better handles this case.
Thanks to p4p3r (https://hackerone.com/p4p3r_hak) for reporting this issue.
This is CVE-2026-42504 and Go issue https://go.dev/issue/79217.
- net/textproto: arbitrary input are included in errors without any escaping
When returning errors, functions in the net/textproto package would
include its input as part of the error, without any escaping. Note that
said input is often controlled by external parties when using this
package naturally. For example, a net/http client uses ReadMIMEHeader
when parsing the headers it receive from a server.
As a result, an attacker could inject arbitrary content into the error.
Practically, this can result in an attacker injecting misleading
content, terminal control bytes, etc. into a victim's output or logs.
This is CVE-2026-42507 and Go issue https://go.dev/issue/79346
- crypto/x509: split candidate hostname only once
(*x509.Certificate).VerifyHostname previously called matchHostnames in a loop
over all DNS Subject Alternative Name (SAN) entries. This caused
strings.Split(host, ".") to execute repeatedly on the same input hostname.
With a large DNS SAN list, verification costs scaled quadratically based on the
number of SAN entries multiplied by the hostname's label count. Because
x509.Verify validates hostnames before building the certificate chain, this
overhead occurred even for untrusted certificates.
Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue.
This is CVE-2026-27145 and https://go.dev/issue/79694.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.26.4
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This makes it easier to verify the sha matches the tag, and may help
with dependabot not updating the version-comment correctly.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Reduces the binary size (39810466 - 39289106 => 521360 (521 kb)
We only import google.golang.org/grpc as an indirect dependency, and
do not make gRPC connections.
grpcnotrace avoids importing golang.org/x/net/trace, which in turn enables
dead code elimination, which can yield 10-15% improvements in binary size
when tracing is not needed.
see https://github.com/grpc/grpc-go/blob/v1.81.1/trace_notrace.go#L23-L25
Before:
ls -l ./build/docker-darwin-arm64
-rwxr-xr-x 1 thajeztah staff 39810466 May 22 11:44 ./build/docker-darwin-arm64*
ls -lh ./build/docker-darwin-arm64
-rwxr-xr-x 1 thajeztah staff 38M May 22 11:44 ./build/docker-darwin-arm64*
After:
ls -l ./build/docker-darwin-arm64
-rwxr-xr-x 1 thajeztah staff 39289106 May 22 11:45 ./build/docker-darwin-arm64*
ls -lh ./build/docker-darwin-arm64
-rwxr-xr-x 1 thajeztah staff 37M May 22 11:45 ./build/docker-darwin-arm64*
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
security changes (not used in our code)
- html: escape greater-than symbol in doctype identifiers (CVE-2026-25681)
- html: improve Noah's Ark clause performance (CVE-2026-25680)
- html: properly render fostered elements in foreign content (CVE-2026-42502)
- html: properly check namespace in "in body" any other end tag (CVE-2026-42506)
- html: ignore duplicate attributes during tokenization (CVE-2026-27136)
other changes:
- quic: fix appendMaxDataFrame erroneously accumulating sentLimit
- quic: establish a "happened-before" relationship between stream write and read
- quic: fix buffer slicing when handling overlapping stream data
- http2: avoid API changes when built with go1.27
security announce: https://groups.google.com/g/golang-announce/c/iI-mYSI0lu8
full diff: https://github.com/golang/net/compare/v0.54.0...v0.55.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
update contributing guide link and improve PR template formatting in `.github/PULL_REQUEST_TEMPLATE.md`
Signed-off-by: Paulchen <lukas.23022005@gmail.com>
Signed-off-by: Lukas Michael <lukas.23022005@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The instructions in the file were outdated, and after removing them,
nothing really substantial was remaining, so let's just remove the
file for now.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use a shorter name, which is more idiomatic, and prevents accidental
shadowing of types or arguments.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: https://github.com/golang/sys/compare/v0.43.0...v0.44.0
- unix: add CPUSetDynamic for systems with more than 1024 CPUs
- unix: avoid nil pointer dereference in Utime
- unix: automatically remove container created by mkall.sh
- cpu: use IsProcessorFeaturePresent to calculate ARM64 on windows
- windows: add GetIfTable2Ex, GetIpInterface{Entry,Table}, GetUnicastIpAddressTable
- windows: avoid uint16 overflow in NewNTUnicodeString
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- opts.ParseRestartPolicy: use a struct-literal and clarify that this
function only parses, but does not validate invalid combinations.
- cli/compose/convert: convertRestartPolicy: update doc to be more
clear on the order of preference and intent.
- cli/compose/convert: convertRestartPolicy: use a switch based on
known values to allow the exhaustive linter to catch missing options.
- cli/compose/convert: convertRestartPolicy: add validation for negative
values when converting the legacy service.restart policy.
- cli/compose/convert: convertRestartPolicy: always set MaxAttempts
and leave validation to the daemon.
opts: ParseRestartPolicy: improve validation of max restart-counts
Use the new container.ValidateRestartPolicy utility to verify if a max-restart-count
is allowed for the given restart-policy.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before:
docker run --rm --env-file=./no-such-file alpine
docker: open ./no-such-file: no such file or directory
Run 'docker run --help' for more information
After:
docker run --rm --env-file=./no-such-file alpine
docker: --env-file: open ./no-such-file: no such file or directory
Run 'docker run --help' for more information
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adds a "Response body size and partial buffering" subsection to
docs/extend/plugins_authorization.md documenting the 64 KiB
maxBufferSize constant in the daemon's internal responseModifier
(pkg/authorization/response.go in moby/moby) and the practical
implications for plugins that use ResponseBody inspection.
The existing docs (lines 81-87) say streaming endpoints such as
logs and events send only the HTTP request to plugins, but don't
explain the underlying mechanism. Plugin authors building
response-body redaction or content-filtering can be surprised when
the same effect happens on non-listed endpoints whose response is
produced through multiple writes exceeding the buffer or via an
io.WriteFlusher.
The 64 KiB buffer is observable from the public moby source, so
this PR is documentation catching up to existing behavior — not
a contract change.
Signed-off-by: Matteo Panzeri <matteo1782@gmail.com>
This release include 11 security fixes:
- cmd/go: malicious module proxy can bypass checksum database
A malicious module proxy could exploit a flaw in the go command's
validation of module checksums to bypass checksum database validation.
This vulnerability affects any user using an untrusted module proxy
(GOMODPROXY) or checksum database (GOSUMDB).
A malicious module proxy can serve altered versions of the Go toolchain.
When selecting a different version of the Go toolchain than the
currently installed toolchain (due to the GOTOOLCHAIN environment variable,
or a go.work or go.mod with a toolchain line), the go command will download
and execute a toolchain provided by the module proxy. A malicious module
proxy can bypass checksum database validation for this downloaded
toolchain.
Since this vulnerability affects the security of toolchain downloads,
setting GOTOOLCHAIN to a fixed version is not sufficient. You must upgrade
your base Go toolchain.
The go tool always validates the hash of a toolchain before executing it,
so fixed versions will refuse to execute any cached, altered versions of the
toolchain.
The go tool trusts go.sum files to contain accurate hashes of the current
module's dependencies. A malicious proxy exploiting this vulnerability to
serve an altered module will have caused an incorrect hash to be recorded
in the go.sum. Users who have configured a non-trusted GOPROXY can determine
if they have been affected by running "rm go.sum ; go mod tidy ; go mod verify",
which will revalidate all dependencies of the current module.
The specific flaw in more detail:
The go command consults the checksum database to validate downloaded modules,
when a module is not listed in the go.sum file. It verifies that the module hash
reported by the checksum database matches the hash of the downloaded module.
If, however, the checksum database returns a successful response that contains
no entry for the module, the go command incorrectly permitted validation to succeed.
A module proxy may mirror or proxy the checksum database, in which case the go
command will not connect to the checksum database directly. Checksums reported
by the checksum database are cryptographically signed, so a malicious proxy
cannot alter the reported checksum for a module. However, a proxy which returns
an empty checksum response, or a checksum response for an unrelated module,
could cause the go command to proceed as if a downloaded module has been validated.
The go command now properly checks checksum database responses to ensure
that the expected module signature is present, not just that if a signature is
present it matches the expectation.
Thanks to Mundur (https://github.com/M0nd0R) for reporting this issue.
This is CVE-2026-42501 and Go issue https://go.dev/issue/79070.
- net/http/httputil: ReverseProxy forwards queries with more than urlmaxqueryparams parameters
When used with a Rewrite function, or a Director function which parses query parameters,
ReverseProxy sanitizes the forwarded request to remove query parameters which are not
parsed by url.ParseQuery. ReverseProxy did not take ParseQuery's limit on the total number
of query parameters (controlled by GODEBUG=urlmaxqueryparams=N) into account.
This could permit ReverseProxy to forward a request containing a query parameter
that was not visible to the Rewrite function.
For example, the query "a1=x&a2=x&...&a10000=x&hidden=y" could forward the parameter
"hidden=y" while hiding it from the proxy's Rewrite function.
ReverseProxy now avoids forwarding parameters that exceed the ParseQuery limit.
This is CVE-2026-39825 and Go issue https://go.dev/issue/78948.
- net: panic in Dial and LookupPort when handling NUL byte on Windows
The Dial and LookupPort functions would panic on Windows when provided
with an input containing a NUL (0). These functions now return an error
rather than panicking.
This is CVE-2026-39836 and Go issue https://go.dev/issue/79006.
- net/mail: quadratic string concatenation in consumePhrase
Pathological inputs could cause DoS through consumePhrase
when parsing an email address according to RFC 5322.
This is CVE-2026-42499 and Go issue https://go.dev/issue/78987.
- net/mail: quadratic string concatentation in consumeComment
Well-crafted inputs reaching ParseAddress, ParseAddressList,
and ParseDate were able to trigger excessive CPU exhaustion
and memory allocations.
This is CVE-2026-39820 and Go issue https://go.dev/issue/78566.
- cmd/go: "go bug" follows symlinks in predictable temporary filenames
The "go bug" command wrote to two files with predictable names in
the system temporary directory (for example, "/tmp").
An attacker with access to the temporary directory could create a
symlink in one of these names, causing "go bug" to overwrite the
target of the symlink.
The "go bug" command now uses os.MkdirTemp to create a safe
working directory.
Thanks to Harshit Gupta (Mr HAX) for reporting this issue.
This is CVE-2026-39819 and Go issue https://go.dev/issue/78584.
- cmd/go: "go tool pack" does not sanitize output paths
The "go tool pack" subcommand is a minimal version of the Unix ar utility.
It is used by the compiler as an internal tool with known-good inputs.
The "pack" subcommand did not sanitize output filenames.
When invoked to extract a malicious archive file, it could write
files to arbitrary locations on the filesystem.
The "pack" subcommand now refuses to extract files with names
containing any directory components.
Thanks to Harshit Gupta (Mr HAX) for reporting this issue.
This is CVE-2026-39817 and Go issue https://go.dev/issue/78778.
- net/http: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE
When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of
writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a
value of 0.
This allows potential DoS against a client by a malicious server. HTTP/2
transport now properly checks that the received SETTINGS_MAX_FRAME_SIZE is
valid.
Thanks to Marwan Atia (marwansamir688@gmail.com) for reporting this issue.
This is CVE-2026-33814 and Go issue https://go.dev/issue/78476.
- html/template: escaper bypass leads to XSS
If a trusted template author were to write a
tag containing an empty type attribute or a type
attribute with an ASCII whitespace, the execution of
the template would incorrectly escape any data passed
into the block.
Thanks to Mundur (https://github.com/M0nd0R) for reporting this issue.
This is CVE-2026-39826 and Go issue https://go.dev/issue/78981.
- net: crash when handling long CNAME response
When using LookupCNAME with the cgo DNS resolver,
a very long CNAME response could trigger a double-free of C memory
and a crash. The double-free has been fixed.
Thanks to hamayanhamayan for reporting this issue.
This is CVE-2026-33811 and Go issue https://go.dev/issue/78803.
- html/template: bypass of meta content URL escaping causes XSS
CVE-2026-27142 fixed a vulnerability in which URLs were not
correctly escaped inside of a tag's attribute.
If the URL content were to insert ASCII whitespaces around the
= rune inside of the attribute, the escaper would
fail to similarly escape it, leading to XSS.
Dynamic inputs to a tag's attribute are now
whitespace sanitized prior to escaping.
Thanks to Samy Ghannad for reporting this issue.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Previously, normalization was done before calling these functions,
which required implementations to normalize before using.
Move the normalization into the GetAuthConfig, GetCredentialsStore,
so that non-normalized hostnames will be able to resolve the correct
auth.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Several Labels() methods iterated over maps without sorting, producing
non-deterministic output.
In early versions of Go, map iteration order happened to be stable in
practice, so the original code appeared to work correctly.
Since Go 1.12, the runtime intentionally randomizes map iteration order,
making the output unpredictable between runs.
The API response produces sorted labels and the container formatter
already sorted its labels (changed in 5ee17eef).
Apply the same fix to the volume, network, config, and secret
formatters, and update tests to assert exact ordering instead of using
order-independent comparison.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Ensure PRs have a milestone set and that it matches the next release
version declared in the root VERSION file.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
go1.26.2 (released 2026-04-07) includes security fixes to the go command,
the compiler, and the archive/tar, crypto/tls, crypto/x509, html/template,
and os packages, as well as bug fixes to the go command, the go fix command,
the compiler, the linker, the runtime, and the net, net/http, and net/url
packages. See the Go 1.26.2 milestone on our issue tracker for details;
- https://github.com/golang/go/issues?q=milestone%3AGo1.26.2+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.26.1...go1.26.2
From the security announce:
We have just released Go versions 1.26.2 and 1.25.9, minor point releases.
These releases include 10 security fixes following the security policy:
- os: Root.Chmod can follow symlinks out of the root on Linux
On Linux, if the target of Root.Chmod is replaced with a symlink while
the chmod operation is in progress, Chmod could operate on the target
of the symlink, even when the target lies outside the root.
The Linux fchmodat syscall silently ignores the AT_SYMLINK_NOFOLLOW flag,
which Root.Chmod uses to avoid symlink traversal. Root.Chmod checks its
target before acting and returns an error if the target is a symlink
lying outside the root, so the impact is limited to cases where the
target is replaced with a symlink between the check and operation.
On Linux, Root.Chmod now uses the fchmodat2 syscall when available, and
an workaround using /proc/self/fd otherwise.
Thanks to Uuganbayar Lkhamsuren for reporting this issue.
This is CVE-2026-32282 and Go issue https://go.dev/issue/78293.
- html/template: JS template literal context incorrectly tracked
Context was not properly tracked across template branches for JS template
literals, leading to possibly incorrect escaping of content when branches were
used.
Additionally template actions within JS template literals did not properly
track
the brace depth, leading to incorrect escaping being applied.
These issues could cause actions within JS template literals to be incorrectly
or improperly escaped, leading to XSS vulnerabilities.
This only affects templates that use template actions within JS template
literals.
This is CVE-2026-32289 and Go issue https://go.dev/issue/78331.
- crypto/x509: excluded DNS constraints not properly applied to wildcard domains
When verifying a certificate chain containing excluded DNS constraints, these
constraints are not correctly applied to wildcard DNS SANs which use a
different
case than the constraint.
For example, if a certificate contains the DNS name "*.example.com" and the
excluded DNS name "EXAMPLE.COM", the constraint will not be applied.
This only affects validation of otherwise trusted certificate chains, issued
by
a root CA in the VerifyOptions.Roots CertPool, or in the system certificate
pool.
This issue only affects Go 1.26.
Thank you to Riyas from Saintgits College of Engineering, k1rnt, @1seal for
reporting this issue.
This is CVE-2026-33810 and Go issue https://go.dev/issue/78332.
- cmd/compile: no-op interface conversion bypasses overlap checking
Previously, the compiler failed to unwrap pointers contained within
a no-op interface conversion leading to an incorrect determination
of a non-overlapping move.
To prevent unsafe move operations, the compiler will now unwrap all
such conversions before considering a move non-overlapping.
Thank you to Jakub Ciolek - https://ciolek.dev/ for reporting this issue.
This is CVE-2026-27144 and Go issue https://go.dev/issue/78371.
- cmd/compile: possible memory corruption after bound check elimination
Previously, slices and arrays accessed using induction variables
were sometimes incorrectly proved in-bound. If the induction variable
used for indexing were to overflow or underflow, it could allow access
to memory beyond the scope of the original slice or array.
To prevent this behavior, the compiler ensures that any mutated induction
variable that overflows/underflows with respect to its loop condition
is not used for bound check elimination.
Thank you to Jakub Ciolek - https://ciolek.dev/ for reporting this issue.
This is CVE-2026-27143 and Go issue https://go.dev/issue/78333.
- archive/tar: unbounded allocation when parsing old format GNU sparse map
tar.Reader could allocate an unbounded amount of memory when reading
a maliciously-crafted archive containing a large number of sparse
regions encoded in the "old GNU sparse map" format.
We now limit both the number of old GNU sparse map extension blocks,
and the total number of sparse file entries, regardless of encoding.
Thanks to Colin Walters (wal...@verbum.org) who initially reported this issue.
Thanks also to Uuganbayar Lkhamsuren (https://github.com/uug4na) and Jakub
Ciolek
who additionally reported this issue.
This is CVE-2026-32288 and Go issue https://go.dev/issue/78301.
- crypto/tls: multiple key update handshake messages can cause connection to
deadlock
If one side of the TLS connection sends multiple key update messages
post-handshake in a single record, the connection can deadlock, causing
uncontrolled consumption of resources. This can lead to a denial of service.
This only affects TLS 1.3.
Thank you to Jakub Ciolek - https://ciolek.dev/ for reporting this issue.
This is CVE-2026-32283 and Go issue https://go.dev/issue/78334.
- cmd/go: trust layer bypass when using cgo and SWIG
A well-crafted SWIG source file could take advantage
of a file-naming convention used inside the trust
boundary of the cgo compiler. Doing so could result
in arbitrary code execution during build time.
SWIG files are disallowed from using this convention.
Thank you to Juho Forsén of Mattermost for reporting this issue.
This is CVE-2026-27140 and Go issue https://go.dev/issue/78335.
- crypto/x509: unexpected work during chain building
During chain building, the amount of work that is done is not correctly
limited
when a large number of intermediate certificates are passed in
VerifyOptions.Intermediates, which can lead to a denial of service. This
affects
both direct users of crypto/x509 and users of crypto/tls.
Thank you to Jakub Ciolek - https://ciolek.dev/ for reporting this issue.
This is CVE-2026-32280 and Go issue https://go.dev/issue/78282.
- crypto/x509: inefficient policy validation
Validating certificate chains which use policies is unexpectedly inefficient
when certificates in the chain contain a very large number of policy mappings,
possibly causing denial of service.
This only affects validation of otherwise trusted certificate chains, issued
by
a root CA in the VerifyOptions.Roots CertPool, or in the system certificate
pool.
Thank you to Jakub Ciolek - https://ciolek.dev/ for reporting this issue.
This is CVE-2026-32281 and Go issue https://go.dev/issue/78281.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
Use the new tree view by default and only fallback if format or old
view-related options are used.
The expanded view is shown when `--tree` is passed.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The logic for applying the dangling filter when `--all` is not used was
inverted. The filter was being applied when the dangling filter was
present, but it should be applied when the dangling filter is NOT
present.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Sort images alphabetically by their repository tags rather than by
creation date.
When an image has multiple tags, they are sorted internally and the
first tag is used as the representative for sorting the image in the
list. Untagged images are placed at the end.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Use separate branches to handle windows/unix results to reduce intermediate
variables, and make it more transparent what's set for each platform.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
construct the decoder inside the go-routine, including closing the body,
and add handling for context-cancellation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We should consider splitting this out to a separate function, but
start with just an early return before we hit the timer-loop.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The JSON field was added in [moby@9fd2c0f], to address [moby#19177], which
reported an incompatibility with Classic (V1) Swarm, which produced a non-
standard response;
> Make docker load to output json when the response content type is json
> Swarm hijacks the response from docker load and returns JSON rather
> than plain text like the Engine does. This makes the API library to return
> information to figure that out.
A later change in [moby@96d7db6] added additional logic to make sure the
correct content-type was returned, depending on whether the `quiet` option
was set (which produced a non-JSON response). This caused inconsistency in
the API response, and [moby@2f27632] changed the endpoint to always produce
JSON (only skipping the "progress" output if `quiet` was set).
This means that the "load" endpoint ([`imageRouter.postImagesLoad`]) now
unconditionally returns JSON, making the `JSON` field fully redundant.
This patch removes the use of the JSON field, as it's redundant, and the way it handles
the content-type is incorrect because it would not handle correct, but different
formatted response-headers (`application/json; charset=utf-8`), which could
result in malformed output on the client.
[moby@9fd2c0f]: https://github.com/moby/moby/commit/9fd2c0feb0c131d01d727d50baa7183b976c7bdc
[moby#19177]: https://github.com/moby/moby/issues/19177
[moby@96d7db6]: https://github.com/moby/moby/commit/96d7db665b06cc0bbede22d818c69dc5f6921f66
[moby@2f27632]: https://github.com/moby/moby/commit/2f27632cde2f0e514bd3a8de77cc1934e5193a83
[`imageRouter.postImagesLoad`]: https://github.com/moby/moby/blob/7b9d2ef6e5518a3d3f3cc418459f8df786cfbbd1/api/server/router/image/image_routes.go#L248-L255
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This field is set for the request as a whole, so can be obtained
from the server-info instead. Docker v29 will provide per-stats
information.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This change prevents changes to the otel version from affecting the otel
sdk version. This is done by copying the telemetry sdk implementation
locally and using our own choice for semconv from within that.
This prevents a schema conflict from happening since the otel version of
the sdk gets implicitly updated whenever the semconv changes while we
have to manually change ours. Now, we manually change both and they're
locked to each other.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `--tree` implementation already does this.
Make the behavior consistent for the legacy image list implementation.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
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>
This release addresses breakage caused by a security patch included in
Go 1.25.2 and 1.24.8, which enforced overly restrictive validation on
the parsing of X.509 certificates. We've removed those restrictions
while maintaining the security fix that the initial release addressed.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This utility was used internally and will be removed in the next release.
Use `DetectContextType` to detect the context-type, and use `GetContextFromLocalDir`,
`GetContextFromLocalDir`, `GetContextFromGitURL`, or `GetContextFromURL`
instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
follow-up to f81816ef88
We could decide to not initialize a default, and do this only when
setting a value, but this may require more changes, so doing this
as a starting-point.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was added in 7405ac5c2d as
a fallback for API < v1.41, which did not include the service status
in the response. Current API versions return this information, so there's
no need to fetch it manually.
It was not gated by API version for some tests (which didn't set API
version), but should not be needed for non-test situations.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- fix minor linting issues (unhandled errors)
- rename vars to prevent shadowing
- use sub-tests for tests that already prepared for it
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This minor release includes 10 security fixes following the security policy:
- net/mail: excessive CPU consumption in ParseAddress
The ParseAddress function constructed domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this could cause excessive CPU consumption.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2025-61725 and Go issue https://go.dev/issue/75680.
- crypto/x509: quadratic complexity when checking name constraints
Due to the design of the name constraint checking algorithm, the processing time
of some inputs scales non-linearly with respect to the size of the certificate.
This affects programs which validate arbitrary certificate chains.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-58187 and Go issue https://go.dev/issue/75681.
- crypto/tls: ALPN negotiation errors can contain arbitrary text
The crypto/tls conn.Handshake method returns an error on the server-side when
ALPN negotation fails which can contain arbitrary attacker controlled
information provided by the client-side of the connection which is not escaped.
This affects programs which log these errors without any additional form of
sanitization, and may allow injection of attacker controlled information into
logs.
Thanks to National Cyber Security Centre Finland for reporting this issue.
This is CVE-2025-58189 and Go issue https://go.dev/issue/75652.
- encoding/pem: quadratic complexity when parsing some invalid inputs
Due to the design of the PEM parsing function, the processing time for some
inputs scales non-linearly with respect to the size of the input.
This affects programs which parse untrusted PEM inputs.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-61723 and Go issue https://go.dev/issue/75676.
- net/url: insufficient validation of bracketed IPv6 hostnames
The Parse function permitted values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: "http://[::1]/". IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement.
Thanks to Enze Wang, Jingcheng Yang and Zehui Miao of Tsinghua University for reporting this issue.
This is CVE-2025-47912 and Go issue https://go.dev/issue/75678.
- encoding/asn1: pre-allocating memory when parsing DER payload can cause memory exhaustion
When parsing DER payloads, memories were being allocated prior to fully validating the payloads.
This permits an attacker to craft a big empty DER payload to cause memory exhaustion in functions such as asn1.Unmarshal, x509.ParseCertificateRequest, and ocsp.ParseResponse.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-58185 and Go issue https://go.dev/issue/75671.
- net/http: lack of limit when parsing cookies can cause memory exhaustion
Despite HTTP headers having a default limit of 1 MB, the number of cookies that can be parsed did not have a limit.
By sending a lot of very small cookies such as "a=;", an attacker can make an HTTP server allocate a large amount of structs, causing large memory consumption.
net/http now limits the number of cookies accepted to 3000, which can be adjusted using the httpcookiemaxnum GODEBUG option.
Thanks to jub0bs for reporting this issue.
This is CVE-2025-58186 and Go issue https://go.dev/issue/75672.
- crypto/x509: panic when validating certificates with DSA public keys
Validating certificate chains which contain DSA public keys can cause programs
to panic, due to a interface cast that assumes they implement the Equal method.
This affects programs which validate arbitrary certificate chains.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-58188 and Go issue https://go.dev/issue/75675.
- archive/tar: unbounded allocation when parsing GNU sparse map
tar.Reader did not set a maximum size on the number of sparse region data blocks in GNU tar pax 1.0 sparse files. A maliciously-crafted archive containing a large number of sparse regions could cause a Reader to read an unbounded amount of data from the archive into memory. When reading from a compressed source, a small compressed input could result in large allocations.
Thanks to Harshit Gupta (Mr HAX) - https://www.linkedin.com/in/iam-harshit-gupta/ for reporting this issue.
This is CVE-2025-58183 and Go issue https://go.dev/issue/75677.
- net/textproto: excessive CPU consumption in Reader.ReadResponse
The Reader.ReadResponse function constructed a response string through
repeated string concatenation of lines. When the number of lines in a response is large,
this could cause excessive CPU consumption.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-61724 and Go issue https://go.dev/issue/75716.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This warning is better handled by the daemon, where applicable, as
the client does not have all information available to determine
if using a localhost / loopback-address for the DNS is possible.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The ResolveDefaultContext function was exported in [cli@f820766] to allow
(unit) testing, but did not document that it was only exported for this
purpose. The only external use of this function is in buildx, which uses
it in a unit test that can be implemented without this function.
This patch deprecates the function so that we can remove it.
[cli@f820766]: https://github.com/docker/cli/commit/f820766f6ac57188d96c9ca377f2b4627e90da28
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's just a wrapper around WithAPIClient, and not needed for this
test, which validates that "Initialize" properly creates the context
store, even if a client was already set;
3b26cfce8b
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>
Support for daemon-side auto-remove was added in API v1.25; on older
versions of the daemon, the client was responsible for removing the
container after it exited (see [moby@6dd8e10])
On API versions < 1.30, it used the events API for this purpose, and
would wait for a "die", "detach" or "detroy" events to know the container
exited, and could be removed or (when attached, but without a TTY) to
get the container's exit-status. (see [cli@38591f2]).
API version 1.24 (docker 1.12) is 9 Years old (July 29, 2016), and API
1.30 (docker 17.06) is 8 Years old (Jun 20, 2017), and long EOL. While
technically, a CLI could negotiate API 1.30 or older, this would only
be in cases where either API version negotiation failed, or the version
was explicitly overridden through `DOCKER_API_VERSION` for testing.
Either of those cases would be rare, and not worth the technical complexity
to support. This patch removes support for AutoRemove on API < 1.30.
[moby@6dd8e10]: https://github.com/moby/moby/commit/6dd8e10d6ed7a7371c5c1824ad58c4403a7b3bfd
[cli@38591f2]: https://github.com/docker/cli/commit/38591f20d07795aaef45d400df89ca12f29c603b
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This utility was added in 9b83d5bbf9, but
was never used. Remove the utility, and rewrite the error returned to
implement the errdefs.NotFound interface, so that it can be detected
using the errdefs.IsNotFound() utility if needed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit [cli@27b2797] forked the AuthConfig type from the API, and changed
existing code to do a direct cast / convert of the forked type to the API
type. This can cause issues if the API types diverges, such as the removal
of the Email field.
This patch explicitly maps each field to the corresponding API type, but
adds some TODOs, because various code-paths only included a subset of the
fields, which may be intentional for fields that were meant to be handled
on the daemon / registry-client only.
We should evaluate these conversions to make sure these fields should
be sent from the client or not (and possibly even removed from the API
type).
[cli@27b2797]: https://github.com/docker/cli/commit/27b2797f7deb3ca5b7f80371d825113deb1faca1
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function is a wrapper around apiClient.ImagePull and not directly
related to docker content trust; it just happens to also be called
when using content trust (through the trustedPull utility).
Move it together with the `runPull` function to separate it from
trust-related code.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function is a wrapper around apiClient.ImagePull; the use of
trust.ImageRefAndAuth was out of convenience because it's also called
when using content trust (through the trustedPull utility).
Let's pull away the layers to separate it from trust code.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This interface is used in tests to provide a dummy notary client,
but none of the tests require any arguments, so let's remove them.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The IndexInfo was only used to detect if the target was an official
image, which we can deduct from the hostname. Adding some normalizing
just in case (but we should only get "docker.io" here).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Docker Hub's Notary service is being retired, and now produces
failures in most cases. Add a warning when attempting to use
it, pending full removal of trust;
https://www.docker.com/blog/retiring-docker-content-trust/
With this PR:
DOCKER_CONTENT_TRUST=1 docker pull -q hello-world
WARNING: Docker is retiring DCT for Docker Official Images (DOI).
For details, refer to https://docs.docker.com/go/dct-deprecation/
could not validate the path to a trusted root: unable to retrieve valid leaf certificates
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
All information needed can be deducted from the image reference, which
is used to create a indexInfo, repoInfo, and to resolve auth-config.
In some situations this may result in resolving the auth-config twice
after it already was resolved to an encoded auth-config.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The Apply command was deprecated in 24bfedf3f8,
and has no known external users, but we didn't remove it from the interface.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was used internally, but is no longer used.
This method was deprecated in 0270b2d6f7,
which was included in the 28.5.0 release, and has no known external users,
so removing it for 29.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These options were used internally as defaults for the constructor and
only impact commands implemented in the CLI itself.
They were deprecated in 40cdfc0d81, which
was included in the 28.5.0 release, so removing it for 29.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was used internally, but is no longer used. Users should check
the value of the `DOCKER_CONTENT_TRUST` environment variable instead.
This method was deprecated in 11d40488dd,
which was included in the 28.5.0 release, and has no known external users,
so removing it for 29.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was used internally, but is no longer used. Users should check
the value of the `DOCKER_CONTENT_TRUST` environment variable instead.
There are no known external users of this method, so already removing it
from the Cli interface; this method will be removed in the next release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is a follow-up to 7609dde8d0 and
3f5b1bdd32, which removed support for
DCT for build and plugin commands.
As these flags are just stubs, hidden by default and no longer functional,
they don't have to reflect the current state of DCT.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These options were used internally as defaults for the constructor and
only impact commands implemented in the CLI itself.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was used internally, but is no longer used. There are
no known users of this method, so already removing it from the Cli
interface.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add support to the `cli/command` package to accept a custom User
Agent to pass to the underlying client.
This is used as the `UpstreamClient` portion of the `User-Agent`
when the Moby daemon makes requests.
For example, pushing and pulling images with Compose might result
in the registry seeing a `User-Agent` value of:
```
docker/24.0.7 go/go1.20.10 git-commit/311b9ff kernel/6.5.13-linuxkit os/linux arch/arm64 UpstreamClient(docker-cli-plugin-compose/v2.24.0)
```
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The CLI currently hard-codes the schema-version for CLI plugins to
"0.1.0", which doesn't allow us to expand the schema for plugins.
As there's many plugins that we shipped already, we can't break
compatibility until we reach 2.0.0, but we can expand the schema
with non-breaking changes.
This patch makes the validation more permissive to allow new schema
versions <= 2.0.0. Note that existing CLIs will still invalidate
such versions, so we cannot update the version until such CLIs are
no longer expected to be used, but this patch lays the ground-work
to open that option.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this patch, a broken symlink would print a warning;
docker info > /dev/null
WARNING: Plugin "/Users/thajeztah/.docker/cli-plugins/docker-feedback" is not valid: failed to fetch metadata: fork/exec /Users/thajeztah/.docker/cli-plugins/docker-feedback: no such file or directory
After this patch, such symlinks are ignored:
docker info > /dev/null
With debug enabled, we don't ignore the faulty plugin, which will
make the warning shown on docker info;
mkdir -p ~/.docker/cli-plugins
ln -s nosuchplugin ~/.docker/cli-plugins/docker-brokenplugin
docker --debug info
Client:
Version: 29.0.0-dev
Context: default
Debug Mode: true
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.25.0
Path: /usr/libexec/docker/cli-plugins/docker-buildx
WARNING: Plugin "/Users/thajeztah/.docker/cli-plugins/docker-brokenplugin" is not valid: failed to fetch metadata: fork/exec /Users/thajeztah/.docker/cli-plugins/docker-brokenplugin: no such file or directory
# ...
We should als consider passing a "seen" map to de-duplicate entries.
Entries can be either a direct symlink or in a symlinked path (for
which we can filepath.EvalSymlinks). We need to benchmark the overhead
of resolving the symlink vs possibly calling the plugin (to get their
metadata) further down the line.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Currently, the plugin.Run command constructs the DockerCli using
the default options, assuming plugins run with all the same options
as the CLI itself; to customize the CLI there's a "Apply" option,
but this means mutating the CLI after it's already constructed, which
is not ideal.
This patch adds a variadic ops argument to allow CLI plugins to pass
custom options to use for the CLI, so that there's no need to mutate
its config in most cases.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The Apply method was added when CLI options for constructing the CLI were
rewritten into functional options in [cli@7f207f3]. There was no mention
in the pull request of this method specifically, and this may have been
related to work being done elsewhere on compose-on-kubernetes or the
compose-cli plugin that may have needed options to modify the CLI config
after it was already initialized.
We should try to remove functions that mutate the CLI configuration after
initialization if possible (and likely remove the `Apply` method); currently
this function is used in docker compose, but as part of a hack that can
probably be avoided.
[cli@7f207f3]: https://github.com/docker/cli/commit/7f207f3f957ed3f5129aeb22bef2a429c14caf22
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Mirantis Container Runtime (MCR) 23.0 reached EOL, and the next LTS
version of MCR is 25.x
- Docker 26.x reached EOL and is no longer maintained
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This code was added in 846ecf59ff as an
escape hatch in case the new OAuth login flow would cause problems.
We have not received reports where the new flow caused problems, and
searching the internet shows no mentions of the env-var.
This env-var was not documented, so we can remove it.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Configuration options for experimental CLI features were deprecated in
docker 19.03 (3172219932), and enabled by
default since docker 20.10 (977d3ae046).
This field was deprecated in c8f9187157,
which is part of the 28.x release, and is unused. This patch removes
the field.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This const was added in 846ecf59ff, but
only used internally; commit 18cdc25bb4
deprecated the const, which was included in the 28.4 release.
This patch removes the exported const, as it's unused.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This package was deprecated in 13010ba673,
and only used internally. The deprecation was included in the 28.4 release,
and there's no known external users, so we can remove it for v29.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit [moby@17d870b] (API v1.13, docker v1.1.0) changed the default to pause
containers during commit, keeping the behavior opt-in for older API versions.
This version-gate was removed in [moby@1b1147e] because API versions lower
than v1.23 were no longer supported.
This patch deprecates the `--pause` flag in favor of a `--no-pause` flag to
be more explicit on the default. The old `--pause` flag is marked deprecated
but still functional. Using the deprecated flag will print a warning, and an
error is produced when trying to use both the old and new flag;
docker commit --pause mycontainer
Flag --pause has been deprecated, and enabled by default. Use --no-pause to disable pausing during commit.
docker commit --pause=false mycontainer
Flag --pause has been deprecated, and enabled by default. Use --no-pause to disable pausing during commit.
docker commit --pause --no-pause mycontainer
Flag --pause has been deprecated, use --no-pause instead
conflicting options: --no-pause and --pause cannot be used together
[moby@17d870b]: https://github.com/moby/moby/commit/17d870bed5ef997c30da1e8b9843f4e84202f8d4
[moby@1b1147e]: https://github.com/moby/moby/commit/1b1147e46b732caeaed4ae365cd56ccbfdf40233
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `--kernel-memory` flag was still included to allow it to be used with
old API versions, but it's no longer supported by the kernel, and no longer
handled by OCI runtimes, so deprecating the flags.
With this patch, a deprecation warning is now produced when trying to use
the option;
docker run --kernel-memory 123b busybox
Flag --kernel-memory has been deprecated, this option is deprecated in the kernel and no longer supported
docker container create --kernel-memory 123b busybox
Flag --kernel-memory has been deprecated, and no longer supported by the kernel
31fb57e2c6434490a2892031602be20d0206d3cf0fc281ea25654c46dcb62bac
Note that cobra does not _fail_ the command when using deprecated options;
we could make this a hard failure instead, but may not be worth the effort.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This code was missing a check for the ID field before truncating it to a
shorter length for presentation. This would result in a panic if an event
would either have an empty ID field or a shorter length ID;
panic: runtime error: slice bounds out of range [:12] with length 0
goroutine 82 [running]:
github.com/docker/cli/cli/command/container.RunStats.func2({{0x0, 0x0}, {0x0, 0x0}, {0x0, 0x0}, {0x40001fcba0, 0x9}, {0x40001fcba9, 0x5}, ...})
/go/src/github.com/docker/cli/cli/command/container/stats.go:146 +0x1d0
created by github.com/docker/cli/cli/command/container.(*eventHandler).watch in goroutine 6
/go/src/github.com/docker/cli/cli/command/container/stats.go:363 +0x1c8
We need to look at this code in general; the truncated ID is passed to
NewStats, which uses the ID to propagate the `Container` field in the
`StatsEntry` struct. which is not used in the default format used by
`docker stats` and, having the same content as the `ID` field on the
same struct, doesn't make it very useful, other than being able to
present it under a `CONTAINER` column (instead of `CONTAINER ID`);
we should consider deprecating it; there may be some subtle things
to look into here; the `Container` field originally held the container
name. This was changed in [moby@ef915fd], which introduced separate
`ID` and `Name` fields, renaming the old `Name` field to container.
Looking at [`Stats.SetStatistics()`] and related code in [stats_helpers.go],
the `Container` field is used as the "canonical" reference for the stats
record; this allows the stats _data_ to be refreshed when a new stats
sample arrives for the same container (also see [moby@929a77b], which
moved locking to the `Stats` wrapper struct). This construct allows to
account for intermediate states, where a stats sample was incomplete
or could produce an error; in that case, the reference to the container
for which the stats were sampled is kept to allow removing a container
from the list once the container was removed. We should consider removing
`Container` as a formatting option, and moving the `Container` field to
the outer struct; this makes the outer struct responsible for keeping a
reference to the container, allowing the `StatsEntry` as a whole to be
replaced atomically.
This patch only addresses the panic;
- It changes the logic to preserve the container ID verbatim instead
of truncating. This allows stats samples to be matched against the
`Actor.ID` as-is.
- Truncating the `Container` is moved to the presentation logic;
currently this does not take `--no-trunc` into account to keep
the existing behavior, but we can (should) consider adding this.
- Logging is improved to use structured logs, and an extra check is
added to prevent empty IDs from being added as watcher.
[`Stats.SetStatistics()`]: https://github.com/docker/cli/blob/82281087e3e186c5a2eafa0d973e849ff84c357d/cli/command/container/formatter_stats.go#L88-L94
[moby@ef915fd]: https://github.com/moby/moby/commit/ef915fd036d9ea5263f9370dce490ef97ea0618d
[moby@929a77b]: https://github.com/moby/moby/commit/929a77b814dfe9ab7a11bffc2d16eebd27bd903a
[stats_helpers.go]: https://github.com/docker/cli/blob/82281087e3e186c5a2eafa0d973e849ff84c357d/cli/command/container/stats_helpers.go#L26-L51
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Use sub-tests
- Don't use un-named keys
- Add test-cases for 'Name', 'ID' and custom container names
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Name is a required argument for both "create" and "update", so better
to split it from the options struct.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's adding a slight indirection by constructing a function when called,
but makes the completion functions more consistent, the signature easier
to read, and making the return type a [cobra.CompletionFunc] makes it
more transparent what it's intended for, and helps discovery of functions
that provide completion.
[cobra.CompletionFunc]: https://pkg.go.dev/github.com/spf13/cobra#CompletionFunc
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's adding a slight indirection by constructing a function when called,
but makes the completion functions more consistent, the signature easier
to read, and making the return type a [cobra.CompletionFunc] makes it
more transparent what it's intended for, and helps discovery of functions
that provide completion.
[cobra.CompletionFunc]: https://pkg.go.dev/github.com/spf13/cobra#CompletionFunc
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's adding a slight indirection by constructing a function when called,
but makes the completion functions more consistent, the signature easier
to read, and making the return type a [cobra.CompletionFunc] makes it
more transparent what it's intended for, and helps discovery of functions
that provide completion.
[cobra.CompletionFunc]: https://pkg.go.dev/github.com/spf13/cobra#CompletionFunc
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's adding a slight indirection by constructing a function when called,
but makes the completion functions more consistent, the signature easier
to read, and making the return type a [cobra.CompletionFunc] makes it
more transparent what it's intended for, and helps discovery of functions
that provide completion.
[cobra.CompletionFunc]: https://pkg.go.dev/github.com/spf13/cobra#CompletionFunc
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This uses the DefaultShellCompDirective feature which was added
in cobra to override the default (which would complete to use
files for commands and flags).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This uses the DefaultShellCompDirective feature which was added
in cobra to override the default (which would complete to use
files for commands and flags).
Note that we set "cobra.NoFileCompletions" for many commands, which
is redundant with this change, so we could remove as well.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These commands accept two arguments; the first is a custom name,
the second is either a filename or "-" to create from STDIN.
With this patch:
# does not provide completion
docker secret create <tab>
# starts providing completion once a non-empty name is provided
docker secret create somename<tab>
file.txt other-file.txt
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The "docker inspect" command can inspect any type of object, which would
require all possible endpoints to be contacted. By default, we don't
provide completion, but if a `--type` is passed, we provide completion
for the given type.
For example, `docker inspect --type container` will complete container
names, `docker inspect --type volume` will complete volume names and
so on.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Similar to 323fbc485e - this code was added
in [moby@c127d96], but used string-matching to detect cases where a user
tried to install an image as plugin. However, this handling no longer matched
any error-strings, so no longer worked:
docker plugin install busybox
Error response from daemon: did not find plugin config for specified reference docker.io/library/busybox:latest
[moby@c127d96]: https://github.com/moby/moby/commit/c127d9614f5b30bd73861877f8540a63e7d869e9
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These were deprecated in ad6ab189a6 and
were only used internally. Move them back inside the stack package.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These were deprecated in ad6ab189a6 and
were only used internally. Move them back inside the stack package.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This warning was added in [moby@4a8b3ca] to print a warning when building
Linux images from a Windows client. Window's filesystem does not have an
"executable" bit, which mean that, for example, copying a shell script
to an image during build would lose the executable bit. So for Windows
clients, the executable bit would be set on all files, unconditionally.
Originally this was detected in the client, which had direct access to
the API response headers, but when refactoring the client to use a common
library in [moby@535c4c9], this was refactored into a `ImageBuildResponse`
wrapper, deconstructing the API response into an `io.Reader` and a string
field containing only the `OSType` header.
This was the only use and only purpose of the `OSType` field, and now that
BuildKit is the default builder for Linux images, this warning didn't get
printed unless BuildKit was explicitly disabled.
This patch removes the warning, so that we can potentially remove the
field, or the `ImageBuildResponse` type altogether.
[moby@4a8b3ca]: https://github.com/moby/moby/commit/4a8b3cad6096854027151dfbcfb4b2cd8841ad95
[moby@535c4c9]: https://github.com/moby/moby/commit/535c4c9a59b1e58c897677d6948a595cb3d28639
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This change updates the builder prune command to send the `ReservedSpace` parameter in preparation of `KeepStorage` deprecation in API v1.52.
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
We may still change this, but in the client module, the signature
of the client.Opt changed to now include a non-exported type, which
means that we can't construct a custom option that is implemented
using client options:
#18 16.94 # github.com/docker/cli/cli/context/docker
#18 16.94 cli/context/docker/load.go:105:29: cannot use withHTTPClient(tlsConfig) (value of type func(*client.Client) error) as client.Opt value in argument to append
#18 16.94 cli/context/docker/load.go:152:6: cannot use c (variable of type *client.Client) as *client.clientConfig value in argument to client.WithHTTPClient(&http.Client{…})
We can consider exporting the `client.clientConfig` type (but keep its
fields non-exported), but for this use, we don't strictly need it, so
let's change the implementation to not having to depend on that.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We may still change this, but in the client module, the signature
of the client.Opt changed to now include a non-exported type, which
means that we can't construct a custom option that is implemented
using client options:
#18 16.94 # github.com/docker/cli/cli/context/docker
#18 16.94 cli/context/docker/load.go:105:29: cannot use withHTTPClient(tlsConfig) (value of type func(*client.Client) error) as client.Opt value in argument to append
#18 16.94 cli/context/docker/load.go:152:6: cannot use c (variable of type *client.Client) as *client.clientConfig value in argument to client.WithHTTPClient(&http.Client{…})
We can consider exporting the `client.clientConfig` type (but keep its
fields non-exported), but for this use, we don't strictly need it, so
let's change the implementation to not having to depend on that.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This includes 1 security fix:
- net/http: CrossOriginProtection bypass patterns are over-broad
When passing patterns to CrossOriginProtection.AddInsecureBypassPattern,
requests that would have redirected to those patterns (e.g. without a trailing
slash) were also exempted, which might be unexpected.
Thanks to Marco Gazerro for reporting this issue.
This is CVE-2025-47910 and Go issue https://go.dev/issue/75054.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.24.7
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
With this patch, completion is provided for images already present
in the local image cache to help pulling the latest version of the
same tag;
docker pull go<tab>
golang:1.12 golang:1.18.0 golang:1.21 golang:1.24 gopher:latest
golang:1.13 golang:1.20 golang:1.23 golang:latest
docker pull golang:<tab>
1.12 1.13 1.18.0 1.20 1.21 1.23 1.24 latest
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The restrictedNamePattern was a basic regular expression. Replace it
with a minimal utility to do the same, without having to use regular
expressions (or the "lazyregexp" package).
Some quick benchmarking (not committed) show that the non-regex approach
is ~18x faster:
BenchmarkIsValidName_Regex_Valid-10 8516511 119.4 ns/op 0 B/op 0 allocs/op
BenchmarkIsValidName_Manual_Valid-10 172426240 6.964 ns/op 0 B/op 0 allocs/op
BenchmarkIsValidName_Regex_Invalid-10 34824540 34.22 ns/op 0 B/op 0 allocs/op
BenchmarkIsValidName_Manual_Invalid-10 550804021 2.173 ns/op 0 B/op 0 allocs/op
BenchmarkIsValidName_Regex_Parallel-10 69289900 17.30 ns/op 0 B/op 0 allocs/op
BenchmarkIsValidName_Manual_Parallel-10 1000000000 0.9296 ns/op 0 B/op 0 allocs/op
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The pluginNameRe was a basic regular expression, effectively only checking
if the name consisted of lowercase alphanumeric characters. Replace it
with a minimal utility to do the same, without having to use regular
expressions (or the "lazyregexp" package).
Some quick benchmarking (not committed) show that the non-regex approach
is ~25x faster:
BenchmarkIsValidPluginName_Regex_Valid-10 13956240 81.39 ns/op 0 B/op 0 allocs/op
BenchmarkIsValidPluginName_Manual_Valid-10 360003060 3.318 ns/op 0 B/op 0 allocs/op
BenchmarkIsValidPluginName_Regex_Invalid-10 35281794 33.74 ns/op 0 B/op 0 allocs/op
BenchmarkIsValidPluginName_Manual_Invalid-10 906072663 1.320 ns/op 0 B/op 0 allocs/op
BenchmarkIsValidPluginName_Regex_Parallel-10 96595677 12.04 ns/op 0 B/op 0 allocs/op
BenchmarkIsValidPluginName_Manual_Parallel-10 1000000000 0.4541 ns/op 0 B/op 0 allocs/op
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These consts and types were moved to a separate metadata package in commits
292713c887 and 4321293972,
and deprecated in 72f76f2720, 5876b2941c,
and 6fa7d18320.
This removes the deprecated aliases in `cli-plugins/manager` in favor of
their equivalent in `cli-plugins/manager/metadata`:
- `CommandAnnotationPlugin`
- `CommandAnnotationPluginVendor`
- `CommandAnnotationPluginVersion`
- `CommandAnnotationPluginInvalid`
- `CommandAnnotationPluginCommandPath`
- `NamePrefix`
- `MetadataSubcommandName`
- `HookSubcommandName`
- `Metadata`
- `ReexecEnvvar`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These errors satisfy errdefs.IsNotFound, which can be used instead. This
function was deprecated in 71460215d3 and
is no longer used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This const was added in 846ecf59ff, but
only used internally. This patch deprecates the const, to be removed
in the next release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This alias was added in 4321293972, which is
part of v28.0, but did not deprecate them. They are no longer used in the
CLI itself, but may be used by cli-plugin implementations.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These functions and types are shallow wrappers around the context
store and were intended for internal use as implementation for the
CLI itself.
They were exported in 3126920af1 to be
used by plugins and Docker Desktop. However, there's currently no public
uses of this, and Docker Desktop does not use these functions. These were
deprecated in 95eeafa551 and are no longer
used.
This patch removes the deprecated functions as they were meant to be
implementation specific for the CLI. If there's a need to provide
utilities for manipulating the context-store other than through the
CLI itself, we can consider creating an SDK for that purpose.
This removes:
- `RunCreate` and `CreateOptions`
- `RunExport` and `ExportOptions`
- `RunImport`
- `RunRemove` and `RemoveOptions`
- `RunUpdate` and `UpdateOptions`
- `RunUse`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These were deprecated in 036d3a6bab and
30774ed1f2, and were originally in the
cli/command/stack package, but moved for the (now deprecated) Compose
on Kubernetes feature in 4d947de292.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This replaces the visitAll recursive function with a test that verifies that
the option is set for all commands and subcommands, so that it doesn't have
to be modified at runtime.
We currently still have to loop over all functions for the setValidateArgs
call, but that can be looked at separately.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These functions and types are shallow wrappers around the context
store and were intended for internal use as implementation for the
CLI itself.
They were exported in 3126920af1 to be
used by plugins and Docker Desktop. However, there's currently no public
uses of this, and Docker Desktop does not use these functions.
This patch deprecates the exported functions as they were meant to be
implementation specific for the CLI. If there's a need to provide
utilities for manipulating the context-store other than through the
CLI itself, we can consider creating an SDK for that purpose.
This deprecates:
- `RunCreate` and `CreateOptions`
- `RunExport` and `ExportOptions`
- `RunImport`
- `RunRemove` and `RemoveOptions`
- `RunUpdate` and `UpdateOptions`
- `RunUse`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use a struct-literal for the IPAM config, and combine some of the checks.
Also use the Name field as a default, and only construct a scoped name
if the given name is empty (instead of the reverse).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function is currently only used within the package; create a non-exported
version of it, to make it clear it's not used elsewhere. This patch keeps
the exported function for now, but we can decide if we need to keep it
in future.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It was only used in a single place, and possibly incorrect. Let's inline
it to put the logic where it's used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These are very small structs, so using pointers doesn't bring much
advantage and makes it slightly more cumbersome to use.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This intermediate slice was a left-over from the "Compose on Kubernetes"
feature, which required some conversions, but that code was removed in
193ede9b12, so the intermediate slice no
longer has a purpose.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Preserve the original order by avoiding the intermediate map[string] and
keeping an index for the first occurrence of a stack; this also avoids
looping multiple times.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Include name in test-table
- Don't use un-keyed values in struct
- Simplify test-table to take a format string instead of a whole formatter.Context
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Functions and types in this package were exported as part of the "compose
on kubernetes" feature, which was deprecated and removed. These functions
are meant for internal use, and will be removed in the next release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Functions and types in this package were exported as part of the "compose
on kubernetes" feature, which was deprecated and removed. These functions
are meant for internal use, and will be removed in the next release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Functions and types in this package were exported as part of the "compose
on kubernetes" feature, which was deprecated and removed. These functions
are meant for internal use, and will be removed in the next release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Functions and types in this package were exported as part of the "compose
on kubernetes" feature, which was deprecated and removed. These functions
are meant for internal use, and will be removed in the next release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Functions and types in this package were exported as part of the "compose
on kubernetes" feature, which was deprecated and removed. These functions
are meant for internal use, and will be removed in the next release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This only impacts the JSON marshaled output; the "regular" output
of `docker info` already ignores these fields.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These were just testing JSON marshaling fields that are deprecated, but
may be present in a response; these fields will be removed in future
API versions, so stop testing for them.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This special handling was added in [moby@9b6dcc8], and later updated in
[moby@c127d96], but it fully depended on string-matching, which is brittle.
Testing the original ticket that lead to this handling, it looks like the
string matching no longer works, and the daemon error is returned as-is:
With graphdrivers:
docker pull tiborvass/no-remove
Using default tag: latest
Error response from daemon: Encountered remote "application/vnd.docker.plugin.v0+json"(unknown) when fetching
With containerd snapshotters enabled:
docker pull tiborvass/no-remove
Using default tag: latest
latest: Pulling from tiborvass/no-remove
cf635291f7c9: Download complete
failed to unpack image on snapshotter overlayfs: mismatched image rootfs and manifest layers
The error-message for containerd can probably be improved, but as the special
handling in the CLI no longer works, we can remove it.
[moby@9b6dcc8]: https://github.com/moby/moby/commit/9b6dcc8b9d1366d3da3c8f60f89de1a36b087b88
[moby@c127d96]: https://github.com/moby/moby/commit/c127d9614f5b30bd73861877f8540a63e7d869e9
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was used to share it between "trust" and "image",
but was only a shallow wrapper, so split the implementations where
used.
It was deprecated in 7ad113ccc2 and is
no longer used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Now that 3f5b1bdd32 removed DCT, which
needed some of the intermediate types (indexInfo), we can simplify the
auth code further and just get the base64-encoded AuthConfig to be set
as header.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These were deprecated in a5f4ba08d9 and only
used internally.
This removes the deprecated types and functions:
- `RunConfigCreate` and `CreateOptions`
- `RunConfigInspect` and `InspectOptions`
- `RunConfigList` and `ListOptions`
- `RunConfigRemove` and `RemoveOptions`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These were exported in f60369dfe6 to be
used in docker enterprise, but this never happened, and there's no
known consumers of these, so we should deprecate these. External
consumers can still call the API-client directly, which should've
been the correct thing to do in the first place.
This deprecates:
- `RunConfigCreate` and `CreateOptions`
- `RunConfigInspect` and `InspectOptions`
- `RunConfigList` and `ListOptions`
- `RunConfigRemove` and `RemoveOptions`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Relates to [cli@27b2797], which forked this type from the Moby API, and
[moby@6cfff7e], which made the same change on the API side.
The Email field was originally used to create a new Docker Hub account
through the `docker login` command. The `docker login` command could be
used both to log in to an existing account (providing only username and
password), or to create a new account (providing desired username and
password, and an e-mail address to use for the new account).
This functionality was confusing, because it was implemented when Docker
Hub was the only registry, but the same functionality could not be used
for other registries. This functionality was removed in Docker 1.11 (API
version 1.23) through [moby@aee260d], which also removed the Email field
([engine-api@9a9e468]) as it was no longer used.
However, this caused issues when using a new CLI connecting with an old
daemon, as the field would no longer be serialized, and the deprecation
may not yet be picked up by custom registries, so [engine-api@167efc7]
added the field back, deprecated it, and added an "omitempty". There
was no official "deprecated" format yet at the time, so let's make sure
the deprecation follows the proper format to make sure it gets noticed.
[cli@27b2797]: https://github.com/docker/cli/commit/27b2797f7deb3ca5b7f80371d825113deb1faca1
[moby@6cfff7e]: https://github.com/moby/moby/commit/6cfff7e8803a71b4acb74768b5121e7d17a9e098
[moby@aee260d]: https://github.com/moby/moby/commit/aee260d4eb3aa0fc86ee5038010b7bbc24512ae5
[engine-api@9a9e468]: https://github.com/docker-archive-public/docker.engine-api/commit/9a9e468f503eb731d6fdc9d7f98c122e1b397c86
[engine-api@167efc7]: https://github.com/docker-archive-public/docker.engine-api/commit/167efc72bb24d7ad2bcc91760a9a5d37572e104f
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These flags were added in 20a6ff32ee, and require
API version v1.32 or up, but they accidentally copied the flag-name from another
flag, so were not setting the annotation correctly.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Remove redundant intermediate variables
- Explicitly use an early return on error instead of combining with
other checks.
- Fix unhandled errors and combine defers
- Remove outstanding TODO that unlikely will be addressed
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `reference.TrimNamed` function strips both digests and tags; the
formatter function only wants to remove the digest, but preserve any
tags present.
Update the implementation to only trim the reference if there's a digest
present, otherwise use it as-is.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was exported to share it between "trust" and "image",
but was only a shallow wrapper, so split the implementations where
used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These were exported in 812f113685, but
while the function and options are exported, the option-fields were
all un-exported, so these were not usable.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch deprecates exported NewPruneCommand and moves the
implementation details to an unexported function.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Use a table-test to more easily allow adding test-cases
- Use the test-name itself as name for the golden file
- Use a struct-literal to create the fixture for formatting.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
This deprecates the following types and functions:
- `SignedTagInfo`
- `SignerInfo`
- `NewTrustTagFormat`
- `NewSignerInfoFormat`
- `TagWrite`
- `SignerInfoWrite`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The RegisterLegacy and Register functions register constructors for
commands, so we should expect them to be a fresh copy that is not
shared, which means that we can mutate the command in-place.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The Register and RegisterLegacy functions are designed to be used
in package init() functions, which are guaranteed to be run
sequentially.
From the documentation (https://go.dev/ref/mem#init);
> Program initialization runs in a single goroutine, but that goroutine
> may create other goroutines, which run concurrently. If a package `p`
> imports package `q`, the completion of `q`'s `init` functions happens
> before the start of any of `p`'s.
>
> The completion of all `init` functions is synchronized before the
> start of the function `main.main`.
This patch removes the synchonisation as no concurrency should happen
if these functions are used as intended.
As the internal queue is not expected to be mutated after use, we also
don't have to return a copy.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch removes the explicit `commands.AddCommands` function and
instead relies upon the `internal/commands` package which registers each
CLI command using `init()` instead.
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
This patch deprecates exported trust commands and moves the implementation
details to an unexported function.
Commands that are affected include:
- trust.NewTrustCommand
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
This patch deprecates exported plugin commands and moves the implementation
details to an unexported function.
Commands that are affected include:
- plugin.NewPluginCommand
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
- Parse/format the repository name when constructing and store the
result.
- Remove the Name() accessor, as this type is only used internally,
and no longer had any special handling.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch deprecates exported swarm commands and moves the implementation
details to an unexported function.
Commands that are affected include:
- swarm.NewSwarmCommand
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
This patch deprecates exported registry commands and moves the implementation
details to an unexported function.
Commands that are affected include:
- registry.NewLoginCommand
- registry.NewLogoutCommand
- registry.NewSearchCommand
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
This patch deprecates exported stack commands and moves the implementation
details to an unexported function.
Commands that are affected include:
- stack.NewStackCommand
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
This patch deprecates exported context commands and moves the implementation
details to an unexported function.
Commands that are affected include:
- context.NewContextCommand
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
This patch deprecates exported volume commands and moves the implementation
details to an unexported function.
Commands that are affected include:
- volume.NewVolumeCommand
- volume.NewPruneCommand
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
This patch deprecates exported service commands and moves the implementation
details to an unexported function.
Commands that are affected include:
- service.NewServiceCommand
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
This patch deprecates exported secret commands and moves the implementation
details to an unexported function.
Commands that are affected include:
- secrets.NewSecretCommand
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
This patch deprecates exported manifest commands and moves the implementation
details to an unexported function.
Commands that are affected include:
- manifest.NewManifestCommand
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
This patch deprecates exported node commands and moves the implementation
details to an unexported function.
Commands that are affected include:
- node.NewNodeCommand
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
This patch deprecates exported network commands and moves the
implementation details to an unexported function.
Commands that are affected include:
- network.NewNetworkCommand
- network.NewPruneCommand
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
This non-standard handling for these options was added in [moby@e4c1f07]
and [moby@abe32de] to work around a regression in Docker 1.13 that caused
`docker-machine` to fail. Preserving quotes in such cases is expected (and
standard behavior), but versions of Docker before 1.13 used a custom "mflag"
package for flag parsing, and that package contained custom handling for
quotes (added in [moby@0e9c40e]).
Given that Docker Machine reached EOL a long time ago and other options,
such as `docker context`, have been added to configure the CLI to connect
to a specific host (with corresponding TLS configuration), we can remove
the special handling for these flags, as it's inconsistent with all other
flags, and not worth maintaining for a tool that no longer exists.
[moby@e4c1f07]: https://github.com/moby/moby/commit/e4c1f0772923c3069ce14a82d445cd55af3382bc
[moby@abe32de]: https://github.com/moby/moby/commit/abe32de6b46825300f612864e6b4c98606a5bb0e
[moby@0e9c40e]: https://github.com/moby/moby/commit/0e9c40eb8243fa437bc6c3e93aaff64a10cb856e
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch deprecates exported system commands and moves the
implementation details to an unexported function.
Commands that are affected include:
- system.NewVersionCommand
- system.NewInfoCommand
- system.NewSystemCommand
- system.NewEventsCommand
- system.NewInspectCommand
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
- Use sentence-case to follow our docs guidelines.
- Add newlines to prevent these being rendered on a
single line.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Rewrite the test to not depend on registry.DecodeAuthConfig, which
may be moved internal to the daemon as part of the modules transition.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch unexports the `builder` and `bake` stub command and it adds
deprecation notices on the exported functions.
It also registers the commands using the new `cli/internal/commands`
package when the init function executes.
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
These aliases were added in 292713c887
(part of v28.0), but did not deprecate them. They are no longer used
in the CLI itself, but may be used by cli-plugin implementations.
This deprecates the aliases in `cli-plugins/manager` in favor of
their equivalent in `cli-plugins/manager/metadata`:
- `CommandAnnotationPlugin`
- `CommandAnnotationPluginVendor`
- `CommandAnnotationPluginVersion`
- `CommandAnnotationPluginInvalid`
- `CommandAnnotationPluginCommandPath`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These were deprecated in 6f0c66c152 and are
no longer used.
This removes the deprecated:
- `NewNamedListOptsRef`
- `NewNamedMapOpts`
- `NamedListOpts`
- `NamedMapOpts`
- `NamedOption`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `--tlscacert`, `--tlscert`, and `--tlskey` command-line flags had
non-standard behavior for handling values contained in quotes (`"` or `'`).
Normally, quotes are handled by the shell, for example, in the following
example, the shell takes care of handling quotes before passing the values
to the `docker` CLI:
docker --some-option "some-value-in-quotes" ...
However, when passing values using an equal sign (`=`), this may not happen
and values may be handled including quotes;
docker --some-option="some-value-in-quotes" ...
This caused issues with "Docker Machine", which used this format as part
of its `docker-machine config` output, and the CLI carried special, non-standard
handling for these flags.
Docker Machine reached EOL, and this special handling made the processing
of flag values inconsistent with other flags used, so this behavior is
deprecated. Users depending on this behavior are recommended to specify
the quoted values using a space between the flag and its value, as illustrated
above.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `NewNamedListOptsRef`, `NewNamedMapOpts` and related `NamedListOpts`,
`NamedMapOpts`, and `NamedOption` interface were added in [moby@677a6b3],
which added support for a `daemon.json` configuration file. That change
required a way to correlate command-line flags with their corresponding
fields in the `daemon.json` to detect conflicting options. At the time,
the CLI and daemon were produced from the same code, and shared packages
for command-line options, but when the CLI was moved to a separate
repository, these options were inherited.
[moby@677a6b3]: https://github.com/moby/moby/commit/677a6b3506107468ed8c00331991afd9176fa0b9
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
hostVar is used for the '--host' / '-H' flag to set [ClientOptions.Hosts].
The [ClientOptions.Hosts] field is a slice because it was originally shared
with the daemon config. However, the CLI only allows for a single host to
be specified.
hostVar presents itself as a "string", but stores the value in a string
slice. It produces an error when trying to set multiple values, matching
the check in [getServerHost].
[getServerHost]: https://github.com/docker/cli/blob/7eab668982645def1cd46fe1b60894cba6fd17a4/cli/command/cli.go#L542-L551
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The ClientOptions struct and related flags were inherited from the Moby
repository, where originally the CLI and Daemon used the same implementation
and had a "Common" options struct. When the CLI moved to a separate repository,
those structs were duplicated, but some daemon-specific logic remained. For
example, the daemon can be configured to listen on multiple ports and sockets
([moby@dede158]), but the CLI [can only connect to a single host][1]. The
daemon config also had to account for flags conflicting with `daemon.json`,
and use special flag-vars for this ([moby@677a6b3]).
Unfortunately, the `ClientConfig` struct became part of the public API and
is used as argument in various places, but we can remove the use of the
special flag var. This patch replaces the use of `NewNamedListOptsRef`
for a regular `StringArray`.
Unfortunately this changes the flag's type description from `list` to
`stringArray`, but we can look at changing that separately.
[moby@dede158]: https://github.com/moby/moby/commit/dede1585ee00f957e153691c464aab293c2dc469
[1]: https://github.com/moby/moby/blob/0af135e9065562e14a77439e13a29b4f1eb627a0/docker/docker.go#L191-L193
[moby@677a6b3]: https://github.com/moby/moby/commit/677a6b3506107468ed8c00331991afd9176fa0b9
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `QuotedString` option was added in [moby@e4c1f07] and [moby@abe32de]
to work around a regression in Docker 1.13 that caused `docker-machine`
to fail. `docker-machine` produced instructions on how to set up a cli
to connect to the Machine it produced. These instructions used quotes
around the paths for TLS certificates, but with an `=` for the flag's
values instead of a space; due to this the shell would not handle
stripping quotes, so the CLI would now get the value including quotes.
Preserving quotes in such cases is expected (and standard behavior), but
versions of Docker before 1.13 used a custom "mflag" package for flag
parsing, and that package contained custom handling for quotes (added
in [moby@0e9c40e]).
For other flags, this problem could be solved by the user, but as these
instructions were produced by `docker-machine`'s `config` command, an
exception was made for the `--tls-xxx` flags. From [moby-29761]:
> The flag trimming behaviour is really unusual, and I would say unexpected.
> I think removing it is generally the right idea. Since we have one very
> common case where it's necessary for backwards compatibility we need to
> add a special case, but I don't think we should apply that case to every
> flag.
The `QuotedString` implementation has various limitations, as it doesn't
follow the same handling of quotes as a shell would.
Given that Docker Machine reached EOL a long time ago and other options,
such as `docker context`, have been added to configure the CLI to connect
to a specific host (with corresponding TLS configuration), we should remove
the special handling for these flags, as it's inconsitent with all other
flags, and not worth maintaining for a tool that no longer exists.
This patch deprecates the `QuotedString` option and removes its use. A
temporary, non-exported copy is added, but will be removed in the next
release.
[moby-29761]: https://github.com/moby/moby/issues/29761#issuecomment-270211265
[moby@e4c1f07]: https://github.com/moby/moby/commit/e4c1f0772923c3069ce14a82d445cd55af3382bc
[moby@abe32de]: https://github.com/moby/moby/commit/abe32de6b46825300f612864e6b4c98606a5bb0e
[moby@0e9c40e]: https://github.com/moby/moby/commit/0e9c40eb8243fa437bc6c3e93aaff64a10cb856e
[moby@c79a169]: https://github.com/moby/moby/commit/c79a169a35f8ee0ecb66cfcffab4b0bd2c77f996
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These utilities were only used internally; create a local copy
where used, and deprecate the ones in cli.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It was only used in a single place and has no external consumers.
Move it to where it's used to keep things together.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The example shows that the `--volumes` option is used, which in current
versions of docker only removes "anonymous" volumes, but preserves named
volume:
$ docker system prune -a --volumes
...
- all anonymous volumes not used by at least one container
...
But the example output showed that a named volume ("named-vol") was
deleted;
Deleted Volumes:
named-vol
Co-authored-by: Roberto Villarreal <rrjjvv@yahoo.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The label validation steps now properly fail the workflow when required
labels are missing, instead of continuing with errors.
This change removes the `continue-on-error: true` directives and adds
`always()` conditions to ensure the validation steps run regardless of
previous step outcomes.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The PR validation workflow now enforces that every PR with an 'impact/*'
label must also have a corresponding 'kind/*' label, in addition to the
existing 'area/*' label requirement.
This change helps ensure proper categorization of pull requests by
requiring contributors to specify both the impact area and the kind of
change being made.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The logic used in this function was confusing; some errors were ignored,
but responses handled regardless. The intent here is to try to detect
whether the destination exists inside the container and is of the right
"type" (otherwise produce an error).
Failing to "stat" the path in the container means we can't produce a
nice error for the user, but we'll continue the request, which either
would succeed or produce an error returned by the daemon.
While working on this patch, I noticed that some error-handling on the
daemon side is incorrect. This patch does not fix those cases, but
makes the logic slightly easier to follow (we should consider extracting
the "stat" code to a separate function though).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- deprecate sockets.GetProxyEnv, sockets.DialerFromEnvironment
- add support for unix sockets on Windows
- remove legacy CBC cipher suites from client config
- align client and server defaults to be the same.
- remove support for encrypted TLS private keys.
- nat: optimize ParsePortSpec
full diff: https://github.com/docker/go-connections/compare/v0.5.0...v0.6.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This test was recently rewritten from testing plugin upgrade with
DCT enabled to just "plugin upgrade", but there's a fair amount of
complexity in the e2e tests that set up different daemons and registries.
It's possible that tests are affecting each-other, and some state (config)
is left behind.
Let's skip the test for now, and add a tracking ticket to dig deeper.
=== FAIL: e2e/global TestPromptExitCode/plugin_upgrade (7.55s)
cli_test.go:205: assertion failed:
Command: docker plugin push registry:5000/plugin-upgrade-test:latest
ExitCode: 1
Error: exit status 1
Stdout: The push refers to repository [registry:5000/plugin-upgrade-test]
459089aa5943: Preparing
adc41078d1d9: Preparing
d7bff979db13: Preparing
459089aa5943: Preparing
Stderr: error pushing plugin: failed to do request: Head "https://registry:5000/v2/plugin-upgrade-test/blobs/sha256:adc41078d1d937495df2f90444e5414a01db31e5a080f8aa4f163c64d41abd11": http: server gave HTTP response to HTTPS client
Failures:
ExitCode was 1 expected 0
Expected no error
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- https://github.com/golang/go/issues?q=milestone%3AGo1.24.6+label%3ACherryPickApproved
- full diff: golang/go@go1.24.5...go1.24.6
These minor releases include 2 security fixes following the security policy:
- os/exec: LookPath may return unexpected paths
If the PATH environment variable contains paths which are executables (rather
than just directories), passing certain strings to LookPath ("", ".", and ".."),
can result in the binaries listed in the PATH being unexpectedly returned.
Thanks to Olivier Mengué for reporting this issue.
This is CVE-2025-47906 and Go issue https://go.dev/issue/74466.
- database/sql: incorrect results returned from Rows.Scan
Cancelling a query (e.g. by cancelling the context passed to one of the query
methods) during a call to the Scan method of the returned Rows can result in
unexpected results if other queries are being made in parallel. This can result
in a race condition that may overwrite the expected results with those of
another query, causing the call to Scan to return either unexpected results
from the other query or an error.
We believe this affects most database/sql drivers.
Thanks to Spike Curtis from Coder for reporting this issue.
This is CVE-2025-47907 and https://go.dev/issue/74831.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.24.6
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
It was only used internally and has no external users. It should not be
used for new uses, because it also adds a minimum API version constraint
and a default from env-var, which must be evaluated for each individual
use of such flags.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Plugins are not widely used, and there's no known plugins that use
content-trust. We're working on updating the authentication stack
in the CLI, and the trust implementation hinders us in making
changes, so removing parts that are not high-priority (ahead of
full deprecation of DCT).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use names for the plugin that don't refer to content-trust, as that's
not related to this test.
Make it slightly more clear which steps are preparation and which
are the actual test. The test sometimes fails in the preparation
step, and we could consider moving those separate and XFail the
test if the preparation fails;
Stderr: error pushing plugin: failed to do request: Head "https://registry:5000/v2/plugin-content-trust-upgrade/blobs/sha256:af932a31d4df3a2890f900bcf28e16cea87b2b440b8036ba86ab3418f3e50a35": http: server gave HTTP response to HTTPS client
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The gotest.tools `fs.NewDir` utility already sets up a `t.Cleanup`,
so we can treat it the same as `t.TempDir()` and let it handle
cleaning up by itself.
We should probably consider replacing some of this with `t.TempDir`.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This package will not be included in the api or client modules, and
we're currently only using a single function of it, and only the
unix implementation, so let's fork it for now (although the package
may be moved to moby/sys).
This removes the last dependency on github.com/docker/docker.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These aliases were added in 4321293972
(part of v28.0), but did not deprecate them. They are no longer used
in the CLI itself, but may be used by cli-plugin implementations.
This deprecates the aliases in `cli-plugins/manager` in favor of
their equivalent in `cli-plugins/manager/metadata`:
- `NamePrefix`
- `MetadataSubcommandName`
- `HookSubcommandName`
- `Metadata`
- `ReexecEnvvar`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was a pattern inheritted from pkg/errors.Wrapf, which ignored
nil errors for convenience. However, it is error-prone, as it is
not obvious when returning a nil-error.
All call-sites using `wrapAsPluginError` already do a check for
nil errors, so remove this code to prevent hard to find bugs.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It is for internal use, and no longer needed for testing, now that
the `Plugin` type handles marshalling errors.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Go does not by default marshal `error` type fields to JSON. The manager
package therefore implemented a `pluginError` type that implements
[encoding.TextMarshaler]. However, the field was marked as a regular
`error`, which made it brittle; assining any other type of error would
result in the error being discarded in the marshaled JSON (as used in
`docker info` output), resulting in the error being marshaled as `{}`.
This patch adds a custom `MarshalJSON()` on the `Plugin` type itself
so that any error is rendered. It checks if the error used already
implements [encoding.TextMarshaler], otherwise wraps the error in
a `pluginError`.
[encoding.TextMarshaler]: https://pkg.go.dev/encoding#TextMarshaler
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Experimental is always enabled (977d3ae046),
and the `Experimental` field in plugin metadata was deprecated in
977d3ae046 and removed in commit
6a50c4f700.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Move the version-check for pruners to the pruner, which can
return a [ErrNotImplemented] error to indicate they won't
be run with the API version that's used.
This helps separating concerns, and doesn't enforce knowledge
about what's supported by each content-type onto the system
prune command.
[ErrNotImplemented]: https://pkg.go.dev/github.com/docker/docker@v28.3.3+incompatible/errdefs#ErrNotImplemented
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds a "dry-run" / "pre-check" option for prune-functions,
which delegates constructing the confirmation message (what is
about to be pruned) and validation of the given options to the
prune-functions.
This helps separating concerns, and doesn't enforce knowledge
about what's supported by each content-type onto the system
prune command.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Introduce a "prune" package in which we maintain a list of prune
functions that are registered. Known prune "content-types" are
included in a pre-defined order, after which additional content
can be registered.
Using this approach no longer requires the "RunPrune" functions
to be exported, and allows additional content-types to be
introduced without having to import those packages into the
system package, so keeping things more decoupled.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Most places only use IndexInfo (and may not even need that), so replace
the use of ParseRepositoryInfo for NewIndexInfo, and move the RepositoryInfo
type to the trust package, which uses it as part of its ImageRefAndAuth
struct.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Use strong-typed switches for validating options
- Initialize defaults instead of setting them after
parsing the ports. Each option should be validated
as part of the parsing, so no invalid (or empty)
values should be set.
- Put variables closer to where they're used, and
pre-allocate slices.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Rewrite the function to use strings.Cut instead of checking for,
and trimming prefixes for each option.
- More explicitly set the value, instead of setting an empty value,
then propagating the struct.
- Define a "type" to provide a more enum-like construct.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
notable changes;
- api/types/container: move StateStatus, NewStateStatus internal again
- daemon/server/httputils: remove ContainerDecoder interface
- runconfig: move to daemon/internal/runconfig
- pkg/stack: move to daemon/internal
- remove pkg/stringid as it has moved to the client module
- remove pkg/stdcopy as it has moved to the api module
- pkg/rootless: move to daemon/internal
- move api/types/plugins/logdriver to daemon/internal
- move api/types/plugins/logdriver to daemon/internal
- pkg/system: move to daemon/internal
- remove pkg/fileutils
full diff: https://github.com/moby/moby/compare/25e2b4d48551...2574c2b2e9174688bb78010a1dd8a02017ca5130
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Removed the error return from the `ParseRepositoryInfo` function.
There are no validation steps inside `ParseRepositoryInfo` which
could cause an error, so we always returned a nil error.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We transitioned most functionality of docker/errdefs to containerd
errdefs module, and the docker/errdefs package should no longer be
used.
Because of that, there will no longer be ambiguity, so we can remove
the aliases for this package, and use it as "errdefs".
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It it just a chain of `New("sometag").Parse(...)`, and most of our
uses don't use a tag for the template, so can call Parse.
There's no public users of this function, but deprecating it first
just in case.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- fix various unhandled errors
- remove some locally defined option-types in favor of option-types
defined by the client / api
- don't use unkeyed structs in tests, and add docs for some subtests
- fix some values in tests that triggered "spellcheck" warnings
- inline vars / functions that only had a single use.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Moves ParseVolume() to a new internal package to remove the dependency
on cli/compose/loader in cli/command/container/opts.go
refactor to keep types isolated
- rename the package to "volumespec" to reuse the name of the package
as part of the name (parsevolume.ParseVolume() -> volumespec.Parse())
- move the related compose types to the internal package as well,
and rename them to be more generic (not associated with "compose");
- ServiceVolumeConfig -> VolumeConfig
- ServiceVolumeBind -> BindOpts
- ServiceVolumeVolume -> VolumeOpts
- ServiceVolumeImage -> ImageOpts
- ServiceVolumeTmpfs -> TmpFsOpts
- ServiceVolumeCluster -> ClusterOpts
- alias the internal types inside cli/compose/types to keep backward
compatibility (for any external consumers); even though the implementation
is internal, Go allows aliasing types to use them externally.
Signed-off-by: Michael Tews <michael@tews.dev>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
internal/registry/errors.go:26:43: use-any: since Go 1.18 'interface{}' can be replaced by 'any' (revive)
func invalidParamf(format string, args ...interface{}) error {
^
internal/registry/registry_mock_test.go:52:51: use-any: since Go 1.18 'interface{}' can be replaced by 'any' (revive)
func writeResponse(w http.ResponseWriter, message interface{}, code int) {
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The registry.ServiceConfig struct in the API types was meant for the
registry configuration on the daemon side; it has variuos fields we
don't use, defines methods for (un)marshaling JSON, and a custom version
of `net.IPNet`, also to (un)marshal JSON.
None of that is needed, so let's change it to a local type, and implement
a constructor (as we now only have "insecure registries" to care
about).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It was written to be used as validate-func for command-line flags, which
we don't use it for (which for CLI-flags includes normalizing the value).
The validation itself didn't add much; it only checked the registry didn't
start or end with a hyphen (which would still fail when parsing).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
now that we no longer need to account for mirrors, these were
identical, so just use a single one.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The CLI does not have information about mirrors, and doesn't
configure them, so we can remove these parts.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds an internal fork of [github.com/docker/docker/registry], taken
at commit [moby@f651a5d]. Git history was not preserved in this fork,
but can be found using the URLs provided.
This fork was created to remove the dependency on the "Moby" codebase,
and because the CLI only needs a subset of its features. The original
package was written specifically for use in the daemon code, and includes
functionality that cannot be used in the CLI.
[github.com/docker/docker/registry]: https://pkg.go.dev/github.com/docker/docker@v28.3.2+incompatible/registry
[moby@49306c6]: https://github.com/moby/moby/tree/49306c607b72c5bf0a8e426f5a9760fa5ef96ea0/registry
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was deprecated in 6f46cd2f4b,
which is part of v28.x, and no longer used, so we can remove it.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This utility was only used in the CLI, but the implementation was
based on it being used on the daemon side, so included resolving
the host's IP-address, mirrors, etc.
The only reason it's used in the CLI is to provide credentials for
the registry that's being searched, so reduce it to just that.
There's more cleaning up to do in this area, so to make our lives
easier, it's implemented locally as non-exported functions; likely
to be replaced with something else.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Docker Content Trust is currently only implemented for the classic
builder, but is known to not work with multi-stage builds, and
requires rewriting the Dockerfile, which is brittle because the
Dockerfile syntax evolved with the introduction of BuildKit as
default builder.
Given that the classic builder is deprecated, and only used for
Windows images, which are not verified by content trust;
# docker pull --disable-content-trust=false mcr.microsoft.com/windows/servercore:ltsc2025
Error: remote trust data does not exist for mcr.microsoft.com/windows/servercore: mcr.microsoft.com does not have trust data for mcr.microsoft.com/windows/servercore
With content trust not implemented in BuildKit, and not implemented
in docker compose, this resulted in an inconsistent behavior.
This patch removes content-trust support for "docker build". As this
is a client-side feature, users who require this feature can still
use an older CLI to to start the build.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
gitutils_test.go:210: git-http-backend: git: 'http-backend' is not a git command. See 'git --help'.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adds a local fork of this package for use in the classic builder.
Code was taken at commit [d33d46d01656e1d9ee26743f0c0d7779f685dd4e][1].
Migration was done using the following steps:
# install filter-repo (https://github.com/newren/git-filter-repo/blob/main/INSTALL.md)
brew install git-filter-repo
# create a temporary clone of docker
cd ~/Projects
git clone https://github.com/docker/docker.git build_context_temp
cd build_context_temp
# commit taken from
git rev-parse --verify HEAD
d33d46d01656e1d9ee26743f0c0d7779f685dd4e
git filter-repo --analyze
# remove all code, except for the remotecontext packages, and move to build/internal docs and previous locations of it
git filter-repo \
--path 'builder/remotecontext/git' \
--path 'builder/remotecontext/urlutil' \
--path-rename builder/remotecontext:cli/command/image/build/internal
# go to the target repository
cd ~/go/src/github.com/docker/cli
# create a branch to work with
git checkout -b fork_remotecontext
# add the temporary repository as an upstream and make sure it's up-to-date
git remote add build_context_temp ~/Projects/build_context_temp
git fetch build_context_temp
# merge the upstream code
git merge --allow-unrelated-histories --signoff -S build_context_temp/master
[1]: https://github.com/docker/docker/d33d46d01656e1d9ee26743f0c0d7779f685dd4e
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Removes direct imports of github.com/docker/docker/builder in
the image package, to be moved later.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- use consistent name for MountOpt vars
- cleanup some comments and make them a GoDoc
- remove import alias
- use subtests for tests that were prepared for it.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Also rename "ctx" argument; we shouldn't use this as name for things
that are not a context.Context.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch deprecates the unused `RegistryAuthenticationPrivilegedFunc`.
The function would prompt the user when the registry returns a 403 after trying
the initial auth value set in `RegistryAuth`.
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
docker build --call outline .
TARGET: binary
BUILD ARG VALUE DESCRIPTION
BASE_VARIANT alpine
ALPINE_VERSION 3.21 sets the version of the alpine base image to use, including for the golang image.
GO_VERSION 1.24.5
XX_VERSION 1.6.1
GOVERSIONINFO_VERSION v1.4.1
GO_LINKMODE static defines if static or dynamic binary should be produced
GO_BUILDTAGS defines additional build tags
GO_STRIP strips debugging symbols if set
CGO_ENABLED manually sets if cgo is used
VERSION sets the version for the produced binary
PACKAGER_NAME sets the company that produced the windows binary
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch removes the interactive prompts from `docker push/pull`.
The prompt would only execute on a response status code 403 from the registry
after trying the value set in `RegistryAuth`. Docker Hub could return 404
instead or 429, which would never execute the prompt.
The UX regarding the prompt is also questionable since the user might
not actually want to authenticate with a registry and the CLI could fail fast
instead. The user can always run `docker login` or set the `DOCKER_AUTH_CONFIG`
environment variable to get authenticated.
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
client.ContainerDiff already validates the given container name/ID, and
produces an error when empty, so we don't have to check for this;
https://github.com/moby/moby/blob/abba330bbfe10765822b59bb68af99db439736ba/client/container_diff.go#L13-L16
While updating, also;
- remove the diffOptions type, as there were no other options, and make
the container name/ID a string argument.
- fix camelCase nameing of dockerCLI
Before this patch:
docker diff ""
Container name cannot be empty
With this patch:
docker diff ""
invalid container name or ID: value is empty
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It was the only utility we consumed from the package, and it's trivial
to implement, so let's create local copies of it.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This utility was only used for testing, and to generate a random
suffix for Dockerfiles. As we don't need the same contract as
pkg/stringid.GenerateRandomID() (not allow all-numeric IDs as they
would not be usable for hostnames), we can use a local test-utility,
and local implementation for the random suffix instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We were depending on pkg/stringid to truncate IDs for presentation. While
traditionally, we used a fixed length for "truncated" IDs, this is not
a strict requirement (any ID-prefix should work, but conflicts may
happen on shorter IDs).
This patch adds a local `TruncateID()` utility in the formatter package;
it's currently using the same implementation and length as the
`stringid.TruncateID` function, but may diverge in future.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `AllowOverwriteDirWithFile` option was added when reimplementing the
CLI using the API Client lib in [moby@1b2b91b]. Before that refactor, the
`noOverwriteDirNonDir` query argument [would be set unconditionally][1]
by the CLI, with no options to control the behavior.
It's unclear why the `noOverwriteDirNonDir` was implemented as opt-in (not
opt-out), as overwriting a file with a directory (or vice-versa) would
generally be unexpected behavior.
We're considering making `noOverwriteDirNonDir` unconditional on the daemon
side, and to deprecate the `AllowOverwriteDirWithFile` option. This patch
removes its use, as it was set to the default either way, and there's no
options to configure it from the CLI.
[1]: https://github.com/moby/moby/blob/8c9ad7b818c0a7b1e39f8df1fabba243a0961c2d/api/client/cp.go#L345-L346
[moby@1b2b91b]: https://github.com/moby/moby/commit/1b2b91ba43dc6fa1b4b758fc5a8090ce6cc597ff
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Make the test slightly more permissive; we're looking for a trailing
newline, not necessarily an empty line.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- https://github.com/golang/go/issues?q=milestone%3AGo1.24.5+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.24.4...go1.24.5
This minor releases include 1 security fixes following the security policy:
- cmd/go: unexpected command execution in untrusted VCS repositories
Various uses of the Go toolchain in untrusted VCS repositories can result in
unexpected code execution. When using the Go toolchain in directories fetched
using various VCS tools (such as directly cloning Git or Mercurial repositories)
can cause the toolchain to execute unexpected commands, if said directory
contains multiple VCS configuration metadata (such as a '.hg' directory in a Git
repository). This is due to how the Go toolchain attempts to resolve which VCS
is being used in order to embed build information in binaries and determine
module versions.
The toolchain will now abort attempting to resolve which VCS is being used if it
detects multiple VCS configuration metadata in a module directory or nested VCS
configuration metadata (such as a '.git' directoy in a parent directory and a
'.hg' directory in a child directory). This will not prevent the toolchain from
building modules, but will result in binaries omitting VCS related build
information.
If this behavior is expected by the user, the old behavior can be re-enabled by
setting GODEBUG=allowmultiplevcs=1. This should only be done in trusted
repositories.
Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting
this issue.
This is CVE-2025-4674 and https://go.dev/issue/74380.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.24.5
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
I noticed this in a ticket in the compose issue tracker; with debug logging
enabled, the OTEL error-logger may be logging even if there's no error;
DEBU[0000] Executing bake with args: [bake --file - --progress rawjson --metadata-file /tmp/compose-build-metadataFile-1203980021.json --allow fs.read=/home/user/dev/project --allow fs.read=/home/user/dev/project --allow fs.read=/home/user/dev/project/nginx --allow fs.read=/home/user/dev/project]
TRAC[0000] Plugin server listening on @docker_cli_d8df486f78df3b7357995be71bf0cef6
DEBU[0005] otel error error="<nil>"
^CTRAC[0055] Closing plugin server
TRAC[0055] Closing plugin server
DEBU[0055] otel error error="<nil>"
DEBU[0055] otel error error="<nil>"
Update the error-handler to not log if there's no error.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Make it a hidden file. From the [CodeCov docs][1]:
> Can I name the file .codecov.yml?
>
> Yes, you can name the file `codecov.yml` or `.codecov.yml`. However, the
> file must still be located in the repository root, `dev/`, or `.github/`
> directories
[1]: https://docs.codecov.com/docs/codecov-yaml#can-i-name-the-file-codecovyml
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adding image tags that follow the semver major and minor versions (e.g., `28`
and `28.3`) for the moby-bin images.
This makes it easier for users to reference the latest build within a
major or minor version series without having to know the exact
minor/patch version.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
When connecting to a remote daemon through an ssh:// connection,
the CLI connects with the remote host using ssh, executing the
`docker system dial-stdio` command on the remote host to connect
to the daemon API's unix socket.
By default, the `docker system dial-stdio` command connects with the
daemon using the default location (/var/run/docker.sock), or the
location as configured on the remote host.
Commit 25ebf0ec9c (included in docker
CLI v24.0.0-rc.2 and higher) introduced a feature to allow the location
of the socket to be specified through the host connection string, for
example:
DOCKER_HOST='ssh://example.test/run/custom-docker.sock'
The custom path is included as part of the ssh command executed from
the client machine to connect with the remote host. THe example above
would execute the following command from the client machine;
ssh -o ConnectTimeout=30 -T -- example.test docker --host unix:///run/custom-docker.sock system dial-stdio
ssh executes remote commands in a shell environment, and no quoting
was in place, which allowed for a connection string to include additional
content, which would be expanded / executed on the remote machine.
For example, the following example would execute `echo hello > /hello.txt`
on the remote machine;
export DOCKER_HOST='ssh://example.test/var/run/docker.sock $(echo hello > /hello.txt)'
docker info
# (output of docker info from the remote machine)
While this doesn't allow the user to do anything they're not already
able to do so (by directly using the same SSH connection), the behavior
is not expected, so this patch adds quoting to prevent such URLs from
resulting in expansion.
This patch updates the cli/connhelper and cli/connhelper/ssh package to
quote parameters used in the ssh command to prevent code execution and
expansion of variables on the remote machine. Quoting is also applied to
other parameters that are obtained from the DOCKER_HOST url, such as username
and hostname.
- The existing `Spec.Args()` method inthe cli/connhelper/ssh package now
quotes arguments, and returns a nil slice when failing to quote. Users
of this package should therefore check the returned arguments before
consuming. This method did not provide an error-return, and adding
one would be a breaking change.
- A new `Spec.Command` method is introduced, which (unlike the `Spec.Args()`
method) provides an error return. Users are recommended to use this new
method instead of the `Spec.Args()` method.
Some minor additional changes in behavior are included in this patch;
- Connection URLs with a trailing slash (e.g. `ssh://example.test/`)
would previously result in `unix:///` being used as custom socket
path. After this patch, the trailing slash is ignored, and no custom
socket path is used.
- Specifying a remote command is now required. When passing an empty
remote command, `Spec.Args()` now results in a `nil` value to be
returned (or an `no remote command specified` error when using
`Spec.Comnmand()`.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
cli/connhelper/internal/syntax/parser.go:31:2: Duplicate words (the) found (dupword)
// Note that it shares some features with Bash, due to the the shared
^
cli/connhelper/internal/syntax/quote.go:48:1: cyclomatic complexity 35 of func `Quote` is high (> 16) (gocyclo)
func Quote(s string, lang LangVariant) (string, error) {
^
cli/connhelper/internal/syntax/quote.go:103:3: shadow: declaration of "offs" shadows declaration at line 56 (govet)
offs := 0
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was introduced in 9b54d860cd,
which added `docker container remove` as alias for `docker container rm`.
However, due to the `NewRmCommand` being used both for adding the top-level
`docker rm` command and for adding the `docker container rm` command, it
also introduced a (hidden) top-level `docker remove` command;
docker remove --help | head -n1
Usage: docker rm [OPTIONS] CONTAINER [CONTAINER...]
The command was not documented, and did not appear in `--help` output,
nor was auto-complete provided;
docker --help | grep remove
docker r<TAB>
rename (Rename a container) rm (Remove one or more containers) run (Create and run a new container from an image)
restart (Restart one or more containers) rmi (Remove one or more images)
This patch adds a dedicated, non-exported `newRemoveCommand` to add sub-
commands for `docker container`, taking a similar approach as was done in
[moby@b993609d5a] for `docker image rm`.
With this patch applied, the hidden command is no longer there, but
the `docker rm`, `docker container rm`, and `docker container remove`
commands stay functional as intended;
docker remove foo
docker: unknown command: docker remove
Run 'docker --help' for more information
docker rm --help | head -n1
Usage: docker rm [OPTIONS] CONTAINER [CONTAINER...]
docker container rm --help | head -n1
Usage: docker container rm [OPTIONS] CONTAINER [CONTAINER...]
docker container remove --help | head -n1
Usage: docker container rm [OPTIONS] CONTAINER [CONTAINER...]
[moby@b993609d5a]: https://github.com/moby/moby/commit/b993609d5ad4590da72e217bb43786b74aabc183
Reported-by: Lorenzo Buero <138243046+LorenzoBuero@users.noreply.github.com>
Co-authored-by: Lorenzo Buero <138243046+LorenzoBuero@users.noreply.github.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When pulling or pushing images, the CLI could prompt for a password
if the push/pull failed and the registry returned a 401 (Unauthorized)
Ironically, this feature did not work when using Docker Hub (and possibly
other registries using basic auth), due to some custom error handling added
in [moby@19a93a6e3d42], which also discards the registry's status code,
changing it to a 404;
curl -v -XPOST --unix-socket /var/run/docker.sock 'http://localhost/v1.50/images/create?fromImage=docker.io%2Fexample%2Fprivate&tag=latest'
...
< HTTP/1.1 404 Not Found
< Content-Type: application/json
...
{"message":"pull access denied for example/private, repository does not exist or may require 'docker login'"}
And due to a bug, other registries (not using basic auth) returned a generic
error, which resulted in a 500 Internal Server Error. That bug was fixed in
docker 28.2, now returning the upstream status code and trigger an interactive
prompt;
docker pull icr.io/my-ns/my-image:latest
Please login prior to pull:
Username:
This prompt would be triggered unconditionally, also if the CLI was run
non-interactively and no TTY attached;
docker pull icr.io/my-ns/my-image:latest < /dev/null
Please login prior to pull:
Username:
With this PR, no prompt is shown ;
# without STDIN attached
docker pull icr.io/my-ns/my-image:latest < /dev/null
Error response from daemon: error from registry: Authorization required. See https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-auth-req - Authorization required. See https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-auth-req
For now, the prompt is still shown otherwise;
docker pull icr.io/my-ns/my-image:latest
Login prior to pull:
Username: ^C
[moby@19a93a6e3d42]: https://github.com/moby/moby/commit/19a93a6e3d4213c56583bb0c843cf9e33d379752
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Currently, image tree visualization doesn't properly detect chips for
parent images, only looking at child images. This patch fixes the issue
by checking both parent and child images when determining which chips to
display in the tree view.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This patch enables the CLI to natively pick up the `DOCKER_AUTH_CONFIG`
environment variable and use it as a credential store.
The `DOCKER_AUTH_CONFIG` value should be a JSON object and must store
the credentials in a base64 encoded string under the `auth` key.
Specifying additional fields will cause the parser to fail.
For example:
`printf "username:pat" | openssl base64 -A`
`export DOCKER_AUTH_CONFIG='{
"auths": {
"https://index.docker.io/v1/": {
"auth": "aGk6KTpkY2tyX3BhdF9oZWxsbw=="
}
}
}'`
Credentials stored in `DOCKER_AUTH_CONFIG` would take precedence over any
credential stored in the file store (`~/.docker/config.json`) or native store
(credential helper).
Destructive actions, such as deleting a credential would result in a noop if
found in the environment credential. Credentials found in the file or
native store would get removed.
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
The RegistryAuthenticationPrivilegedFunc has some conditional logic to
add additional hints when logging in to the default (Docker Hub) registry.
Commit 9f4165ccb8 inadvertently passed the
wrong variable to PromptUserForCredentials, which caused it to show the
additional hints for Docker Hub.
Before this patch, hints were printed for the default (docker hub) registry;
docker pull icr.io/my-ns/my-image:latest
Login prior to pull:
Log in with your Docker ID or email address to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com/ to create one.
You can log in with your password or a Personal Access Token (PAT). Using a limited-scope PAT grants better security and is required for organizations using SSO. Learn more at https://docs.docker.com/go/access-tokens/
Username:
With this patch, those hints are omitted;
docker pull icr.io/my-ns/my-image:latest
Login prior to pull:
Username:
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Image config fields like Cmd, Entrypoint, Env, etc. will be omitted from
/images/{name}/json response when empty, starting in v29.0.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
- https://github.com/golang/go/issues?q=milestone%3AGo1.24.4+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.24.3...go1.24.4
This release includes 3 security fixes following the security policy:
- net/http: sensitive headers not cleared on cross-origin redirect
Proxy-Authorization and Proxy-Authenticate headers persisted on cross-origin redirects potentially leaking sensitive information.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting this issue.
This is CVE-2025-4673 and Go issue https://go.dev/issue/73816.
- os: inconsistent handling of O_CREATE|O_EXCL on Unix and Windows
os.OpenFile(path, os.O_CREATE|O_EXCL) behaved differently on Unix and Windows systems when the target path was a dangling symlink. On Unix systems, OpenFile with O_CREATE and O_EXCL flags never follows symlinks. On Windows, when the target path was a symlink to a nonexistent location, OpenFile would create a file in that location.
OpenFile now always returns an error when the O_CREATE and O_EXCL flags are both set and the target path is a symlink.
Thanks to Junyoung Park and Dong-uk Kim of KAIST Hacking Lab for discovering this issue.
This is CVE-2025-0913 and Go issue https://go.dev/issue/73702.
- crypto/x509: usage of ExtKeyUsageAny disables policy validation
Calling Verify with a VerifyOptions.KeyUsages that contains ExtKeyUsageAny unintentionally disabledpolicy validation. This only affected certificate chains which contain policy graphs, which are rather uncommon.
Thanks to Krzysztof Skrzętnicki (@Tener) of Teleport for reporting this issue.
This is CVE-2025-22874 and Go issue https://go.dev/issue/73612.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
These comments were added to enforce using the correct import path for
our packages ("github.com/docker/docker", not "github.com/moby/moby").
However, when working in go module mode (not GOPATH / vendor), they have
no effect, so their impact is limited.
Remove these imports in preparation of migrating our code to become an
actual go module.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This change eliminates the automatic creation of image tags in the
format `dockereng/cli-bin:sha-ad132f5` for every push.
They're not too useful, produce noise and use a lot of space.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Also renamed some vars for clarity, renamed a error-returns to prevent
shadowing, and fixed some linter warnings about unhandled errors.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
If we have an error type that we're checking a substring against, we
should really be checking using ErrorContains to indicate the right
semantics to assert.
Mostly done using these transforms:
find . -type f -name "*_test.go" | \
xargs gofmt -w -r 'assert.Assert(t, is.ErrorContains(e, s)) -> assert.ErrorContains(t, e, s)'
find . -type f -name "*_test.go" | \
xargs gofmt -w -r 'assert.Assert(t, is.Contains(err.Error(), s)) -> assert.ErrorContains(t, err, s)'
find . -type f -name "*_test.go" | \
xargs gofmt -w -r 'assert.Check(t, is.Contains(err.Error(), s)) -> assert.Check(t, is.ErrorContains(err, s))'
As well as some small fixups to helpers that were doing
strings.Contains explicitly.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
builder/remotecontext/git/gitutils_test.go:116:3: The copy of the 'for' variable "tc" can be deleted (Go 1.22+) (copyloopvar)
tc := tc
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is a partial revert of 389ada7188, which
switched from os/exec to the golang.org/x/sys/execabs package to mitigate
security issues (mainly on Windows) with lookups resolving to binaries in the
current directory.
from the go1.19 release notes https://go.dev/doc/go1.19#os-exec-path
> ## PATH lookups
>
> Command and LookPath no longer allow results from a PATH search to be found
> relative to the current directory. This removes a common source of security
> problems but may also break existing programs that depend on using, say,
> exec.Command("prog") to run a binary named prog (or, on Windows, prog.exe) in
> the current directory. See the os/exec package documentation for information
> about how best to update such programs.
>
> On Windows, Command and LookPath now respect the NoDefaultCurrentDirectoryInExePath
> environment variable, making it possible to disable the default implicit search
> of “.” in PATH lookups on Windows systems.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
cmd.Environ() is new in go1.19, and not needed for this specific case.
Without this, trying to use this package in code that uses go1.18 will fail;
builder/remotecontext/git/gitutils.go:216:23: cmd.Environ undefined (type *exec.Cmd has no field or method Environ)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Setting cmd.Env overrides the default of passing through the parent
process' environment, which works out fine most of the time, except when
it doesn't. For whatever reason, leaving out all the environment causes
git-for-windows sh.exe subprocesses to enter an infinite loop of
access violations during Cygwin initialization in certain environments
(specifically, our very own dev container image).
Signed-off-by: Cory Snider <csnider@mirantis.com>
While it is undesirable for the system or user git config to be used
when the daemon clones a Git repo, it could break workflows if it was
unconditionally applied to docker/cli as well.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Prevent git commands we run from reading the user or system
configuration, or cloning submodules from the local filesystem.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Keep It Simple! Set the working directory for git commands by...setting
the git process's working directory. Git commands can be run in the
parent process's working directory by passing the empty string.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Make the test more debuggable by logging all git command output and
running each table-driven test case as a subtest.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Older versions of Go don't format comments, so committing this as
a separate commit, so that we can already make these changes before
we upgrade to Go 1.19.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Simplify some of the logic, and add documentation about the package,
as well as warnings that this package should not be used as a general-
purpose utility.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
pkg/urlutil (despite its poorly chosen name) is not really intended as a generic
utility to handle URLs, and should only be used by the builder to handle (remote)
build contexts.
- IsURL() only does a very rudimentary check for http(s):// prefixes, without any
other validation, but due to its name may give incorrect expectations.
- IsGitURL() is written specifically with docker build remote git contexts in
mind, and has handling for backward-compatibility, where strings that are
not URLs, but start with "github.com/" are accepted.
Because of the above, this patch:
- moves the package inside builder/remotecontext, close to where it's intended
to be used (ideally this would be part of build/remotecontext itself, but this
package imports many other dependencies, which would introduce those as extra
dependencies in the CLI).
- deprecates pkg/urlutil, but adds aliases as there are some external consumers.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The io/ioutil package has been deprecated in Go 1.16. This commit
replaces the existing io/ioutil functions with their new definitions in
io and os packages.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
urlutil.IsUrl() was merely checking if the url had a http(s)://
prefix, which is just as well handled through using url.Parse()
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was only used inside gitutils,
and is written specifically for the requirements
there.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
`docker build` accepts remote repositories
using either the `git://` notation, or `git@`.
Docker attempted to parse both as an URL, however,
`git@` is not an URL, but an argument to `git clone`.
Go 1.7 silently ignored this, and managed to
extract the needed information from these
remotes, however, Go 1.8 does a more strict
validation, and invalidated these.
This patch adds a different path for `git@` remotes,
to prevent them from being handled as URL (and
invalidated).
A test is also added, because there were no
tests for handling of `git@` remotes.
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)."
# - windows-2022 # FIXME: some tests are failing on the Windows runner, as well as on Appveyor since June 24, 2018: https://ci.appveyor.com/project/docker/cli/history
- G306# G306: Expect WriteFile permissions to be 0600 or less (too restrictive; also flags "0o644" permissions)
- G307# G307: Deferring unsafe method "*os.File" on type "Close" (also EXC0008); (TODO: evaluate these and fix where needed: G307: Deferring unsafe method "*os.File" on type "Close")
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
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 ;\
{name:"builtin alias",c:&fakeCandidate{path:builtinAlias},invalid:`plugin "alias" duplicates an alias of builtin command "builtin"`},
{name:"fetch failure",c:&fakeCandidate{path:goodPluginPath,exec:false},invalid:fmt.Sprintf("failed to fetch metadata: faked a failure to exec %q",goodPluginPath)},
{name:"metadata not json",c:&fakeCandidate{path:goodPluginPath,exec:true,meta:`xyzzy`},invalid:"invalid character"},
{name:"empty schemaversion",c:&fakeCandidate{path:goodPluginPath,exec:true,meta:`{}`},invalid:`plugin SchemaVersion "" is not valid`},
{name:"invalid schemaversion",c:&fakeCandidate{path:goodPluginPath,exec:true,meta:`{"SchemaVersion": "xyzzy"}`},invalid:`plugin SchemaVersion "xyzzy" is not valid`},
{name:"no vendor",c:&fakeCandidate{path:goodPluginPath,exec:true,meta:`{"SchemaVersion": "0.1.0"}`},invalid:"plugin metadata does not define a vendor"},
{name:"empty vendor",c:&fakeCandidate{path:goodPluginPath,exec:true,meta:`{"SchemaVersion": "0.1.0", "Vendor": ""}`},invalid:"plugin metadata does not define a vendor"},
// ReexecEnvvar is the name of an ennvar which is set to the command
// used to originally invoke the docker CLI when executing a
// plugin. Assuming $PATH and $CWD remain unchanged this should allow
// the plugin to re-execute the original CLI.
ReexecEnvvar=metadata.ReexecEnvvar
// ResourceAttributesEnvvar is the name of the envvar that includes additional
// resource attributes for OTEL.
//
// Deprecated: The "OTEL_RESOURCE_ATTRIBUTES" env-var is part of the OpenTelemetry specification; users should define their own const for this. This const will be removed in the next release.
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"
@@ -147,17 +147,18 @@ container source to stdout.`,
opts.destination=args[1]
if!cmd.Flag("quiet").Changed{
// User did not specify "quiet" flag; suppress output if no terminal is attached
opts.quiet=!dockerCli.Out().IsTerminal()
opts.quiet=!dockerCLI.Out().IsTerminal()
}
returnrunCopy(cmd.Context(),dockerCli,opts)
returnrunCopy(cmd.Context(),dockerCLI,opts)
},
Annotations:map[string]string{
"aliases":"docker container cp, docker cp",
},
DisableFlagsInUseLine:true,
}
flags:=cmd.Flags()
flags.BoolVarP(&opts.followLink,"follow-link","L",false,"Always follow symbol link in SRC_PATH")
flags.BoolVarP(&opts.followLink,"follow-link","L",false,"Always follow symlinks in SRC_PATH")
flags.BoolVarP(&opts.copyUIDGID,"archive","a",false,"Archive mode (copy all uid/gid information)")
flags.BoolVarP(&opts.quiet,"quiet","q",false,"Suppress progress output during copy. Progress output is automatically suppressed if no terminal is attached")
assert.Error(t,err,"Container name cannot be empty")
}
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.
