These minor releases include 2 security fixes following the security policy:
- cmd/go: arbitrary code execution during build on darwin
On Darwin, building a Go module which contains CGO can trigger arbitrary code execution when using the Apple version of ld, due to
usage of the -lto_library flag in a "#cgo LDFLAGS" directive.
Thanks to Juho Forsén of Mattermost for reporting this issue.
This is CVE-2024-24787 and Go issue https://go.dev/issue/67119.
- net: malformed DNS message can cause infinite loop
A malformed DNS message in response to a query can cause the Lookup functions to get stuck in an infinite loop.
Thanks to long-name-let-people-remember-you on GitHub for reporting this issue, and to Mateusz Poliwczak for bringing the issue to
our attention.
This is CVE-2024-24788 and Go issue https://go.dev/issue/66754.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.22.3
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.10+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.9...go1.21.10
**- Description for the changelog**
```markdown changelog
Update Go runtime to 1.21.10
```
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit eb99994c75)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Before, for plugin commands, only the plugin name (such as `buildx`)
would be both included as `RootCmd` when passed to the hook plugin,
which isn't enough information for a plugin to decide whether to execute
a hook or not since plugins implement multiple varied commands (`buildx
build`, `buildx prune`, etc.).
This commit changes the hook logic to account for this situation, so
that the the entire configured hook is passed, i.e., if a user has a
hook configured for `buildx imagetools inspect` and the command
`docker buildx imagetools inspect alpine` is called, then the plugin
hooks will be passed `buildx imagetools inspect`.
This logic works for aliased commands too, so whether `docker build ...`
or `docker buildx build` is executed (unless Buildx is disabled) the
hook will be invoked with `buildx build`.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
hooks: include full match when invoking plugins
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
This will make Github render the log line as an error.
(copied from moby/moby fb92caf2aa6cf3664e11dc06ee10d114af300826)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Any PR that is labeled with any `impact/*` label should have a
description for the changelog and an `area/*` label.
(copied from moby/moby 1d473549e865ef6b90ee936c280f4bda677de39b)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
During normal plugin execution (from the CLI), the CLI configures the
plugin command it's about to execute in order to pass all environment
variables on, as well as to set the ReExec env var that informs the
plugin about how it was executed, and which plugins rely on to check
whether they are being run standalone or not.
This commit adds the same behavior to hook invocations, which is
necessary for some plugins to know that they are not running standalone
so that they expose their root command at the correct level.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Particularly for cases such as `docker exec -it`, it's relevant that the CLI
still executes hooks even if the exec exited with a non-zero exit code,
since this is can be part of a normal `docker exec` invocation depending on
how the user exits.
In the future, this might also be interesting to allow plugins to run
hooks after an error so they can offer error-state recovery suggestions,
although this would require additional work to give the plugin more
information about the failed execution.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Document feature option 'windows-dns-proxy', which can be used to
enable or disable forwarding of DNS requests from the daemon's
internal resolver to external servers.
Signed-off-by: Rob Murray <rob.murray@docker.com>
Before this commit, the CLI binary in `dockereng/cli-bin` image was
named `docker` regardless of platform.
Change the binary name to `docker.exe` in Windows images.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
full diff: https://github.com/golang/net/compare/v0.22.0...v0.23.0
Includes a fix for CVE-2023-45288, which is also addressed in go1.22.2
and go1.21.9;
> http2: close connections when receiving too many headers
>
> Maintaining HPACK state requires that we parse and process
> all HEADERS and CONTINUATION frames on a connection.
> When a request's headers exceed MaxHeaderBytes, we don't
> allocate memory to store the excess headers but we do
> parse them. This permits an attacker to cause an HTTP/2
> endpoint to read arbitrary amounts of data, all associated
> with a request which is going to be rejected.
>
> Set a limit on the amount of excess header frames we
> will process before closing a connection.
>
> Thanks to Bartek Nowotarski for reporting this issue.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit adds a "terminal" attribute to `BaseMetricAttributes`
that allows us to discern whether an invocation was from an interactive
terminal or not.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
This adds a default otel error handler for the cli in the debug package.
It uses logrus to log the error on the debug level and should work out
of the box with the `--debug` flag and `DEBUG` environment variable.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This is needed because the project does not have a `go.mod` file and
gets sent to go 1.16 semantics whenever it's imported by another project
and `any` doesn't exist in go 1.16, but the linter requires us to use
`any` here.
Setting the `go:build` tag forces the per-file language to the go
version specified.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This adds the code used by buildx and compose into the default CLI
program to help normalize the usage of these APIs and allow code reuse
between projects. It also allows these projects to benefit from
improvements or changes that may be made by another team.
At the moment, these APIs are a pretty thin layer on the OTEL SDK. It
configures an additional exporter to a docker endpoint that's used for
usage collection and is only active if the option is configured in
docker desktop.
This also upgrades the OTEL version to v1.19 which is the one being used
by buildkit, buildx, compose, etc.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This changes things to rely on a plugin server that manages all
connections made to the server.
An optional handler can be passed into the server when the caller wants
to do extra things with the connection.
It is the caller's responsibility to close the server.
When the server is closed, first all existing connections are closed
(and new connections are prevented).
Now the signal loop only needs to close the server and not deal with
`net.Conn`'s directly (or double-indirects as the case was before this
change).
The socket, when present in the filesystem, is no longer unlinked
eagerly, as reconnections require it to be present for the lifecycle of
the plugin server.
Co-authored-by: Bjorn Neergaard <bjorn.neergaard@docker.com>
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Signed-off-by: Bjorn Neergaard <bjorn.neergaard@docker.com>
CodeQL autobuild uses the makefile, but outside of a container, so let's
set this variable to prevent it having to wait 10 seconds;
Use "make dev" to start an interactive development container,
use "make -f docker.Makefile " to execute this target
in a container, or set DISABLE_WARN_OUTSIDE_CONTAINER=1 to
disable this warning.
Press Ctrl+C now to abort, or wait for the script to continue..
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
CodeQL 2.16.4's auto-build added support for multi-module repositories,
and is trying to be smart by searching for modules in every directory,
including vendor directories. If no module is found, it's creating one
which is ... not what we want, so let's give it a "go.mod".
Here's from a run in CI;
/opt/hostedtoolcache/CodeQL/2.16.4/x64/codeql/codeql version --format=json
{
"productName" : "CodeQL",
"vendor" : "GitHub",
"version" : "2.16.4",
"sha" : "9727ba3cd3d5a26f8b9347bf3c3eb4f565ac077b",
"branches" : [
"codeql-cli-2.16.4"
],
"copyright" : "Copyright (C) 2019-2024 GitHub, Inc.",
"unpackedLocation" : "/opt/hostedtoolcache/CodeQL/2.16.4/x64/codeql",
"configFileLocation" : "/home/runner/.config/codeql/config",
"configFileFound" : false,
"features" : {
"analysisSummaryV2Option" : true,
"buildModeOption" : true,
"bundleSupportsIncludeDiagnostics" : true,
"featuresInVersionResult" : true,
"indirectTracingSupportsStaticBinaries" : false,
"informsAboutUnsupportedPathFilters" : true,
"supportsPython312" : true,
"mrvaPackCreate" : true,
"threatModelOption" : true,
"traceCommandUseBuildMode" : true,
"v2ramSizing" : true,
"mrvaPackCreateMultipleQueries" : true,
"setsCodeqlRunnerEnvVar" : true
}
}
With 2.16.4, first it is unable to correlate files with the project, considering
them "stray" files;
Attempting to automatically build go code
/opt/hostedtoolcache/CodeQL/2.16.4/x64/codeql/go/tools/autobuild.sh
2024/03/16 15:54:34 Autobuilder was built with go1.22.0, environment has go1.21.8
2024/03/16 15:54:34 LGTM_SRC is /home/runner/work/cli/cli
2024/03/16 15:54:34 Found no go.work files in the workspace; looking for go.mod files...
2024/03/16 15:54:34 Found stray Go source file in cli/cobra.go.
2024/03/16 15:54:34 Found stray Go source file in cli/cobra_test.go.
2024/03/16 15:54:34 Found stray Go source file in cli/command/builder/client_test.go.
2024/03/16 15:54:34 Found stray Go source file in cli/command/builder/cmd.go.
...
It then tries to build the binary, but in go modules mode, which fails (it also
seems to be doing this for each and every directory);
Use "make dev" to start an interactive development container,
use "make -f docker.Makefile " to execute this target
in a container, or set DISABLE_WARN_OUTSIDE_CONTAINER=1 to
disable this warning.
Press Ctrl+C now to abort, or wait for the script to continue..
./scripts/build/binary
Building static docker-linux-amd64
+ go build -o build/docker-linux-amd64 -tags osusergo pkcs11 -ldflags -X "github.com/docker/cli/cli/version.GitCommit=38c3ff6" -X "github.com/docker/cli/cli/version.BuildTime=2024-03-16T17:20:38Z" -X "github.com/docker/cli/cli/version.Version=38c3ff6.m" -extldflags -static -buildmode=pie github.com/docker/cli/cmd/docker
cannot find package "github.com/docker/cli/cmd/docker" in any of:
/opt/hostedtoolcache/go/1.21.8/x64/src/github.com/docker/cli/cmd/docker (from $GOROOT)
/home/runner/go/src/github.com/docker/cli/cmd/docker (from $GOPATH)
make: *** [Makefile:62: binary] Error 1
2024/03/16 17:20:38 Running /usr/bin/make [make] failed, continuing anyway: exit status 2
2024/03/16 17:20:38 Build failed, continuing to install dependencies.
2024/03/16 17:20:38 The code in vendor/gotest.tools/v3/skip seems to be missing a go.mod file. Attempting to initialize one...
2024/03/16 17:20:38 Import path is 'github.com/docker/cli'
If also seems to be doing this for ... every package?
cat 0_codeql.log | grep 'you are not in a container' | wc -l
497
After which it starts to create modules out of every directory;
The code in internal/test/network seems to be missing a go.mod file. Attempting to initialize one...
The code in internal/test/notary seems to be missing a go.mod file. Attempting to initialize one...
The code in internal/test/output seems to be missing a go.mod file. Attempting to initialize one...
The code in opts seems to be missing a go.mod file. Attempting to initialize one...
The code in service seems to be missing a go.mod file. Attempting to initialize one...
The code in service/logs seems to be missing a go.mod file. Attempting to initialize one...
The code in templates seems to be missing a go.mod file. Attempting to initialize one...
The code in vendor seems to be missing a go.mod file. Attempting to initialize one...
The code in vendor/dario.cat seems to be missing a go.mod file. Attempting to initialize one...
The code in vendor/dario.cat/mergo seems to be missing a go.mod file. Attempting to initialize one...
...
Skipping dependency package regexp.
Skipping dependency package github.com/opencontainers/go-digest.
Skipping dependency package github.com/distribution/reference.
Extracting /home/runner/work/cli/cli/cli/command/go.mod
Done extracting /home/runner/work/cli/cli/cli/command/go.mod (1ms)
Extracting /home/runner/work/cli/cli/cli/command/go.mod
Done extracting /home/runner/work/cli/cli/cli/command/go.mod (0ms)
Extracting /home/runner/work/cli/cli/cli/command/go.mod
Done extracting /home/runner/work/cli/cli/cli/command/go.mod (0ms)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We originally added this -compat to keep a consistent format of
the vendor.mod files for cases where there were differences
between go versions.
I don't think we really need this anymore, so let's remove.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diffs:
- https://github.com/protocolbuffers/protobuf-go/compare/v1.31.0...v1.33.0
- https://github.com/golang/protobuf/compare/v1.5.3...v1.5.4
From the Go security announcement list;
> Version v1.33.0 of the google.golang.org/protobuf module fixes a bug in
> the google.golang.org/protobuf/encoding/protojson package which could cause
> the Unmarshal function to enter an infinite loop when handling some invalid
> inputs.
>
> This condition could only occur when unmarshaling into a message which contains
> a google.protobuf.Any value, or when the UnmarshalOptions.UnmarshalUnknown
> option is set. Unmarshal now correctly returns an error when handling these
> inputs.
>
> This is CVE-2024-24786.
In a follow-up post;
> A small correction: This vulnerability applies when the UnmarshalOptions.DiscardUnknown
> option is set (as well as when unmarshaling into any message which contains a
> google.protobuf.Any). There is no UnmarshalUnknown option.
>
> In addition, version 1.33.0 of google.golang.org/protobuf inadvertently
> introduced an incompatibility with the older github.com/golang/protobuf
> module. (https://github.com/golang/protobuf/issues/1596) Users of the older
> module should update to github.com/golang/protobuf@v1.5.4.
govulncheck results in our code shows that this does not affect the CLI:
govulncheck ./...
Scanning your code and 448 packages across 72 dependent modules for known vulnerabilities...
=== Symbol Results ===
No vulnerabilities found.
Your code is affected by 0 vulnerabilities.
This scan also found 1 vulnerability in packages you import and 0
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.
Use '-show verbose' for more details.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The command path sent for `docker build` should be `docker` rather than
`docker build` to be consistent with the other command paths.
* `docker buildx build` has a command path of `docker buildx`
* `docker builder build` has a command path of `docker builder`
* `docker image build` has a command path of `docker image`
The reason this gets set to `docker buildx` rather than `docker buildx
build` is because the `build` portion of the command path is processed
by the plugin. So the command path only contains the portions of the
command path that were processed by this tool.
Since the `build` of `docker build` gets forwarded to `buildx`, it is
not included in the command path.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Mark pulling legacy image formats as deprecated, and describe the
DOCKER_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE environment variable.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This code was only used as part of container.RunStats, so moving the code
there instead as a non-exported type. The actual use also did not have to
handle concurrency, so the mutex is removed in the new location.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The daemonOSType variable is already set when collecting stats, so we unlikely
hit this code in practice, and it would only be set if `collect()` failed and
we never got a stats response. If we do need to get this information, let's use
the OSVersion we already obtained from the ping response.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Replace 'docker daemon' with the wording used for the preceeding table,
to make it extra-clear that those flags apply to the default bridge.
Signed-off-by: Rob Murray <rob.murray@docker.com>
Added --detach/-d to stack rm. Setting --detach=false waits until
all of the stack tasks have reached a terminal state.
Co-authored-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: George Margaritis <gmargaritis@protonmail.com>
Added --detach and --quiet/-q flags to stack deploy. Setting --detach=false
waits until all of the stack services have converged. Shows progress bars for
each individual task, unless --quiet/-q is specified.
Co-authored-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: George Margaritis <gmargaritis@protonmail.com>
When a plugin is invoked, the docker cli will now set
`OTEL_RESOURCE_ATTRIBUTES` to pass OTEL resource attribute names to the
plugin as additional resource attributes. At the moment, the only
resource attribute passed is `cobra.command_path`.
All resource attributes passed by the CLI are prepended with the
namespace `docker.cli` to avoid clashing with existing ones the plugin
uses or ones defined by the user.
For aliased commands like the various builder commands, the command path
is overwritten to match with the original name (such as `docker
builder`) instead of the forwarded name (such as `docker buildx build`).
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
--iidfile logically specifies the IIDFILE and not the CIDFILE
(use --cidfile from docker-run.1.md for specifying a cidfile).
Signed-off-by: Max-Julian Pogner <max-julian@pogner.at>
The "github.com/docker/distribution" module moved to the distribution
org ("github.com/docker/distribution/v3"), and the new module deprecated
and removed the uuid package in favor of Google's UUID package.
While we still depend on the old module through packages and as an indirect
dependency, we may want to try avoid using it.
This patch replaces the use for the socket package, and replaces it for a
local utility, taking the same approach as `stringid.GenerateRandomID()`,
which should be random enough for this purpose.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- gha runners updated to ubuntu 22.04
- e2e now runs against moby 23.0, 24.0 and 25.0
- temporarily skip broken test for moby < 25
Signed-off-by: Christopher Petito <chrisjpetito@gmail.com>
Allow tests to check the negotiated API version used by the client.
Can be used to skip tests based on API versions, for example:
```go
skip.If(t, versions.LessThan(environment.DaemonAPIVersion(t), "1.44"))
```
will skip the test if the API version is older than 1.44
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Inline the variables used to define the command + args used in the
tests, which makes it slightly easier to see what's run.
Also explicitly define a context, in case we want to add telemetry
to these tests.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Seems that OpenBSD behaves like darwin and requires to unlink all
socket, after it was used.
Tested on OpenBSD 7.4
Signed-off-by: Kirill A. Korinsky <kirill@korins.ky>
extra_hosts in the compose file format allows '=' as a separator, and brackets
around IP addresses, the engine API doesn't.
So, transform the values when reading a compose file for 'docker stack'.
Signed-off-by: Rob Murray <rob.murray@docker.com>
Vendor docker/docker with API < 1.24 removed. This should not affect client
code.
43ffb1ee9d..9e075f3808
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Return error when user refuses at confirmation prompt
- Avoid sending space freed msg if user cancelled
- Fixed unit tests
Signed-off-by: Christopher Petito <chrisjpetito@gmail.com>
The `docker images` top-level subcommand predates the `docker <object> <verb>`
convention (e.g. `docker image ls`), but accepts a positional argument to
search/filter images by name (globbing). It's common for users to accidentally
mistake these commands, and to use (e.g.) `docker images ls`, expecting
to see all images, but ending up with an empty list because no image named
"ls" was found.
Disallowing these search-terms would be a breaking change, but we can print
and informational message to help the users correct their mistake.
Before this patch:
docker images ls
REPOSITORY TAG IMAGE ID CREATED SIZE
With this patch applied:
docker images ls
REPOSITORY TAG IMAGE ID CREATED SIZE
No images found matching "ls": did you mean "docker image ls"?
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The 20.10 branch reached EOL, so we can probably remove this
one again.
This reverts commit a3d53e319f.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adds a new plugin to the e2e plugins that simulates an older
plugin binary and a test suite to ensure older plugin binaries
keep behaving the same with newer CLI versions.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Use the `XXXVar` equivalent for flags that don't have a shorthand flag
instead of passing an empty string for the shorthand flag.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- rename confusing `target` argument, and use `containerID` in all places;
also make the variable more clearly local-scoped.
- rename `dockerCli` to be correctly camel-case, and to be consistent in
all places in this file.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Docker Engine 1.13 (API v1.25) added an option to set a custom default seccomp
profile on the daemon (see [moby/moby@b237189]). A warning was added on the
client-side if a non-default profile was set.
Docker Engine 23.0 (API v1.42) added warnings about non-default seccomp
profiles to the "info" response ([moby/moby@04f932a]), and the client was
updated to skip generating client-side warnings for API v1.42 and up in
[docker/cli@8964595].
These warnings are purely informational, and given that Docker Engine versions
before 23.0 have reached EOL, and any current version of the Engine now returns
the Warnings, it should be safe to remove the client-side fall back logic.
This patch removes the client-side fall back code for warnings that was
added in 8964595692.
[moby/moby@b237189]: b237189e6c
[moby/moby@04f932a]: 04f932ac86
[docker/cli@8964595]: 8964595692
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was deprecated in 298bddcc23 for
v25.0, and unused. This patch removes the function.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These types were deprecated in 7af509c7f1 (v25.0),
in favor of CLIOption, and are no longer used.
This patch removes the deprecated type-aliases, and while updating, also improves
the documentation for the CLIOption type.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Docker Engine 18.09 (API v1.39) introduced a Warnings field in the into response.
This enhancement was not gated by API version (see [moby/moby@a3d4238]), and
will be returned by Docker Engine 18.09 and up, regardless of the API version
chosen.
Likewise, the client-side code was written to prefer warnings returned by
the daemon, but to fall back on client-side detection of missing features
based on information in the Info response (see [docker/cli@3c27ce2]).
Thse warnings are purely informational, and given that Docker Engine versions
before 18.09 have reached EOL 6 Years ago, and any current version of the
Engine now returns the Warnings, it should be safe to remove the client-side
fall back logic.
This patch removes the client-side fall back code for warnings that was
added in 3c27ce21c9.
[moby/moby@a3d4238]: a3d4238b9c
[docker/cli@3c27ce2]: 3c27ce21c9
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
CLI reference for the base command was generated to cli.md
Changed it to docker.md to handle broken links.
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
Alias pages redirect to the canonical names, but these pages still
linked to the aliases, causing broken links when building the docs site.
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
- Add section about cdi-spec-dirs daemon configuration
- Add subsection about cdi in --device section for docker run
- Update `docker info` output example
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
The Docker daemon provides a versioned API for backward compatibility with old
clients. Docker clients can perform API-version negotiation to select the most
recent API version supported by the daemon (downgrading to and older version of
the API when necessary). API version negotiation was introduced in Docker v1.12.0
(API 1.24), and clients before that used a fixed API version.
Docker Engine versions through v25.0 provide support for all [API versions](https://docs.docker.com/engine/api/#api-version-matrix)
included in stable releases for a given platform. For Docker daemons on Linux,
the earliest supported API version is 1.12 (corresponding with Docker Engine
v1.0.0), whereas for Docker daemons on Windows, the earliest supported API
version is 1.24 (corresponding with Docker Engine v1.12.0).
Support for legacy API versions (providing old API versions on current versions
of the Docker Engine) is primarily intended to provide compatibility with recent,
but still supported versions of the client, which is a common scenario (the Docker
daemon may be updated to the latest release, but not all clients may be up-to-date
or vice versa). Support for API versions before that (API versions provided by
EOL versions of the Docker Daemon) is provided on a "best effort" basis.
Use of old API versions is very rare, and support for legacy API versions
involves significant complexity (Docker 1.0.0 having been released 10 years ago).
Because of this, we'll start deprecating support for legacy API versions.
Docker Engine v25.0 by default disables API version older than 1.24 (aligning
the minimum supported API version between Linux and Windows daemons). When
connecting with a client that uses an API version version older than 1.24,
the daemon returns an error. The following example configures the docker
CLI to use API version 1.23, which produces an error:
DOCKER_API_VERSION=1.23 docker version
Error response from daemon: client version 1.23 is too old. Minimum supported API version is 1.24, please upgrade your client to a newer version
An environment variable (`DOCKER_MIN_API_VERSION`) is introduced that allows
re-enabling older API versions in the daemon. This environment variable must
be set in the daemon's environment (for example, through a [systemd override
file](https://docs.docker.com/config/daemon/systemd/)), and the specified
API version must be supported by the daemon (`1.12` or higher on Linux, or
`1.24` or higher on Windows).
Support for API versions lower than `1.24` will be permanently removed in Docker
Engine v26, and the minimum supported API version will be incrementally raised
in releases following that.
We do not recommend depending on the `DOCKER_MIN_API_VERSION` environment
variable other than for exceptional cases where it's not possible to update
old clients, and those clients must be supported.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
In order to solve the "double notification" issue (see:
ef5e5fa03f)
without running the plugin process under a new pgid (see:
https://github.com/moby/moby/issues/47073) we instead check if we're
attached to a TTY, and if so skip signalling the plugin process since it
will already be signalled.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Build and push an image containing a static CLI binary for master branch
and every release branch and tag.
This is a slightly adjusted copy of the bin-image workflow from
docker/buildx (by @crazy-max).
Co-authored-by: CrazyMax <crazy-max@users.noreply.github.com>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Looks like this change caused docker-ce-packaging to fail;
dest=$PWD/build/mac; cd /home/ubuntu/workspace/release-packaging_ce-nightly/packaging/src/github.com/docker/cli/build && for platform in *; do \
arch=$(echo $platform | cut -d_ -f2); \
mkdir -p $dest/$arch/docker; \
cp $platform/docker-darwin-* $dest/$arch/docker/docker && \
tar -C $dest/$arch -c -z -f $dest/$arch/docker-25.0.0-rc.2.tgz docker; \
done
cp: cannot stat 'darwin_amd64/docker-darwin-*': No such file or directory
cp: cannot stat 'darwin_arm64/docker-darwin-*': No such file or directory
This reverts commit 6ad07f2a4b.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Changes were made in 1554ac3b5f to provide
a mechanism for the CLI to notify running plugin processes that they
should exit, in order to improve the general CLI/plugin UX. The current
implementation boils down to:
1. The CLI creates a socket
2. The CLI executes the plugin
3. The plugin connects to the socket
4. (When) the CLI receives a termination signal, it uses the socket to
notify the plugin that it should exit
5. The plugin's gets notified via the socket, and cancels it's `cmd.Context`,
which then gets handled appropriately
This change works in most cases and fixes the issue it sets out to solve
(see: https://github.com/docker/compose/pull/11292) however, in the case
where the user has a TTY attached and the plugin is not already handling
received signals, steps 4+ changes:
4. (When) the CLI receives a termination signal, before it can use the
socket to notify the plugin that it should exit, the plugin process
also receives a signal due to sharing the pgid with the CLI
Since we now have a proper "job control" mechanism, we can simplify the
scenarios by executing the plugins with their own process group id,
thereby removing the "double notification" issue and making it so that
plugins can handle the same whether attached to a TTY or not.
In order to make this change "plugin-binary" backwards-compatible, in
the case that a plugin does not connect to the socket, the CLI passes
the signal to the plugin process.
Co-authored-by: Bjorn Neergaard <bjorn.neergaard@docker.com>
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Signed-off-by: Bjorn Neergaard <bjorn.neergaard@docker.com>
As macOS does not support the abstract socket namespace, use a temporary
socket in $TMPDIR to connect with the plugin. Ensure this socket is
cleaned up even in the case of crash/ungraceful termination by removing
it after the first connection is accepted.
Co-authored-by: Laura Brehm <laurabrehm@hey.com>
Signed-off-by: Bjorn Neergaard <bjorn.neergaard@docker.com>
Build and push an image containing a static CLI binary for master branch
and every release branch and tag.
This is a slightly adjusted copy of the bin-image workflow from
docker/buildx (by @crazy-max).
Co-authored-by: CrazyMax <crazy-max@users.noreply.github.com>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Transform `VERSION` variable if it contains a git ref.
This is the same as moby does (with "<<<" bashism removed).
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
`scripts/make/binary` produces `docker` file that is a symlink to a
`docker-<platform>` file.
Make the `binary` Dockerfile target produce an image that only contains
the `docker` binary and not the symlink.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Update this function to accept a smaller interface, as it doesn't need
all of "CLI". Also return errors encountered during its operation (although
the caller currently has no error return on its own).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Slightly rephrase the intro (remove "easy reference"), and cross-reference
the corresponding section on the docker CLI page.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
golden.AssertBytes prints the failure as a bytes-array, which makes
it not human-readable; let's compare strings instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Docker v23.0 and up allow the daemon to be configured to have seccomp disabled
by default (using the "unconfined" profile as default), and introduced a new
"builtin" profile-name for the default (see [moby@f8795ed364586acd][1] and
[mnoby@ac449d6b5ad29a50][2]).
However, the CLI had no special handling for the "builtin" profile, which
resulted in it trying to load it as a file, which would fail;
docker run -it --rm --security-opt seccomp=builtin busybox
docker: opening seccomp profile (builtin) failed: open builtin: no such file or directory.
See 'docker run --help'.
This patch adds a special case for the "builtin" profile, to allow using the
default profile on daemons with seccomp disabled (unconfined) by default.
[1]: f8795ed364
[2]: ac449d6b5a
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 9e1f8d646e changed this to a
"nolint" comment due to a regression in GoSec. That regression was
fixed, so we can go back to use the more fine-grained "nosec" comment.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: https://github.com/klauspost/compress/compare/v1.17.2...v1.17.4
v1.17.4:
- huff0: Speed up symbol counting
- huff0: Remove byteReader
- gzhttp: Allow overriding decompression on transport
- gzhttp: Clamp compression level
- gzip: Error out if reserved bits are set
v1.17.3:
- fse: Fix max header size
- zstd: Improve better/best compression
- gzhttp: Fix missing content type on Close
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Using this option on the daemon will now produce an error (flag will
be removed entirely in v26.0).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The filter option is not currently exposed on the command-line,
but can be added as a flag in future. It will be used by compose
to filter the list of containers to include based on compose
labels.
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When running `docker stats` without a list of containers, `runStats` collects
an initial list of containers. If that API call fails, the error is sent to the
`closeChan`, however, `closeChan` is non-buffered, and nothing is reading the
channel until we received the initial list and start collecting stats.
This patch rewrites the code that gets the initial list of containers to
return the error if the API call fails. The `getContainerList` closure is
also removed and inlined to make the logic somewhat easier to read.
Before this patch, the command would hang without producing output;
docker stats
# hangs; no output
With this patch, the error is printed, and the CLI exits:
docker stats
Error response from daemon: some error occurred
echo $?
1
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The monitorContainerEvents and getContainerList closures where only
used when collecting "all" containers, so let's define them in that
branch of the code.
Also move some of the other variables closer to where they're used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We were unconditionally registering event-handlers for these events, but
the handler itself would ignore the event depending on the "all" option.
This patch skips registering the event handlers, so that we're not handling
them (saving some resources).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- memoize the API-client in a local variable.
- use struct-literals in some places.
- rename some variables for clarity and to prevent colliding with imports.
- make use of the event-constants (events.ContainerEventType).
- fix some grammar
- fix some minor linting warnings
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
no changes in vendored files
full diff: https://github.com/golang/crypto/compare/v0.16.0...v0.17.0
from the security mailing:
> Hello gophers,
>
> Version v0.17.0 of golang.org/x/crypto fixes a protocol weakness in the
> golang.org/x/crypto/ssh package that allowed a MITM attacker to compromise
> the integrity of the secure channel before it was established, allowing
> them to prevent transmission of a number of messages immediately after
> the secure channel was established without either side being aware.
>
> The impact of this attack is relatively limited, as it does not compromise
> confidentiality of the channel. Notably this attack would allow an attacker
> to prevent the transmission of the SSH2_MSG_EXT_INFO message, disabling a
> handful of newer security features.
>
> This protocol weakness was also fixed in OpenSSH 9.6.
>
> Thanks to Fabian Bäumer, Marcus Brinkmann, and Jörg Schwenk from Ruhr
> University Bochum for reporting this issue.
>
> This is CVE-2023-48795 and Go issue https://go.dev/issue/64784.
>
> Cheers,
> Roland on behalf of the Go team
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is a follow-up to 0e73168b7e
This repository is not yet a module (i.e., does not have a `go.mod`). This
is not problematic when building the code in GOPATH or "vendor" mode, but
when using the code as a module-dependency (in module-mode), different semantics
are applied since Go1.21, which switches Go _language versions_ on a per-module,
per-package, or even per-file base.
A condensed summary of that logic [is as follows][1]:
- For modules that have a go.mod containing a go version directive; that
version is considered a minimum _required_ version (starting with the
go1.19.13 and go1.20.8 patch releases: before those, it was only a
recommendation).
- For dependencies that don't have a go.mod (not a module), go language
version go1.16 is assumed.
- Likewise, for modules that have a go.mod, but the file does not have a
go version directive, go language version go1.16 is assumed.
- If a go.work file is present, but does not have a go version directive,
language version go1.17 is assumed.
When switching language versions, Go _downgrades_ the language version,
which means that language features (such as generics, and `any`) are not
available, and compilation fails. For example:
# 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)
Note that these fallbacks are per-module, per-package, and can even be
per-file, so _(indirect) dependencies_ can still use modern language
features, as long as their respective go.mod has a version specified.
Unfortunately, these failures do not occur when building locally (using
vendor / GOPATH mode), but will affect consumers of the module.
Obviously, this situation is not ideal, and the ultimate solution is to
move to go modules (add a go.mod), but this comes with a non-insignificant
risk in other areas (due to our complex dependency tree).
We can revert to using go1.16 language features only, but this may be
limiting, and may still be problematic when (e.g.) matching signatures
of dependencies.
There is an escape hatch: adding a `//go:build` directive to files that
make use of go language features. From the [go toolchain docs][2]:
> 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 patch adds `//go:build` directives to those files using recent additions
to the language. It's currently using go1.19 as version to match the version
in our "vendor.mod", but we can consider being more permissive ("any" requires
go1.18 or up), or more "optimistic" (force go1.21, which is the version we
currently use to build).
For completeness sake, note that any file _without_ a `//go:build` directive
will continue to use go1.16 language version when used as a module.
[1]: 58c28ba286/src/cmd/go/internal/gover/version.go (L9-L56)
[2]; https://go.dev/doc/toolchain#:~:text=The%20go%20line%20for,file%20to%20Go%201.22
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This driver has been deprecated and removed because the service
is no longer operational. Update the deprecated features docs to
mention it's been fully removed in Docker v25.0.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This driver has been deprecated and removed because the service
is no longer operational. Remove it from the tests to better reflect
reality.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This driver has been deprecated and removed because the service
is no longer operational. Remove it from the sample output.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The service has been discontinued on November 15, 2022:
> Dear Logentries user,
>
> We have identified you as the owner of, or collaborator of, a Logentries
> account.
>
> The Logentries service will be discontinued on November 15th, 2022. This
> means that your Logentries account access will be removed and all your
> log data will be permanently deleted on this date.
>
> Next Steps
> If you are interested in an alternative Rapid7 log management solution,
> InsightOps will be available for purchase through December 16th, 2022.
> Please note, there is no support to migrate your existing Logentries
> account to InsightOps.
>
> Thank you for being a valued user of Logentries.
>
> Thank you,
> Rapid7 Customer Success
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The cli/command package defined two option-types with the same signature.
This patch creates a new type instead (CLIOption), and makes the existing
types an alias for this (deprecating their old names).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Create an easier to digest introduction to container networking,
move the bulk of information to the networking overview page.
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
# - 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
run:echo "::error::PR title suggests targetting the ${{ steps.title_branch.outputs.branch }} branch, but is opened against ${{ github.event.pull_request.base.ref }}" && exit 1
@ -84,7 +84,7 @@ use for simple changes](https://docs.docker.com/opensource/workflow/make-a-contr
<tr>
<td>Community Slack</td>
<td>
The Docker Community has a dedicated Slack chat to discuss features and issues. You can sign-up <ahref="https://dockr.ly/slack"target="_blank">with this link</a>.
The Docker Community has a dedicated Slack chat to discuss features and issues. You can sign-up <ahref="https://dockr.ly/comm-slack"target="_blank">with this link</a>.
t.Fatalf("Error when reading tar archive: %s",err)
}
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.
