Support for connecting more than one network using the container run
command was added in v25.0 for API > 1.44 - describe that in the docs.
Signed-off-by: Rob Murray <rob.murray@docker.com>
The test didn't do anything useful...
- Despite its name it used newCreateCommand() instead of
newConnectCommand() with create flags/options instead of connect.
- There was no fake networkCreateFunc(), so the result of the 'connect'
wasn't checked.
- The fake networkConnectFunc() was never called, so didn't spot the
problem.
Signed-off-by: Rob Murray <rob.murray@docker.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>
actions/setup-go was trying to use caching, and produced a warning
because it expects a `go.mod` / `go.sum`;
Run actions/setup-go@v5
with:
go-version: 1.21
check-latest: false
token: ***
cache: true
env:
DISABLE_WARN_OUTSIDE_CONTAINER: 1
Setup go version spec 1.21
Found in cache @ /opt/hostedtoolcache/go/1.21.9/x64
Added go to the path
Successfully set up Go version 1.21
/opt/hostedtoolcache/go/1.21.9/x64/bin/go env GOMODCACHE
/opt/hostedtoolcache/go/1.21.9/x64/bin/go env GOCACHE
/home/runner/go/pkg/mod
/home/runner/.cache/go-build
Warning: Restore cache failed: Dependencies file is not found in /home/runner/work/cli/cli. Supported file pattern: go.sum
go version go1.21.9 linux/amd64
While our regular builds would use a containerised flow, CodeQL's autobuild
does not, and also doesn't seem to use our vendor directory (?) so for this
one it's probably fine to let it use some caching.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
Explicitly create the context and set it on the CLI, instead of depending on
NewDockerCli() to instance a default context.
Co-authored-by: Sebastiaan van Stijn <github@gone.nl>
Co-authored-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.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>
Paweł Gronowski
Sebastiaan van Stijn
cncal
Christopher Petito
Christopher Petito
Laura Brehm
Rob Murray
Andrew-Zipperer
Sebastiaan van Stijn
Alano Terblanche