Docker Desktop currently ships with the "cloud integration" wrapper,
which outputs an additional ContextType field in the JSON output.
While this field is non-standard, it made its way into Visual Studio's
Docker integration, which uses this to exclude "aci" and "eci" context
types that are not supported by Visual Studio.
This patch;
- conditionally adds a ContextType field to the JSON output
- but ONLY when using the default "{{json .}}" or "json" formats
(which are the formats used by Visual Studio)
- if the context is a "aci" or "eci" context, that type is
preserved, otherwise the default "moby" type is used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit fed9fa0f72)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The CLI does not currently expose options to add custom metadata to
contexts, but contexts support them.
- update test-utilities to allow setting custom metadata
- update the inspect test to verify that custom metadata is included
when inspecting a context.
- update the import/export tests to verify that custom metadata
is preserved.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 2e9eff235d)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
(cherry picked from commit faf096b25c)
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
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>
Commit 5011759056 implemented a fix that
caused the current environment to be discarded, using `os.Environ()`.
On Windows, `os.Environ()` may produce an incorrect value for `PWD`,
for which a new function was added in go1.19;
- https://tip.golang.org/doc/go1.19#osexecpkgosexec
- https://go-review.googlesource.com/c/go/+/401340
Replace the use of `os.Environ()` with `cmd.Environ()` to address that.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 5ccb48459b)
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>