The BuildCache.Parent field was removed in API v1.42 in [moby@e0db820].
While we had to keep the Go struct field around to backfil the field for
older API versions, it's no longer part of API v1.42 and up (using the
"omitempty" is just an implementation detail).
This patch corrects the swagger files to match this.
[moby@e0db820]: e0db8207f3
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit a5d9619093)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When DOCKERD_ROOTLESS_ROOTLESSKIT_MTU is not set, and ...
- DOCKERD_ROOTLESS_ROOTLESSKIT_NET is not set and slirp4netns
is selected, MTU defaults to 65520.
- DOCKERD_ROOTLESS_ROOTLESSKIT_NET=slirp4netns, MTU defaults
to 1500.
Change the logic so that, however slirp4netns is selected, MTU
defaults to 65520.
Signed-off-by: Rob Murray <rob.murray@docker.com>
(cherry picked from commit a6206f2da9)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
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>
(cherry picked from commit d7b4bb25bda9f86dc47bf5a8921ceb8b3a4a498c)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The default gc policy calculations based on percentage were calculated
improperly. These were calculated correctly in buildkit, but the
calculation method was not copied over correctly when updating the
values.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
(cherry picked from commit 1a7d7cc015)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This change reworks the Go mod tidy/vendor checks to run for all tracked Go modules by the project and fail for any uncommitted changes.
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
(cherry picked from commit f6e1bf2808)
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
The image inspect response has various fields that were deprecated as
part of the legacy builder, or Dockerfile syntax;
- The `Parent` field is only used for the legacy builder, and only set for
images that are built locally (i.e., not persisted when pulling an image).
- The `DockerVersion` field is only set when building images with the legacy
builder, and empty in most cases.
This patch deprecates the fields in the `InspectResponse` go struct, as
these fields will no longer be set in future once the legacy builder is
removed (`Parent`, `DockerVersion`). The legacy builder's deprecation in
[cli@4d8e457] / [cli@fd22746] (docker 23.0, API v1.42), however the related
API fields were kept so that information of legacy images would not be
discarded.
The API continues to return these fields if set, allowing the client to
print the fields for informational purposes when printing the raw response,
but these fields should be considered "transitional", and not be depended
on; deprecating the fields helps raise awareness.
[cli@4d8e457]: 4d8e45782b
[cli@fd22746]: fd2274692f
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit bd8a99b400)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `VirtualSize` field was deprecated in [moby@1261fe6], and omitted / removed
in API v1.44 in [moby@913b0f5]. We should not document the field as part of
those API versions as it no longer exists for those.
[moby@1261fe6]: 1261fe69a3
[moby@913b0f5]: 913b0f51ca
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 51cbd2ed16)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Starting with kernel v6.12, kernel memory TCP accounting is deprecated for cgroups v1.
Note: kernel memory TCP accounting is not supported by cgroups v2.
See d046ff46ee
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
(cherry picked from commit fb2f8115c8)
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 380ded6 restored a now-unused endpoint count to the
store, so that when the daemon is downgraded it exists for
the old code to find.
But, on network deletion, the endpoint count was not loaded
from the store - so the delete code saw the wrong "index",
and logged a warning before deleting it anyway.
Use DeleteObject instead of DeleteObjectAtomic, so the old
index isn't checked.
Signed-off-by: Rob Murray <rob.murray@docker.com>
(cherry picked from commit 94bcf89412)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This field was no longer used since Docker 1.11 (API version 1.23)
through [moby@aee260d] and [engine-api@9a9e468] but kept and deprecated
in [engine-api@167efc7], however the docs still used it in an example.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 08d014cac8)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This fixes a bug where no checkpoints would produce a `null` response
instead of an empty array:
```
$ docker run -d --name foo nginx:alpine
17fbeff7185733f101c38cb8208359dd0ef141116a1345da2d3c3f58c11f3e14
$ curl --unix-socket /var/run/docker.sock http://local/containers/foo/checkpoints
null
```
With this patch, this becomes:
```
$ curl --unix-socket /var/run/docker.sock http://local/containers/foo/checkpoints
[]
```
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit 646e068cf1)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The `BridgeNfIptables` and `BridgeNfIp6tables` were removed in API v1.50
in commit 6505d3877c, and only returned in
lower API versions.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 0fb46d08ad)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This change adds conditional logic to skip build and test jobs when a
pull request is labeled with 'ci/validate-only'.
The `govulncheck` job in the CI workflow is intentionally excluded from
this conditional logic, ensuring security vulnerability checks always
run regardless of the label.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit f0c069ffc9)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This example was added in 5e0e34fafd so that
the deprecated fields could be omitted from the example. Those fields were
removed from the swagger in 4dc961d0e9, but
the temporary example was not removed.
This patch removes the example, in favor of the per-field examples, which
were already in place.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 0fe1af95f3)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This example was added in 5e0e34fafd so that
the deprecated fields could be omitted from the example. Those fields were
removed from the swagger in 4dc961d0e9, but
the temporary example was not removed.
This patch removes the example, in favor of the per-field examples, which
were already in place.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 7bfbb6e8ca)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
`tar` utility is included in Windows 10 (17063+) and Windows Server
2019+ so we can use it directly.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit 8c8324b37f)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
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>
(cherry picked from commit 30406d42e3)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
When building a non-native platform, it's not unpacked by default.
History tries to read the disk usage of all the layer and it doesn't
handle missing snapshots gracefully.
This patch fixes this.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit 27fca93b65)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
BuildKit emits some additional events during build and they are not
`build.Result` so don't fail if we encounter one.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit ad830a47af)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Use `winio.RunWithPrivileges` to get the privileges.
It's better because it also locks the Go runtime thread so if the Go
scheduler decides to run this code on a different thread, it will still
have the expected privileges.
A naive attempt at fixing an error experienced by Docker Desktop user
when using Windows containers:
```
failed to register layer: re-exec error: exit status 1: output: hcsshim::ProcessUtilityVMImage \\?\C:\ProgramData\Docker\windowsfilter\<hash1>\UtilityVM: Access is denied.
failed to register layer: re-exec error: exit status 1: output: hcsshim::ProcessBaseLayer \\?\C:\ProgramData\Docker\windowsfilter\<hash2>: Access is denied.
failed to register layer: re-exec error: exit status 1: output: hcsshim::ProcessBaseLayer \\?\C:\ProgramData\Docker\windowsfilter\<hash3>: Access is denied.
```
Unfortunately I can't reproduce the issue on a Windows VM, but this
definitely won't hurt.
At least, I verified that the daemon still works on Windows.
Inspired by: https://github.com/containerd/containerd/issues/8206
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit f66f555ad4)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
container.NetworkSettingsBase is deprecated in v28.4, and scheduled for
removal in v29. However, it contains three fields that aren't deprecated
and that will be moved to NetworkSettings.
Update the deprecation notice on NetworkSettingsBase to advise users
to access NetworkSettingsBase's fields through NetworkSettings.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
This struct is only used to report the networking state for the default
bridge network when the container is connected to it.
It was deprecated in v1.09 (API v1.21), and scheduled for removal in
v1.11. Unfortunately, the deprecation warning was wrongly formatted in
the Go code. However, deprecation warnings are already present in
swagger.yaml, so don't touch it.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
(cherry picked from commit b7c597ec35)
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Most fields in NetworkSettingsBase are deprecated, so deprecate the
whole struct. The few fields which aren't deprecated will move to the
NetworkSettings struct in v29.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
(cherry picked from commit 80bb864fd6)
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
This field provides little value as it's only set when the daemon is
started with --bridge flag specified, and the inspected container is
connected to the default bridge network.
Unfortunately, there's no equivalent field in NetworkSettings.Networks.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
(cherry picked from commit 16dc39136c)
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Ensure events for containerd backend are properly sent when deleted via
image prune. Fix prune output to only show deleted images rather than
the deletion of each blob.
Signed-off-by: Derek McGowan <derek@mcg.dev>
(cherry picked from commit da2b1a2930)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When a endpoint's net.IPNet is loaded from store and converted
to a netip.Addr, unmap it so that iptables rules don't contain
IPv4-mapped IPv6 addresses.
Signed-off-by: Rob Murray <rob.murray@docker.com>
(cherry picked from commit 071e6472db)
Signed-off-by: Rob Murray <rob.murray@docker.com>
The go-connections package implementation is only a shallow wrapper
around go-winio for named pipes; use the go-winio implementation
directly.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit accbfde61e)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Also rename the "container" argument, which shadowed an import.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 44972d7427)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The fixture was using an invalid formatted Capability, which wasn't
detected in the old API code, but fails with the API module, for example:
=== RUN TestPluginsWithRuntimes
plugin_test.go:269: assertion failed: error is not nil: json: error calling MarshalText for type plugin.CapabilityID: capability "docker.dummy/1.0" cannot contain a dot
--- FAIL: TestPluginsWithRuntimes (0.63s)
=== RUN TestPluginBackCompatMediaTypes
plugin_test.go:331: assertion failed: error is not nil: json: error calling MarshalText for type plugin.CapabilityID: capability "docker.dummy/1.0" cannot contain a dot
--- FAIL: TestPluginBackCompatMediaTypes (0.11s)
FAIL
This patch applies the same changes as ee560a3b23
in the master branch.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Move these types back to their old location, but alias in the
new location so that any user of the old types would not require
to update.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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.
[moby@aee260d]: aee260d4eb
[engine-api@9a9e468]: 9a9e468f50
[engine-api@167efc7]: 167efc72bb
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 6cfff7e880)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Fix the compilation issue on aix, android and solaris due to wrong use of maxMapSize
- Add protection on meta page when it's being written
- Correct the incorrect usage of debug method
- Add clarification on the option InitialMmapSize
- Fix the crash when writing huge values
full diff: https://github.com/etcd-io/bbolt/compare/v1.4.0...v1.4.2
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit a2aa7be724)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This test was added in 72f1881df1, which
introduced a dedicated `events.Message` struct for the events endpoints.
Before that change, events would produce a generic `JSONMessage`, and
the test is to verify that an `events.Message` could be successfully
unmarshalled to a `JSONMessage`.
The change above was part of docker 1.10 (API version 1.22), which we
no longer support, so we can remove this test.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit eac4c43aaa)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds the "non-blocking" part of the TestEventsBackwardsCompatible
as a separate test, as it's not related to the backward-compatibility
part of that test.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit b0d9a90f45)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These types are only used internal to the daemon and will be removed from the api in the next release.
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
On API version v1.22 and older, the `JSONMessage` was used to produce the
`/events` response. However, commit 72f1881df1
introduced an `events.Message` type that replaced the use of `JSONMessage`
for that purpose.
The `JSONMessage` is no longer used to unmarshal these messages, and users
of this package should not depend on these fields, and use the `events.Message`
type instead for unmarshaling the `/events` response.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Preserve error formatting without importing internal package from the
root package.
Signed-off-by: Derek McGowan <derek@mcg.dev>
(cherry picked from commit 374fa24a53)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This utility was added in 83b5729f64 to
replace httputils.ParseServerHeader, which was added to print a warning
on Windows in 126529c6d0. At the time, the
only available option to detect the daemon's OS was to parse the `Server`
header, which contained the version of Docker as well as the OS.
However, 7199522ea2 introduced an `OSType`
("Ostype") header that's included on all responses, and a later commit
e9dac5ef5e changed that to also be included
when producing an error for unsupported API versions.
Note that the casing in the midddleware was changed from `OSType` to
`Ostype` (normalized form) in 76a5ca1d4d,
but headers are case-insensitive, and `header.Get()` should handle either
case in the response.
In short; every API response contains an "Ostype" header, which already
contains the OS ("windows" or "linux") that doesn't require any parsing,
so let's put that header to use.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit fcf3ff1b2f)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- release notes: https://github.com/opencontainers/runc/releases/tag/v1.3.0
- full diff: https://github.com/opencontainers/runc/compare/v1.2.6..v1.3.0
-----
This is the first release of the 1.3.z release branch of runc. It
contains a few minor fixes for issues found in 1.3.0-rc.2.
This is the first release of runc that will follow our new release and
support policy (see RELEASES.md for more details). This means that, as
of this release:
* As of this release, the runc 1.2.z release branch will now only
receive security and "significant" bugfixes.
* Users are encouraged to plan migrating to runc 1.3.0 as soon as
possible.
* Due to its particular situation, runc 1.1.z is officially no longer
supported and will no longer receive any updates (not even for
critical security issues). Users are urged (in the strongest possible
terms) to upgrade to a supported version of runc.
* Barring any future changes to our release policy, users should expect
a runc 1.4.0 release in late October 2025.
Fixed
* Removed pre-emptive "full access to cgroups" warning when calling
`runc pause` or `runc unpause` as an unprivileged user without
`--systemd-cgroups`. Now the warning is only emitted if an actual permission
error was encountered.
* Several fixes to our CI, mainly related to AlmaLinux and CRIU.
Changed
* In runc 1.2, we changed our mount behaviour to correctly handle clearing
flags. However, the error messages we returned did not provide as much
information to users about what clearing flags were conflicting with locked
mount flags. We now provide more diagnostic information if there is an error
when in the fallback path to handle locked mount flags.
* Upgrade our CI to use golangci-lint v2.0.
* `runc version` information is now filled in using `//go:embed` rather than
being set through `Makefile`. This allows `go install` or other non-`make`
builds to contain the correct version information. Note that
`make EXTRA_VERSION=...` still works.
* Remove `exclude` directives from our `go.mod` for broken `cilium/ebpf`
versions. `v0.17.3` resolved the issue we had, and `exclude` directives are
incompatible with `go install`.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit f5f984eec6)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This test is failing frequently (50%) on Windows;
=== FAIL: github.com/docker/docker/integration/container TestExecResize/success (0.01s)
exec_test.go:144: assertion failed: error is not nil: Error response from daemon: NotFound: exec: '9c19c467436132df24d8b606b0c462b1110dacfbbd13b63e5b42579eda76d7fc' in task: '7d1f371218285a0c653ae77024a1ab3f5d61a5d097c651ddf7df97364fafb454' not found: not found
Let's keep the test, but log the failure and skip on Windows.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit fd8fec18cd)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This test was failing frequently on Windows, waiting for the state
of the container to be "running" after restarting, however, this
would race because the command of the container was very short-lived;
=== Failed
=== FAIL: github.com/docker/docker/integration-cli TestDockerCLIRestartSuite/TestRestartStoppedContainer (37.00s)
docker_cli_restart_test.go:42: assertion failed: error is not nil: condition ""true" == "false"" not true in time (20s)
Ironically, that check was added in 48ccdd46ae
to make the test less flaky.
This patch takes the approach from TestRestartRunningContainer, which had
similar issues on Windows that were addressed in bae22d167c
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit a327a9f341)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This test depended on the container to die after running the `true` command,
but this condition failed frequently on Windows 2025.
=== Failed
=== FAIL: github.com/docker/docker/integration/container TestRemoveContainerWithVolume (32.68s)
remove_test.go:61: timeout hit after 10s: waiting for container State.Status to be 'exited', currently 'running'
While this may be revealing an actual issue (and we should have a test for
that), it's irrelevant for this test, which;
- creates and starts a container with an anonymous volume
- verifies the anonymous volume was created
- removes the container
- verifies the anonymous volume was removed
We can force-remove the container to kill, and removed it; we probably
could've sufficed with "container create" (without starting), but it's
good to add extra coverage, in case running the container impacts whether
we're able to remove the volume.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit d6c90dcb87)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Correctly parse HTTP response that doesn't contain an HTTP version with a decimal place:
```
< HTTP/2 307
```
The previous version would only match strings like `HTTP/2.0 307`.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit 359a881cea)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This function depended on the non-exported `Args.values` field.
With the migration of the API to a separate module, we will
alias that type, and remove the deprecated `ToParamWithVersion`
function.
This means that we cannot alias the function, and aliasing the
`Args` type means we can't access the non-exported field.
This patch reimplements `ToParamWithVersion` by unmarshaling
the JSON output of the current format, and re-marshaling it
to the legacy format.
This is not optimal, but this code-path would only be used
for API versions that are deprecated, and is not to be used
for any new code.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The strslice.StrSlice type is a string-slice with a custom JSON Unmarshal
function to provide backward-compatibility with older API requests from
before docker 1.7 (see [moby@17d6f00] and [moby@ea4a067]), which used a
string instead of an array of strings for some fields (Cmd, Entrypoint).
We no longer support those API versions, and we no longer support pulling
v1 images that may contain such a config, so we can remove these tests that
validate the behavior as they're invalid API requests.
This;
- removes DockerAPISuite.TestPostContainerAPICreateWithStringOrSliceEntrypoint
- removes DockerAPISuite.TestPostContainersCreateWithStringOrSliceCmd
- removes DockerAPISuite.TestPostContainersCreateWithStringOrSliceCapAddDrop
- updates DockerAPISuite.TestContainerAPIPostCreateNull, which used an invalid example
[moby@17d6f00]: 17d6f00ec2
[moby@ea4a067]: ea4a06740b
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 1378604cc3)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Because:
- it's the last thing outside 'daemon/' that uses libnetwork's
resolvconf package
- there's better coverage of the host resolv.conf transformations
in the resolvconf package's unit tests
- there are integration tests that don't modify the test host's
resolv.conf file in 'integration/networking/resolvconf_test.go'
Signed-off-by: Rob Murray <rob.murray@docker.com>
(cherry picked from commit 3003c56c57)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before ea29dffaa5, the image create endpoint
had a [fallback for very old client versions][1] that would send authentication
as body instead of through the `X-Registry-Auth` header.
However, the implementation of this fallback did not handle empty bodies,
resulting in an `io.EOF` error to be returned when trying to parse the
body as JSON.
In practice, this problem didn't happen when using the CLI, because even
if no authentication was present, `registry.EncodeAuthConfig()` (used by
the CLI to set the `X-Registry-Auth` header) would produce an empty JSON
document (`{}`), which would be encoded in base64 (`e30=`), so we would
never set an empty `X-Registry-Auth` (but other clients may have hit this
situation). That behavior was unexpected, because not all registries require
authentication, and omitting the `X-Registry-Auth` should be valid. We
also want to have more flexibility in authentication (and being able to
distinguish unauthenticated requests, so that we can fallback to
alternative paths).
Unfortunately, we can't change existing daemons, so must account for the
faulty fallback. Currently, omitting the `X-Registry-Auth` produces an
error, but we can avoid this by unconditionally sending a body, which
may be an empty JSON document (`{}`).
I explored possible options for this; we can either construct our own
empty JSON (`json.RawMessage("{}")`) to be explicit that we're sending
empty JSON, but [`encodeBody()`][2] is currently hard-coded to expect
JSON requests, and unconditionally calls [`encodeData`][3], which
encodes to JSON, so we may as well take advantage of `http.NoBody`,
which gets marshaled to an empty JSON document;
https://go.dev/play/p/QCw9dJ6LGQu
package main
import (
"encoding/json"
"fmt"
"net/http"
)
func main() {
body, _ := json.Marshal(http.NoBody)
fmt.Println(string(body))
}
Before this patch, a client omitting `X-Registry-Auth` (and no body)
would produce an error;
docker pull -q busybox
docker tag busybox 127.0.0.1:5001/myimage:latest
docker run -d --name registry -p 127.0.0.1:5001:5000 registry:3
docker push 127.0.0.1:5001/myimage:latest
Error response from daemon: bad parameters and missing X-Registry-Auth: invalid X-Registry-Auth header: EOF
With this patch applied, no error is produced;
docker pull -q busybox
docker tag busybox 127.0.0.1:5001/myimage:latest
docker run -d --name registry -p 127.0.0.1:5001:5000 registry:3
docker push 127.0.0.1:5001/myimage:latest
The push refers to repository [127.0.0.1:5001/myimage]
189fdd150837: Pushed
latest: digest: sha256:68a0d55a75c935e1101d16ded1c748babb7f96a9af43f7533ba83b87e2508b82 size: 610
[1]: 63fcf7d858/api/types/registry/authconfig_test.go (L109-L114)
[2]: 63fcf7d858/client/request.go (L67-L87)
[3]: 63fcf7d858/client/request.go (L296-L304)
[4]: ea29dffaa5
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit b1ce0c89f0)
Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
- 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>
(cherry picked from commit 0a047e825c)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The TestNatNetworkICC and TestFlakyPortMappedHairpinWindows (TestPortMappedHairpinWindows)
tests were frequently failing on Windows with a context timeout;
=== FAIL: github.com/docker/docker/integration/networking TestNatNetworkICC/User_defined_nat_network (9.67s)
nat_windows_test.go:62: assertion failed: error is not nil: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.51/containers/4357bd24c9b77b955ee961530d1f552ce099b3dcbeb396db599971b2396d8b08/start": context deadline exceeded
panic.go:636: assertion failed: error is not nil: Error response from daemon: error while removing network: network mynat has active endpoints (name:"ctr2" id:"dc8d597dafef")
=== FAIL: github.com/docker/docker/integration/networking TestNatNetworkICC (18.34s)
=== FAIL: github.com/docker/docker/integration/networking TestFlakyPortMappedHairpinWindows (13.02s)
nat_windows_test.go:110: assertion failed: error is not nil: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.51/containers/65207ae3d6953d85cd2123feac45af60b059842d570d4f897ea53c813cba3cb4/start": context deadline exceeded
panic.go:636: assertion failed: error is not nil: Error response from daemon: error while removing network: network clientnet has active endpoints (name:"amazing_visvesvaraya" id:"18add58d415e")
These timeouts were set in c1ab6eda4b and
2df4391473, and were shared between Linux
and Windows; likely Windows is slower to start, so these timeouts to be
expected.
Let's increase the context timeout to give it a bit more time.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 0ea28fede0)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The same env-var is used for action/setup-go as for overriding
the default Go version in Dockerfiles, however action/setup-go
only accepts SemVer (e.g. 1.25.0-rc.1) whereas the official golang
image follows the Go project's versioning, which doesn't use
a SemVer-compatible format (go1.25rc1 / 1.25rc1).
Trying to use the same "GO_VERSION" value for both will therefore
fail.
As we're already updating the default version in the Dockerfile to
the version we want to use, let's remove the --build-arg, and use
the default that's set in the Dockerfile.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit fa4f3c979f)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
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>
(cherry picked from commit 38b98bcf68)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
We had some runs timeout after 120 minutes; expected duration is much
lower than that, so let's lower the timeout to make actions fail faster.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 0a30b98447)
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Commit 8e6cd44ce4 added synchronisation to
wait for the container's status to be updated in memory. However, since
952902efbc, a defer was used to produce
the container's "stop" event.
As a result of the sychronisation that was added, the "die" event would
now be produced before the "stop" event.
This patch moves the locking inside the defer to restore the previous
behavior.
Unfortunately the order of events is still not guaranteed, because events
are emited from multiple goroutines that don't have synchronisation between
them; this is something to look at for follow ups. This patch keeps the status
quo and should preserve the old behavior, which was "more" correct in most
cases.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 062082ec9b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Validation of registry mirrors was performed during daemon startup,
but after the config-file was validated. As a result, the `--validate`
option would incorrectly print that the configuration was valid, but
the daemon would fail to start;
echo '{"registry-mirrors":["example.com"]}' > my-config.json
dockerd --config-file ./my-config.json --validate
configuration OK
dockerd --config-file ./my-config.json
# ...
failed to start daemon: invalid mirror: no scheme specified for "example.com": must use either 'https://' or 'http://'
With this patch applied, validation is also performed as part of the
daemon config validation;
echo '{"registry-mirrors":["example.com"]}' > my-config.json
dockerd --config-file ./my-config.json --validate
unable to configure the Docker daemon with file ./my-config.json: merged configuration validation from file and command line flags failed: invalid mirror: no scheme specified for "example.com": must use either 'https://' or 'http://'
# fix the invalid config
echo '{"registry-mirrors":["https://example.com"]}' > my-config.json
dockerd --config-file ./my-config.json --validate
configuration OK
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 1d8545d60c)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this patch, a missing scheme would sometimes produce a confusing
error message. If no scheme was specified at all, an empty "" would be
included in the message;
echo '{"registry-mirrors":["example.com"]}' > my-config.json
dockerd --config-file ./my-config.json
# ...
failed to start daemon: invalid mirror: unsupported scheme "" in "example.com"
If a scheme was missing, but a port was included, the hostname would be
printed as the scheme;
echo '{"registry-mirrors":["example.com:8080"]}' > my-config.json
dockerd --config-file ./my-config.json
# ...
failed to start daemon: invalid mirror: unsupported scheme "example.com" in "example.com:8080"
With this patch applied, the error messages are slightly more user-friendly;
echo '{"registry-mirrors":["example.com"]}' > my-config.json
dockerd --config-file ./my-config.json
# ...
failed to start daemon: invalid mirror: no scheme specified for "example.com": must use either 'https://' or 'http://'
echo '{"registry-mirrors":["example.com:8080"]}' > my-config.json
dockerd --config-file ./my-config.json
# ...
failed to start daemon: invalid mirror: no scheme specified for "example.com:8080": must use either 'https://' or 'http://'
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 307c18598d)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This field was added in 5130fe5d38, which
added it for use as intermediate struct when parsing CLI flags (through
`runconfig.ParseExec`) in c786a8ee5e.
Commit 9d9dff3d0d rewrote the CLI to use
Cobra, and as part of this introduced a separate `execOptions` type in
`api/client/container`.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 0c182d4d57)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use the tagged version instead of the v2.0.0-20250613170222-a45be3cac15c
pseudo-version. The referenced commit has not changed.
Signed-off-by: Cory Snider <csnider@mirantis.com>
(cherry picked from commit c3ac979ecf)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The IdentityMapping and Identity types are still used internally, but
should be considered transitional.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit b7ef527bdc)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
After pushing the multi-platform index fails due to missing content, we
retry with the single-platform manifest. While the target descriptor was
changed for the second push, the actual target digested reference still
pointed to the original multi-platform index. Obviously, with the
fallback that didn't really work correctly, because the multi-platform
index is not pushed.
This commit fixes the issue by updating the target reference to point to
the single-platform manifest.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
It checked for "Bind for 0.0.0.0:80 failed: port is already
allocated". But, since commit d662091 ("portallocator: always
check for ports allocated for 0.0.0.0/::"), the message is
sometimes about ":::80".
Signed-off-by: Rob Murray <rob.murray@docker.com>
This parameter was already supported for some time in the backend (for
purposes related to docker system prune). It was also already present in
the imagetypes.ListOptions but was never actually handled by the client.
Make it available by default in the response.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
It looks like the error returned by Windows changed in Windows 2025; before
Windows 2025, this produced a `ERROR_INVALID_NAME`;
The filename, directory name, or volume label syntax is incorrect.
But Windows 2025 produces a `ERROR_DIRECTORY` ("The directory name is invalid."):
CreateFile \\\\?\\Volume{d9f06b05-0405-418b-b3e5-4fede64f3cdc}\\windows\\system32\\drivers\\etc\\hosts\\: The directory name is invalid.
Docs; https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 7c09fa25fd and
e8c269843c removed support for schema1, but
we still enabled the schema1 conversion in containerd, causing the error
produced by dockerd to be shadowed by the error from containerd;
Before this patch, we would get an error from containerd;
docker pull docker:1.0
Error response from daemon: failed to get converter for "docker.io/library/docker:1.0": Pulling Schema 1 images have been deprecated and disabled by default since containerd v2.0. As a workaround you may set an environment variable `CONTAINERD_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE=1`, but this will be completely removed in containerd v2.1.
After enabling that env-var, it would return the error from dockerd;
CONTAINERD_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE=1 dockerd --feature containerd-snapshotter
docker pull docker:1.0
Error response from daemon: Docker Image Format v1 and Docker Image manifest version 2, schema 1 support has been removed. Suggest the author of docker.io/library/docker:1.0 to upgrade the image to the OCI Format or Docker Image manifest v2, schema 2. More information at https://docs.docker.com/go/deprecated-image-specs/
With this patch, we immediately return the error from dockerd;
docker pull docker:1.0
Error response from daemon: Docker Image Format v1 and Docker Image manifest version 2, schema 1 support has been removed. Suggest the author of docker.io/library/docker:1.0 to upgrade the image to the OCI Format or Docker Image manifest v2, schema 2. More information at https://docs.docker.com/go/deprecated-image-specs/
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Mostly for readability, and to avoid linters suggesting to move the
default condition outside of the if/else.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Some linters were complaining about the testing.T not being used; put
it to use to silence the linter.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- scope variables locally to the if/else if
- use if/else if to try to make it more clear it's a "best effort" before
falling through to other ways of resolving the image reference
- remove outdated TODO, now that containerd errdefs can be used for either
moby, or containerd error definitions.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- 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>
Added backend code to support the exact same interface
used today for Nvidia GPUs, allowing customers to use
the same docker commands for both Nvidia and AMD GPUs.
Signed-off-by: Sudheendra Gopinath <sudheendra.gopinath@amd.com>
Reused common functions from nvidia_linux.go.
Removed duplicate code in amd_linux.go by reusing
the init() and countToDevices() functions in
nvidia_linux.go. AMD driver is registered in init().
Signed-off-by: Sudheendra Gopinath <sudheendra.gopinath@amd.com>
Renamed amd-container-runtime constant
Signed-off-by: Sudheendra Gopinath <sudheendra.gopinath@amd.com>
Removed empty branch to keep linter happy.
Also renamed amd_linux.go to gpu_amd_linux.go.
Signed-off-by: Sudheendra Gopinath <sudheendra.gopinath@amd.com>
Renamed nvidia_linux.go and gpu_amd_linux.go.
Signed-off-by: Sudheendra Gopinath <sudheendra.gopinath@amd.com>
commit 4dc961d0e9 removed deprecated
fields from the image inspect response for API v1.50 and up. As
part of that change, it changed the type used for the Config field
to use the docker image spect structs, which embeds the OCI image
spec structs.
While the OCI image spect struct contains the same fields as we
used before, those fields also have "omitempty" set, which means
they are now omitted when empty.
We should probably consider deprecating that behavior in the API,
and call out that these fields are omitted if not set, but in the
meantime, we can add them back with their default (zero) value.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
More recent versions of go-swagger failed on this, because the value
is interpolated as JSON numberic value, which assumes int64 (signed).
Quote the value to prevent it being handled before validated against
uint64.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
More recent versions of go-swagger failed on this, because the value
is interpolated as JSON numberic value, which assumes int64 (signed).
Quote the value to prevent it being handled before validated against
uint64.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Also adding test-cases for;
- empty options for all fields
- invalid nameServer (domain instead of IP).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Gracefully leaving the memberlist cluster is a best-effort operation.
Failing to successfully broadcast the leave message to a peer should not
prevent NetworkDB from cleaning up the memberlist instance on close. But
that was not the case in practice. Log the error returned from
(*memberlist.Memberlist).Leave instead of returning it and proceed with
shutting down irrespective of whether Leave() returns an error.
Signed-off-by: Cory Snider <csnider@mirantis.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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 `moby/moby-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>
Use platform MatchComparer when checking for matching platforms.
Also, add unit test to ensure the merging of defined and host-supported
platforms works correctly.
Signed-off-by: Cesar Talledo <cesar.talledo@docker.com>
We set SO_REUSEADDR on sockets used for host port mappings by
docker-proxy - which means it's possible to bind the same port
on a specific address as well as 0.0.0.0/::.
For TCP sockets, an error is raised when listen() is called on
both sockets - and the port allocator will be called again to
avoid the clash (if the port was allocated from a range, otherwise
the container will just fail to start).
But, for UDP sockets, there's no listen() - so take more care
to avoid the clash in the portallocator.
The port allocator keeps a set of allocated ports for each of
the host IP addresses it's seen, including 0.0.0.0/::. So, if a
mapping to 0.0.0.0/:: is requested, find a port that's free in
the range for each of the known IP addresses (but still only
mark it as allocated against 0.0.0.0/::). And, if a port is
requested for specific host addresses, make sure it's also
free in the corresponding 0.0.0.0/:: set (but only mark it as
allocated against the specific addresses - because the same
port can be allocated against a different specific address).
Signed-off-by: Rob Murray <rob.murray@docker.com>
Instead of passing the dirs for buildkit to configure the same cache
instance, just pass the shared CDI cache instance.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Avoid logging warnings when default CDI directory does not exist:
```
WARN[2025-05-26T14:27:54.008196418Z] CDI setup error /var/run/cdi: failed to monitor for changes: no such file or directory
WARN[2025-05-26T14:27:54.008209168Z] CDI setup error /etc/cdi: failed to monitor for changes: no such file or directory
```
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Because we set SO_REUSEADDR on sockets for host ports, if there
are port mappings for INADDR_ANY (the default) as well as for
specific host ports - bind() cannot be used to detect clashes.
That means, for example, on daemon startup, if the port allocator
returns the first port in its ephemeral range for a specific host
adddress, and the next port mapping is for 0.0.0.0 - the same port
is returned and both bind() calls succeed. Then, the container
fails to start later when listen() spots the problem and it's too
late to find another port.
So, bind and listen to each set of ports as they're allocated
instead of just binding.
Signed-off-by: Rob Murray <rob.murray@docker.com>
The legacy `docker.pkg.github.com` registry provided by GitHub was not
OCI compliant, and did not suport pull by digest (among others). Commit
495d623ae5 added fallback code to detect
"not found" errors when pulling by digest, in which case we would fall
back to pulling by `name:tag`.
GitHub deprecated the legacy registry, and it was [sunset on Feb 24th, 2025][1]
in favor of GitHub Container Registry (GHCR) (ghcr.io).
This reverts commit 495d623ae5, removing the
fallback logic.
[1]: https://github.blog/changelog/2025-01-23-legacy-docker-registry-closing-down/
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The netip types are really useful for tracking state in the overlay
driver as they are hashable, unlike net.IP and friends, making them
directly useable as map keys. Converting between netip and net types is
fairly trivial, but fewer conversions is more ergonomic.
The NetworkDB entries for the overlay peer table encode the IP addresses
as strings. We need to parse them to some representation before
processing them further. Parse directly into netip types and pass those
values around to cut down on the number of conversions needed.
The peerDB needs to marshal the keys and entries to structs of hashable
values to be able to insert them into the SetMatrix. Use netip.Addr in
peerEntry so that peerEntry values can be directly inserted into the
SetMatrix without conversions. Use a hashable struct type as the
SetMatrix key to avoid having to marshal the whole struct to a string
and parse it back out.
Use netip.Addr as the map key for the driver's encryption map so the
values do not need to be converted to and from strings. Change the
encryption configuration methods to take netip types so the peerDB code
can pass netip values directly.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Because nftables tables/chain aren't fixed, like they are
in iptables - this change makes an assumption about the
bridge driver's naming.
Signed-off-by: Rob Murray <rob.murray@docker.com>
The Namespace keeps some state for each inserted neighbor-table entry
which is used to delete the entry (and any related entries) given only
the IP and MAC address of the entry to delete. This state is not
strictly required as the retained data is a pure function of the
parameters passed to AddNeighbor(), and the kernel can inform us whether
an attempt to add a neighbor entry would conflict with an existing
entry. Get rid of the neighbor state in Namespace. It's just one more
piece of state that can cause lots of grief if it falls out of sync with
ground truth. Require callers to call DeleteNeighbor() with the same
aguments as they had passed to AddNeighbor(). Push the responsibility
for detecting attempts to insert conflicting entries into the neighbor
table onto the kernel by using (*netlink.Handle).NeighAdd() instead of
NeighSet().
Modernize the error messages and logging in DeleteNeighbor() and
AddNeighbor().
Signed-off-by: Cory Snider <csnider@mirantis.com>
func (*Namespace) AddNeighbor is only ever called with the force
parameter set to false. Remove the parameter and eliminate dead code.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Add checks in both containerd-based and distribution-based image pull
code paths to detect and AI model images early in the pull process.
These are not yet supported directly by the Engine and need to be
handled by the `docker model` CLI plugin.
For distribution-based pull, reject the AI models pulls.
For containerd image service only emit a warning.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
I'm horrible at vim, and use nano as my go-to editor for quick changes.
Let's install nano in the dev-container as alternative to vim for those
like me, who are not so vim-savvy ^O^C^C:wq:
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The (*Sandbox).joinLeaveStart() and .joinLeaveEnd() methods implement an
exclusive lock which is almost functionally identical to
(*sync.Mutex).Lock() and .Unlock(), respectively. The only notable
differences are that joinLeaveStart allocates, and calling
joinLeaveEnd() more times than joinLeaveStart() is a silent no-op
instead of a fatal error.
The construction of the joinLeaveStart/End methods is shaped like a
condition variable which uses channels for waiting and broadcasting.
The condition being waited for is that the joinLeaveDone struct field is
nil, i.e. that the lock has not been acquired by another goroutine.
As the condition is being checked and set while in a critical section,
it is a mutex implemented in terms of mutexes and channels. Replace the
home-grown mutex with a plain sync.Mutex.
Signed-off-by: Cory Snider <csnider@mirantis.com>
When deleting specific platforms from a multi-platform image, there's
potential risk as platform-specific content might be shared across
images/containers.
For now, require `force` parameter to make the user aware.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This change adds the ability to delete a specific platform from a
multi-platform image.
Previously, image deletion was an all-or-nothing operation - when
deleting a multi-platform image, all platforms would be removed
together. This change allows users to selectively remove individual
platforms from a multi-architecture image while keeping other platforms
intact.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
commit af0cdc36c7 marked these fields as
deprecated and to be removed in API v1.47 (which was targeted for v28.0).
We shipped v1.47 with the v27.2 release, but did not yet remove the erroneous
fields, so the version to deprecate was updated to v1.48 through
3df03d8e66
This patch removes fields that are not part of the image by replacing the
type with the Config struct from the docker image-spec.
curl -s --unix-socket /var/run/docker.sock http://localhost/v1.50/images/alpine/json | jq .Config
{
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"/bin/sh"
]
}
curl -s --unix-socket /var/run/docker.sock http://localhost/v1.49/images/alpine/json | jq .Config
{
"Hostname": "",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
],
"Cmd": [
"/bin/sh"
],
"Image": "",
"Volumes": null,
"WorkingDir": "",
"Entrypoint": null,
"OnBuild": null,
"Labels": null
}
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These were originally added in 7b9ecb9700.
The `StartLimitBurst` and `StartLimitInterval` options used to be
options for `[Service]`, but were moved to the `[Unit]` in systemd 229,
and systemd 230 respectively. The `StartLimitInterval` was renamed to
`StartLimitIntervalSec`, which either takes a number (using "seconds" as
default unit) or an optional unit;
- 6bf0f408e4
- f0367da7d1
We kept these deprecated options to provide compatibility with older distros
that not yet had systemd 230, but all distros we support are now on versions
of systemd that support the new options;
docker run --rm registry.access.redhat.com/ubi8/ubi systemctl --version
systemd 239 (239-82.el8_10.5)
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy
docker run -it --rm debian:
apt-get update && apt-get install -y systemd
...
systemctl --version
systemd 247 (247.3-7+deb11u6)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The "fluentd-async-connect" option was deprecated in 20.10 through
cc1f3c750e, and removed in 28.0 trough
49ec488036, which added migration code
on daemon startup.
However, the migration code _copied_ the deprecated option to the new
("fluentd-async") option, preserving the old field. Doing so could cause
an issue if a user would downgrade the daemon to a previous release, as
the changes in cc1f3c750e invalidate a config
that has both fields set (see [daemon/logger/fluentd/fluentd.go#L198-L200]);
if cfg[asyncKey] != "" && cfg[asyncConnectKey] != "" {
return config, errors.Errorf("conflicting options: cannot specify both '%s' and '%s", asyncKey, asyncConnectKey)
}
This patch updates the migration code to remove the deprecated option.
[daemon/logger/fluentd/fluentd.go#L198-L200]: cc1f3c750e/daemon/logger/fluentd/fluentd.go (L198-L200)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 7b153b9e28 changed the daemon to
advertise the recommended builder to use to V2 (BuildKit) for Linux
daemons, and V1 (Legacy Builder) for Windows daemons. For Linux daemons
we allowed the default to be overridden through the "features" field
in the daemon config (daemon.json), but for Windows we hard-coded it
to be V1, and no option to override.
With work in progress on implementing support for Windows in BuildKit,
we should remove this hardcoded assumption, and allow the default to
be overridden to advertise that BuildKit is supported.
Note that BuildKit on Windows is still very much a "work in progress",
and enabling it in the daemon may not even work, so users should not
try to enable this feature; a warning-level log is added to make it
visible that the feature is enabled.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
`opts.params.Platform` is always nil inside this branch so we can omit
it from the `GetImage` call to make it less confusing.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Previously, we were using our own `FromStatusCode` function to map HTTP
status codes to Docker error types. Switch to the containerd code.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
the core/remotes/docker/schema1 package is deprecated and removed
in containerd v2.1; remove its use as we already deprecated these
images for "docker pull" and elsewhere.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
WCOW support on Buildkit is now coming to maturity. As part
of making this generally available, integrating it in
Docker Engine is critical for it's adoption.
This commit adds the buildkit execuitor for WCOW as the
next-builder (backend) for building Windows containers.
This will be an opt-in feature, with the end users setting
DOCKER_BUILDKIT=1 environment variable to use it.
The integration tests bit has also been handled.
https://github.com/moby/buildkit/pull/5956,
BUILDKIT_REF has been set to `master` for now, so
that the tests can run successfully. On the next
release, we will revert this back to using releases.
Signed-off-by: Anthony Nandaa <profnandaa@gmail.com>
The `BridgeNfIptables` and `BridgeNfIp6tables` fields in the
`GET /info` response were deprecated in API v1.48, and are now omitted
in API v1.50.
With this patch, old API version continue to return the field:
curl -s --unix-socket /var/run/docker.sock http://localhost/v1.48/info | jq .BridgeNfIp6tables
false
curl -s --unix-socket /var/run/docker.sock http://localhost/v1.48/info | jq .BridgeNfIptables
false
Omitting the field in API v1.50 and above
curl -s --unix-socket /var/run/docker.sock http://localhost/v1.50/info | jq .BridgeNfIp6tables
null
curl -s --unix-socket /var/run/docker.sock http://localhost/v1.50/info | jq .BridgeNfIptables
null
This reverts commit eacbbdeec6, and re-applies
a variant of 5d2006256f
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Manifest v2 schema1 was deprecated in 4866f5139a1 and this commit
removes the push code for v2 schema1.
This reverts commit f695e98cb7,
adjusted for changes that were made since
daemon: do not mkdir trust directory
Remove push tests and move UUID tests to integration
Partial revert of f23a51a860.
Only the schema1 push tests are removed but the schema1 pull tests
are still desired.
The UUID test is moved from integration-cli to integration.
Signed-off-by: Tibor Vass <tibor@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add ability for the device driver to implement a device discovery
mechanism and expose discovered devices in the `docker info` output.
Currently it's only implemented for CDI devices.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Prevent the daemon spawned for integration tests from sourcing the
daemon configuration intended interactive dev shell usage.
Before this change, integration tests would fail to create a daemon
with different configuration provided via cli flags (like `--feature`)
if they're already specified in the default daemon.json.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Refactor the system CPU usage testing approach for improved maintainability:
1. Extract the core CPU usage parsing logic into a new `readSystemCPUUsage`
function that accepts an io.Reader, making it more testable and modular.
2. Use go:embed directive to embed the test data file at compile time,
eliminating runtime file operations and making tests more reliable.
3. Simplify the test by removing global variable mocking in favor of a more
direct approach with the new reader-based function.
4. Maintain full test coverage for the long "intr" line edge case which was
crucial for the original bug fix, while making the test more maintainable.
This change preserves the original test behavior while improving code quality,
testability, and making the tests self-contained.
Signed-off-by: Lee Gaines <leetgaines@gmail.com>
- rename the error-return to prevent accidental shadowing
- remove some intermediate variables
- usee a struct-literal for specs.Process
- optimize logging-code to not use chained "WithField"
- remove punctuation from error-message
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit ec65f2d21b has a typo: it switches
indexes[byTable] with indexes[byNetwork]. The indexes are not
equivalent. Switch it back.
Signed-off-by: Cory Snider <csnider@mirantis.com>
When a node leaves a network or the cluster, or memberlist considers the
node as failed, NetworkDB atomically deletes all table entries (for the
left network) owned by the node. This maintains the invariant that table
entries owned by a node are present in the local database indices iff
that node is an active cluster member which is participating in the
network the entries pertain to.
(*NetworkDB).handleTableEvent() is written in a way which attempts to
minimize the amount of time it is in a critical section with the mutex
locked for writing. It first checks under a read-lock whether both the
local node and the node where the event originated are participating in
the network which the event pertains to. If the check passes, the mutex
is unlocked for reading and locked for writing so the local database
state is mutated in a critical section. That leaves a window of time
between the participation check the write-lock being acquired for a
network or node event to arrive and be processed. If a table event for a
node+network races a node or network event which triggers the purge of
all table entries for the same node+network, the invariant could be
violated. The table entry described by the table event may be reinserted
into the local database state after being purged by the node's leaving,
resulting in an orphaned table entry which the local node will bulk-sync
to other nodes indefinitely.
It's not completely wrong to perform a pre-flight check outside of the
critical section. It allows for an early return in the no-op case
without having to bear the cost of synchronization. But such optimistic
concurrency control is only sound if the condition is double-checked
inside the critical section. It is tricky to get right, and this
instance of optimistic concurrency control smells like a case of
premature optimization. Move the pre-flight check into the critical
section to ensure that the invariant is maintained.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Use the errdefs resolver to ensure the status code is chosen from the
first outermost error. Remove duplicate containerd errdefs checks.
Signed-off-by: Derek McGowan <derek@mcg.dev>
The `Cause()` function is not part of the standard library and should
not be used or relied on. `pkg/errors` already has compatibility with
the standard library.
Signed-off-by: Derek McGowan <derek@mcg.dev>
The present content size is included in the image size usage and should
be included in the total size that the layer takes up on disk.
This prevents an issue where the reclaimable amount reported by the CLI
was a negative number.
This also updates the `/system/df` endpoint to use a new type that
computes information that was previously computed by the CLI. Computing
these in the server should require less work from the CLI and ensure
the calculations are more accurate because the CLI doesn't have to
reconstruct the numbers.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
daemon/network.go:156:3: S1000: should use for range instead of for { select {} } (staticcheck)
for {
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
container.HealthStatus is a pseudo-type (alias for string) that was
introduced in 1e4bb14bcd.
Changing this field to use that type as a potential stepping-stone
towards making that type a distinct type.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
ContainerState is currently an alias for string, so this should not
be a disruptive change, but is a stepping-stone to make it a distinct
type in future.
Relates to b811829595
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This test is failing frequently on Windows;
=== FAIL: github.com/docker/docker/integration/networking TestPortMappedHairpinWindows (12.37s)
nat_windows_test.go:108: assertion failed: error is not nil: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.49/containers/1181d6510a2f55c742b7b183aa7324eddbc213cd15797428c4062dcb031fb825/start": context deadline exceeded
panic.go:636: assertion failed: error is not nil: Error response from daemon: error while removing network: network clientnet has active endpoints (name:"laughing_lederberg" id:"8605ebbc2c7c")
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(*NetworkDB).SetPrimaryKey() acquires a read lock on the NetworkDB
instance. That seems sound on the surface as it is only reading from the
NetworkDB struct, not mutating it. However, concurrent calls to
(*memberlist.Keyring).UseKey() would get flagged by Go's race detector
due to some questionable locking in its implementation. Acquire an
exclusive lock in SetPrimaryKey so concurrent calls don't race each
other.
Signed-off-by: Cory Snider <csnider@mirantis.com>
The bridge driver should figure out whether it's running in
a mirrored WSL2 setup, and tell the firewaller.
So, move the WSL2-deciding code back into the bridge driver
and unit test it there. Use TestIptabler to check the rules
are constructed properly.
Signed-off-by: Rob Murray <rob.murray@docker.com>
integration/internal/network/ops.go:137:1: ST1020: comment on exported function WithIPAMRange should be of the form "WithIPAMRange ..." (staticcheck)
// WithIPAM adds an IPAM with the specified Subnet, IPRange and Gateway to the network
^
libnetwork/bitmap/sequence.go:50:1: ST1020: comment on exported function New should be of the form "New ..." (staticcheck)
// NewHandle returns a new Bitmap of ordinals in the interval [0, n).
^
libnetwork/diagnostic/server.go:61:1: ST1020: comment on exported method HandleFunc should be of the form "HandleFunc ..." (staticcheck)
// Handle registers the handler function for the given pattern,
^
libnetwork/endpoint.go:388:1: ST1020: comment on exported method Key should be of the form "Key ..." (staticcheck)
// endpoint Key structure : endpoint/network-id/endpoint-id
^
libnetwork/network.go:574:1: ST1020: comment on exported method MarshalJSON should be of the form "MarshalJSON ..." (staticcheck)
// TODO : Can be made much more generic with the help of reflection (but has some golang limitations)
^
libnetwork/network.go:633:1: ST1020: comment on exported method UnmarshalJSON should be of the form "UnmarshalJSON ..." (staticcheck)
// TODO : Can be made much more generic with the help of reflection (but has some golang limitations)
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
NetworkDB's Watch() facility is problematic to use in practice. The
stream of events begins when the watch is started, so the watch cannot
be used to process table entries that existed beforehand. Either option
to process existing table entries is racy: walking the table before
starting the watch leaves a race window where events could be missed,
and walking the table after starting the watch leaves a race window
where created/updated entries could be processed twice.
Modify Watch() to initialize the channel with synthetic CREATE events
for all existing entries owned by remote nodes before hooking it up to
the live event stream. This way watchers observe an equivalent sequence
of events irrespective of whether the watch was started before or after
entries from remote nodes are added to the database. Remove the bespoke
and racy synthetic event replay logic for driver watches from the
libnetwork agent.
Signed-off-by: Cory Snider <csnider@mirantis.com>
The gossip protocol which powers NetworkDB does not guarantee in-order
reception of events. This poses a problem with deleting entries: without
some mechanism to discard stale CREATE or UPDATE events received after a
DELETE, out-of-order reception of events could result in a deleted entry
being spuriously resurrected in the local NetworkDB state! NetworkDB
handles this situation by storing "tombstone" entries for a period of
time with the Lamport timestamps of the entries' respective DELETE
events. Out-of-order CREATE or UPDATE events will be ignored by virtue
of having older timestmaps than the tombstone entry, just like how it
works for entries that have not yet been deleted.
NetworkDB was only storing a tombstone if the entry was already present
in the local database at the time of the DELETE event. If the first
event received for an entry is a DELETE, no tombstone is stored. If a
stale CREATE/UPDATE event for the entry (with an older timestamp than
the DELETE) is subsequently received, NetworkDB erroneously creates a
live entry in the local state with stale data. Modify NetworkDB to store
tombstones for DELETE events irrespective of whether the entry was known
to NetworkDB beforehand so that it correctly discards out-of-order
CREATEs and UPDATEs in all cases.
Signed-off-by: Cory Snider <csnider@mirantis.com>
NetworkDB gossips changes to table entries to other nodes using distinct
CREATE, UPDATE and DELETE events. It is unfortunate that the wire
protocol distinguishes CREATEs from UPDATEs as nothing useful can be
done with this information. Newer events for an entry invalidate older
ones, so there is no guarantee that a CREATE event is broadcast to any
node before an UPDATE is broadcast. And due to the nature of gossip
protocols, even if the CREATE event is broadcast from the originating
node, there is no guarantee that any particular node will receive the
CREATE before an UPDATE. Any code which handles an UPDATE event
differently from a CREATE event is therefore going to behave in
unexpected ways in less than perfect conditions.
NetworkDB table watchers also receive CREATE, UPDATE and DELETE events.
Since the watched tables are local to the node, the events could all
have well-defined meanings that are actually useful. Unfortunately
NetworkDB is just bubbling up the wire-protocol event types to the
watchers. Redefine the table-watch events such that a CREATE event is
broadcast when an entry pops into existence in the local NetworkDB, an
UPDATE event is broadcast when an entry which was already present in the
NetworkDB state is modified, and a DELETE event is broadcast when an
entry which was already present in the NetworkDB state is marked for
deletion. DELETE events are broadcast with the same value as the most
recent CREATE or UPDATE event for the entry.
The handler for endpoint table events in the libnetwork agent assumed
incorrectly that CREATE events always correspond to adding a new active
endpoint and that UPDATE events always correspond to disabling an
endpoint. Fix up the handler to handle CREATE and UPDATE events using
the same code path, checking the table entry's ServiceDisabled flag to
determine which action to take.
Signed-off-by: Cory Snider <csnider@mirantis.com>
State.RemovalInProgress was originally non-exported when it was added in
[40945fc186][1], adding a comment that the
field should not be persisted to disk.
But when moved to a separate package in [6bb0d1816a][2],
it was was exported, without adding `json:"-"`. As a result, it's now persisted
to disk;
cat /var/lib/docker/containers/e493924a99cad918cda8048f967032729105ee072d563d734125cec46e1b5885/config.v2.json | jq .State
{
"Running": true,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"RemovalInProgress": false,
"Dead": false,
"Pid": 5053,
"ExitCode": 0,
"Error": "",
"StartedAt": "2025-05-13T12:12:15.115512564Z",
"FinishedAt": "0001-01-01T00:00:00Z",
"Health": null
}
Note that this type is used internally, and (while similar) is not used for
API responses;
docker inspect e493924a99cad918cda8048f967032729105ee072d563d734125cec46e1b5885 | jq .[].State
{
"Status": "running",
"Running": true,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 5053,
"ExitCode": 0,
"Error": "",
"StartedAt": "2025-05-13T12:12:15.115512564Z",
"FinishedAt": "0001-01-01T00:00:00Z"
}
However, interestingly, [`daemon.restore`][3] does take this field into account
while restoring containers, which seems that it depends on the field being
persisted to disk. That logic was added in [ce72473197][4].
That logic may be redundant if we no longer persist to disk, as the `State.Dead`
is already set when cleaning up a container in [`daemon.cleanupContainer`][5].
[1]: 40945fc186
[2]: 6bb0d1816a (diff-60173e67d15f3085dd09956b3ffa83566ae25fec61cfe08ddd2e1c37223e3be7R24)
[3]: d42d79dceb/daemon/daemon.go (L498-L514)
[4]: ce72473197
[5]: 294f0c36e4/daemon/delete.go (L124-L126)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The swarmPlugin type does not implement the Swarm plugin.AddrPlugin
interface because it embeds an interface value which does not include
that method in its method set. (You can type-assert an interface value
to another interface which the concrete type implements, but a struct
embedding an interface value is not itself an interface value.) Wrap the
plugin with a different adapter type which exposes the Addr() method if
the concrete plugin implements it.
Signed-off-by: Cory Snider <csnider@mirantis.com>
Makes the code slightly more idiomatic. These paths avoided uses of
defer because they came with an overhead in older versions of Go,
but this overhead should now be neglectible.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Currently, it's needed to set `BIND_DIR=.` when starting the dev-container
in order to bind-mount the current source-code into the container. Omitting
that option only bind-mounts the "bundles" directory and copies the source
into the image before starting.
While there are some cases where (e.g.) a remote server is used for development,
and bind-mounting is not possible, those scenarios should be considered more
advanced, so let's make the common scenario easier to use.
With this patch, running `make shell` should build and run the dev-container
with the source-code mounted.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was decorating errors with the container name, but within its
own context wouldn't be aware how the delete was referenced. This could
result in a container deleted by "ID" to produce an error with the container
Name. Some errors were also decorated before storing as "removalError" on
the container object itself.
The removalError was originally added in f963500c54,
before which the error was returned. Now that it's part of the container's
state itself, adding the container's ID is probably not very useful.
This patch reduces the scope of decorating the errors to the error-condition
itself, leaving it to the caller to decorate them further with the container
ID or Name (if any).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This code only needed to know whether the container was paused; for other
states ("restarting", "running"), it's still used to be included in the
error string.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Currently, there's no mechanism to specify a write timeout value for
fluentd connections. This means that writes can forever be blocked if
the downstream connections is unhealthy. This commit makes this value
configurable via a new fluentd log option called "fluentd-write-timeout".
Signed-off-by: Anirudh Aithal <aithal@amazon.com>
Logic was added to the Swarm executor in commit 0d9b0ed678
to clean up managed networks whenever the node's load-balancer IP
address is removed or changed in order to free up the address in the
case where the container fails to start entirely. Unfortunately, due to
an oversight the function returns early if the Swarm is lacking
an ingress network. Remove the early return so that load-balancer IP
addresses for all the other networks are freed as appropriate,
irrespective of whether an ingress network exists in the Swarm.
Signed-off-by: Cory Snider <csnider@mirantis.com>
If kernel module br_netfilter isn't loaded on the test host
before rootless test-integration tests that need it, the
rootless daemon hits a permission error when trying to do
the load. So, try to load the module before going rootless.
Signed-off-by: Rob Murray <rob.murray@docker.com>
The container.WaitCondition type was deprecated in
100102108b, but this use of the
deprecated alias was left behind.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Part of https://github.com/docker/docker-ce-packaging/issues/1186
Adds the required systemd-sysusers configuration to the
moby/moby repo. This will be used by downstream package
maintainers (RPM, DEB etc) as a replacement to the
`groupadd` postinstall commands.
It's generally recommended to use sysusers since it is
more of a declarative method of defining these service
accounts and groups.
This configuration file specifies a group ("g") named
"docker" should be created with an automatic GID
allocation ("-").
Signed-off-by: Robert Sturla <robertsturla@outlook.com>
Introduce a ValidateHealthStatus utility in api/types/container to
validate if a given HealthState is valid.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Rename the ouput variable to prevent accidental shadowing, and simplify how
we check for the `syscall.ENOTDIR` error; `errors.Is()` will already unwrap
the error, so no type-casting is needed;
package main
import (
"errors"
"fmt"
"os"
"syscall"
)
func main() {
err := &os.PathError{Op: "mkdir", Path: "/hello/world", Err: syscall.ENOTDIR}
if errors.Is(err, syscall.ENOTDIR) {
fmt.Println(err)
}
}
While at it, also improve the code-comment that outlines the intent.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Prevent accidentally shadowing these errors, which are used in defers, and
while at it, also fixed some linting warnings about unhandled errors.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The function used a `cmdErr` error, but it was discarded when returning an
error. Also removing the named "err" return variable.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- remove named err-returns to prevent accidental shadowing
- fix some minor linting issues (unhandled errors)
- update code depending on "errors.Wrap" behavior. which ignores
nil-errors, which can be easily overlooked when rewriting to
native go error-wrapping (fmt.Errorf()).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This test normally fails due to a known issue, but it
has recently started passing in CI ... not sure why, it
still fails locally - so, allow it to unexpeectedly
pass, but collect some debug info to try to undertand
why.
Signed-off-by: Rob Murray <rob.murray@docker.com>
Skip tests that have recently started failing in rootless
mode with error:
failed to start daemon: Error initializing network controller:
error creating default "bridge" network:
cannot restrict inter-container communication or run
without the userland proxy:
stat /proc/sys/net/bridge/bridge-nf-call-iptables:
no such file or directory:
set environment variable DOCKER_IGNORE_BR_NETFILTER_ERROR=1 to ignore
(Perhaps we can ensure the module is loaded before starting
the rootless env - or work out why the failures have only
recently started, and put-back whatever changed. But, for
now, I think we need to skip.)
Signed-off-by: Rob Murray <rob.murray@docker.com>
NetworkDB uses a hierarchy of queues to prioritize messages for
broadcast. Unfortunately the logic to pull from multiple queues is
flawed. The length of the messages pulled from the first queue is not
taken into account when pulling messages from the second queue. A list
of messages up to tiwce as long as the limit could be returned! Messages
beyond the limit will be truncated unceremoniously by memberlist.
Memberlist broadcast queues assume that all messages returned from a
GetBroadcasts call will be broadcasted to other nodes in the cluster.
Messages are popped from the queue once they have hit their retransmit
limit. On a busy system messages may be broadcast fewer times than
intended, possibly even being dropped without ever being broadcast!
Subtract the length of messages pulled from the first queue from the
broadcast size limit so the limit is not exceeded when pulling from the
second queue.
Signed-off-by: Cory Snider <csnider@mirantis.com>
The loopback-test fixes seem to be sufficient to resolve the flakiness
of all the tests aside from TestFlakyNetworkDBIslands.
Signed-off-by: Cory Snider <csnider@mirantis.com>
NetworkDB defaults to binding to the unspecified address for gossip
communications, with no advertise address set. In this configuration,
the memberlist instance listens on all network interfaces and picks one
of the host's public IP addresses as the advertise address.
The NetworkDB unit tests don't override this default, leaving them
vulnerable to flaking out as a result of rogue network traffic
perturbing the test, or the inferred advertise address not being useable
for loopback testing. And macOS prompts for permission to allow the test
executable to listen on public interfaces every time it is rebuilt.
Modify the NetworkDB tests to explicitly bind to, advertise, and join
ports on 127.0.0.1 to make the tests more robust to flakes in CI and
more convenient to run locally.
Signed-off-by: Cory Snider <csnider@mirantis.com>
The NetworkDB unit tests instantiate clusters which communicate over
loopback where every "node" listens on a distinct localhost port. The
tests make use of a NetworkDB configuration knob to set the port. When
the NetworkDB configuration's BindPort field is set to a nonzero value,
its memberlist instance is configured to bind to the specified port
number. However, the advertise port is left at the
memberlist.DefaultLANConfig() default value of 7946. Because of this,
nodes would be unable to contact any of the other nodes in the cluster
learned by gossip as the gossiped addresseses specify the wrong ports!
The flaky tests passed as often as they did thanks to the robustness of
the memberlist module: NetworkDB gossip and and memberlist node
liveness-probe pings to unreachable nodes can all be relayed through
the reachable nodes, the nodes on the bootstrap join list.
Make the NetworkDB unit tests less flaky by setting each node's
advertise port to the bind port.
The daemon is unaffected by this oversight as it unconditionally uses
the default listen port of 7946, which aligns with the advertise port.
Signed-off-by: Cory Snider <csnider@mirantis.com>
The function was accessing the index map without holding the mutex, so
it would race any mutation to the database indexes. Fetch the reference
to the tree's root while holding a read lock. Since the radix tree is
immutable, taking a reference to the root is equivalent to starting a
read-only database transaction, providing a consistent view of the data
at a snapshot in time, even as the live state is mutated concurrently.
Also optimize the WalkTable function by leveraging the immutability of
the radix tree.
Signed-off-by: Cory Snider <csnider@mirantis.com>
The image api already defines the backend used and does
not directly use the reference store backend. It also should not
directly use the reference store backend.
Signed-off-by: Derek McGowan <derek@mcg.dev>
Per-network option com.docker.network.bridge.trusted-host-interfaces
accepts a list of interfaces that are allowed to route
directly to a container's published ports in a bridge
network with nat enabled.
This daemon level option disables direct access filtering,
enabling direct access to published ports on container
addresses in all bridge networks, via all host interfaces.
It overlaps with short-term env-var workaround:
DOCKER_INSECURE_NO_IPTABLES_RAW=1
- it does not allow packets sent from outside the host to reach
ports published only to 127.0.0.1
- it will outlive iptables (the workaround was initially intended
for hosts that do not have kernel support for the "raw" iptables
table).
Signed-off-by: Rob Murray <rob.murray@docker.com>
trusted_host_interface have access to published ports on container
addresses - enabling direct routing to the container via those
interfaces.
Signed-off-by: Rob Murray <rob.murray@docker.com>
On Sandbox restore if an Endpoint (or Network) can't be loaded from
the store and the container is to be preserved (live-restore), stub
Network and Endpoint objects are created and added to the cache. But
then the Endpoint is just dropped - leaving the stub objects in
cache.
If not-live-restore, the Sandbox is reconstructed do that it can be
deleted by sb.delete(force=true). But, the only thing sb.delete does
with the Endpoint in this case is call ep.Delete. And, ep.Delete
doesn't do anything if the Network and Endpoint can't both be loaded
from the store. So, again, the stub objects are left in the in-memory
cache and nothing that might have needed tidying up got tidied up.
So, whether live-restoring or not, just log an error and ignore an
Endpoint if it can't be loaded from disk.
Signed-off-by: Rob Murray <rob.murray@docker.com>
- Use structured logging.
- Which means ids are logged consistently.
- Use variable 'isRestore' instead of extra map lookups.
Signed-off-by: Rob Murray <rob.murray@docker.com>
This will use the default settings for buildkit gc unless explicitly
disabled by setting `enabled: false` in the gc configuration.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
- remove named error-returns
- make error-handling slightly more idiomatic (check for non-nil errors)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
builder/builder-next/adapters/containerimage/pull.go:912:3: shadow: declaration of "now" shadows declaration at line 905 (govet)
now := time.Now()
^
builder/builder-next/adapters/snapshot/layer.go:52:4: shadow: declaration of "diffIDs" shadows declaration at line 28 (govet)
diffIDs, err := s.EnsureLayer(gctx, info.Parent)
^
builder/builder-next/worker/worker.go:577:3: shadow: declaration of "now" shadows declaration at line 570 (govet)
now := time.Now()
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
pkg/plugins/plugins.go:325:4: shadow: declaration of "pl" shadows declaration at line 315 (govet)
pl, err := loadWithRetry(name, false)
^
pkg/plugins/pluginrpc-gen/parser.go:153:4: shadow: declaration of "iface" shadows declaration at line 135 (govet)
iface, ok := spec.Type.(*ast.InterfaceType)
^
pkg/plugins/pluginrpc-gen/parser_test.go:61:2: shadow: declaration of "arg" shadows declaration at line 40 (govet)
arg := f.Args[0]
^
pkg/plugins/pluginrpc-gen/parser_test.go:165:2: shadow: declaration of "arg" shadows declaration at line 40 (govet)
arg := f.Args[0]
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
daemon/logger/loggertest/logreader.go:548:14: shadow: declaration of "open" shadows declaration at line 545 (govet)
case err, open := <-lw.Err:
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
api/server/router/network/network_routes.go:148:14: shadow: declaration of "nwv" shadows declaration at line 146 (govet)
} else if nwv, ok := listByFullName[nwk.ID]; ok {
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
libnetwork/network.go:637:6: shadow: declaration of "v" shadows declaration at line 634 (govet)
if v, ok := n.generic[netlabel.GenericData]; ok {
^
libnetwork/service_linux.go:125:7: shadow: declaration of "ep" shadows declaration at line 86 (govet)
if ep := sb.getGatewayEndpoint(); ep != nil {
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
libnetwork/portallocator/portallocator_test.go:151:7: shadow: declaration of "i" shadows declaration at line 150 (govet)
for i := 0; i <= p.end-p.begin; i++ {
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
also moved the variables closer to where they're used
libnetwork/networkdb/cluster.go:414:4: shadow: declaration of "nid" shadows declaration at line 397 (govet)
nid := params[0]
^
libnetwork/networkdb/networkdb.go:514:4: shadow: declaration of "nid" shadows declaration at line 506 (govet)
nid := params[0]
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Prevent accidentally shadowing these errors, which are used in defers, and
while at it, also fixed some linting warnings about unhandled errors, and
defers created in a loop.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Prevent accidentally shadowing the error, which is used in a defer, and
while at it, also fixed some linting warnings about unhandled errors.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Prevent accidentally shadowing these errors, which are used in defers, and
while at it, also fixed some linting warnings about unhandled errors.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Prevent accidentally shadowing these errors, which are used in defers, and
while at it, also fixed some linting warnings about unhandled errors.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Update referencesin hack/README.md from outdated docker URLs to the correct location at /docs/contributing/test.md.
Signed-off-by: ChengyuZhu6 <hudson@cyzhu.com>
Alias and deprecate the status types and constants from the root
container package. The root container package is intended for use
within the daemon and no the api package.
Signed-off-by: Derek McGowan <derek@mcg.dev>
Prevent accidentally shadowing these errors, which are used in defers, and
while at it, also fixed some linting warnings about unhandled errors.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
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>
Prevent accidentally shadowing the error, which is used in a defers, and
while at it, also fixed some linting warnings about unhandled errors and
shadowed vars.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The build exporter now clears the image tags and always exported to a
dangling image. It then uses the image tagger to perform the tagging
which causes the dangling image to be removed and the naming message to
be sent correctly.
An additional progress message is sent to indicate the renaming.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Before this patch, and error would be produced when starting the exec,
but the CLI would wait for the exec to complete, timing out after 10
seconds (default). With this change, an error is returned immediately
when creating the exec.
Note that "technically" this check may have some TOCTOU issues, because
'/etc/passwd' and '/etc/groups' may be mutated by the container in between
creating the exec and starting it.
This is very likely a corner-case, but something we can consider changing
in future (either allow creating an invalid exec, and checking before
starting, or checking both before create and before start).
With this patch:
printf 'FROM alpine\nRUN rm -f /etc/group' | docker build -t nogroup -
ID=$(docker run -dit nogroup)
time docker exec -u 0:root $ID echo hello
Error response from daemon: unable to find group root: no matching entries in group file
real 0m0.014s
user 0m0.010s
sys 0m0.003s
# numericc uid/gid (should not require lookup);
time docker exec -u 0:0 $ID echo hello
hello
real 0m0.059s
user 0m0.007s
sys 0m0.008s
# no user specified (should not require lookup);
time docker exec $ID echo hello
hello
real 0m0.057s
user 0m0.013s
sys 0m0.008s
docker rm -fv $ID
# container that does have a valid /etc/groups
ID=$(docker run -dit alpine)
time docker exec -u 0:root $ID echo hello
hello
real 0m0.063s
user 0m0.010s
sys 0m0.009s
# non-existing user or group
time docker exec -u 0:blabla $ID echo hello
Error response from daemon: unable to find group blabla: no matching entries in group file
real 0m0.013s
user 0m0.004s
sys 0m0.009s
docker rm -fv $ID
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When a network is created with "-o com.docker.network.enable_ipv4'
(including via "default-network-opts" in daemon config), and
EnableIPv4 is present in the API request (including when CLI option
"--ipv4" is used) - the top-level API value is used and the '-o'
is ignored.
But, the "-o" still shows up in Options in inspect output, which is
confusing if the values are different.
So, drop the "-o" if the top-level API option is set. Ditto IPv6.
Signed-off-by: Rob Murray <rob.murray@docker.com>
`moby/vpnkit` now officially pushes a binary image to `moby/vpnkit-bin`
repository on Docker Hub.
Use it to fetch the vpnkit binary.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Commit 27adcd5 ("libnet/d/bridge: drop connections to lo mappings, and
direct remote connections") introduced an iptables rule to drop 'direct'
remote connections made to the container's IP address - for each
published port on the container.
The normal filter-FORWARD rules would then drop packets sent directly to
unpublished ports. This rule was only created along with the rest of port
publishing (when a container's endpoint was selected as its gateway). Until
then, all packets addressed directly to the container's ports were dropped
by the filter-FORWARD rules.
But, the rule doesn't need to be per-port. Just drop packets sent
directly to a container's address unless they originate on the host.
That means fewer rules, that can be created along with the endpoint (then
directly-routed get dropped at the same point whether or not the endpoint
is currently the gateway - very slightly earlier than when it's not the
gateway).
Signed-off-by: Rob Murray <rob.murray@docker.com>
gotest.tools v3.0.1 and up support Go's native test.Cleanup(), which
means that manually calling the cleanup functions in a defer is no
longer needed.
Some of these could probably be replaced by Go's native `t.TempDir()`,
but keeping that for a follow-up exercise.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was added in 684633f734, because
Go stdlib's filepath.Rel did not support Windows UUID paths (and UNC paths).
UNC paths were fixed in https://golang.org/cl/253197 (go1.17), and I think
UUID paths were also supported now.
To verify the behavior I temporarily added a unit-test to compare between
stdlib and this implementation, and it all looks to work, so we can deprecate
and remove this function. Deprecating first, but there's no (known) external
users of this, so we can likely remove in an upcoming minor (or patch) release.
func TestRel(t *testing.T) {
testCases := []struct {
doc string
base string
target string
expected string
}{
{
doc: "UNC path",
base: `\\server\share`,
target: `\\server\share\folder\file.txt`,
expected: `folder\file.txt`,
},
{
doc: "UUID path",
base: `\\?\Volume{b75e2c83-0000-0000-0000-602f00000000}\data`,
target: `\\?\Volume{b75e2c83-0000-0000-0000-602f00000000}\data\file.txt`,
expected: `file.txt`,
},
{
doc: "subdirectory",
base: `C:\Projects`,
target: `C:\Projects\Go\main.go`,
expected: `Go\main.go`,
},
{
doc: "same directory",
base: `C:\Projects`,
target: `C:\Projects`,
expected: `.`,
},
{
doc: "parent directory",
base: `C:\Projects\Go`,
target: `C:\Projects`,
expected: `..`,
},
}
for _, tc := range testCases {
t.Run(tc.doc, func(t *testing.T) {
actual, err := remotecontext.Rel(tc.base, tc.target)
if err != nil {
t.Fatal(err)
}
if actual != tc.expected {
t.Errorf("expected: %q, got: %q", tc.expected, actual)
}
// Try with stdlib
actual, err = filepath.Rel(tc.base, tc.target)
if err != nil {
t.Fatal(err)
}
if actual != tc.expected {
t.Errorf("expected: %q, got: %q", tc.expected, actual)
}
})
}
}
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The syntax was pinned for 1.7 in f696e0d2a7
possibly because it was not yet promoted as "latest stable" at the
time.
I don't think we need to pin to an old version, and just go with
the latest, so that we can use the latest features provided.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
CI runs a docker daemon, and some tests run their own. That tramples
the CI daemon's default bridge.
If a test leaves the bridge with only a link-local IPv6 address (for
example), subsequent tests are likely to fail - even if they also
start their own daemon because, by default the default bridge
network's config is based on an existing bridge device.
So, remember the bridge's addresses at the start of each test, and
restore them afterwards.
Signed-off-by: Rob Murray <rob.murray@docker.com>
- G204 # G204:Subprocess launched with variable; too many false positives.
- G301 # G301:Expect directory permissions to be 0750 or less (also EXC0009); too restrictive
- G302 # G302:Expect file permissions to be 0600 or less (also EXC0009); too restrictive
- G304 # G304:Potential file inclusion via variable.
- 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")
- G504 # G504: Blocklisted import net/http/cgi: Go versions < 1.6.3 are vulnerable to Httpoxy attack:(CVE-2016-5386); (only affects go < 1.6.3)
govet:
enable-all:true
disable:
- fieldalignment # TODO:evaluate which ones should be updated.
importas:
# Do not allow unaliased imports of aliased packages.
no-unaliased:true
alias:
# Enforce alias to prevent it accidentally being used instead of our
- G204 # G204:Subprocess launched with variable; too many false positives.
- G301 # G301:Expect directory permissions to be 0750 or less (also EXC0009); too restrictive
- G302 # G302:Expect file permissions to be 0600 or less (also EXC0009); too restrictive
- G304 # G304:Potential file inclusion via variable.
- 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")
- G504 # G504: Blocklisted import net/http/cgi: Go versions < 1.6.3 are vulnerable to Httpoxy attack:(CVE-2016-5386); (only affects go < 1.6.3)
govet:
enable-all:true
disable:
- fieldalignment # TODO:evaluate which ones should be updated.
importas:
# Do not allow unaliased imports of aliased packages.
no-unaliased:true
alias:
# Enforce alias to prevent it accidentally being used instead of our
# This allows the test suite to be able to run without worrying about the underlying fs used by the container running the daemon (e.g. aufs-on-aufs), so long as the host running the container is running a supported fs.
// TODO(thaJeztah); we only use this to produce a nice error, but as a result, we can't remove libtrust as dependency - see if we can reduce the dependencies, but still able to detect it's a deprecated manifest
// CacheDiskUsage contains disk usage for the build cache.
//
// Deprecated: this type is no longer used and will be removed in the next release.
typeCacheDiskUsagestruct{
TotalSizeint64
Reclaimableint64
Items[]*CacheRecord
}
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.
