This code was added in 85b260fba8, but didn't
account for maps.Clone returning a `nil` map if the map cloned was `nil`.
This could lead to a panic, similar to the panic that was fixed in
7517464283d29969c4d3615397b369abd99ce395;
panic: assignment to entry in nil map
goroutine 498 [running]:
github.com/moby/moby/v2/daemon.buildPortsRelatedCreateEndpointOptions(0x400042f348, 0xaaaabcc8f458?, 0x40006feb40)
/root/build-deb/engine/daemon/network.go:1047 +0x844
github.com/moby/moby/v2/daemon.buildCreateEndpointOptions(0x400042f348, 0x4001015040, 0x400027d320, 0x40006feb40, {0x0, 0x0, 0x4001506cb8?})
/root/build-deb/engine/daemon/network.go:988 +0x20c
github.com/moby/moby/v2/daemon.(*Daemon).connectToNetwork(0x4000898008, {0xaaaabe21d9f8, 0x4000f12b10}, 0x400089a008, 0x400042f348, {0x400077a9f0, 0x6}, 0x400027d320)
/root/build-deb/engine/daemon/container_operations.go:738 +0x66c
github.com/moby/moby/v2/daemon.(*Daemon).allocateNetwork(0x4000898008, {0xaaaabe21d9f8, 0x4000f12b10}, 0x400089a008, 0x400042f348)
/root/build-deb/engine/daemon/container_operations.go:421 +0x298
github.com/moby/moby/v2/daemon.(*Daemon).initializeCreatedTask(0x4000898008, {0xaaaabe21d9f8, 0x4000f12b10}, 0x400089a008, {0xaaaabe23dc60, 0x4000eb21c8}, 0x400042f348, 0xaaaabd4db3df?)
/root/build-deb/engine/daemon/start_linux.go:37 +0x260
github.com/moby/moby/v2/daemon.(*Daemon).containerStart(0x4000898008, {0xaaaabe21d9c0, 0xaaaabfa05300}, 0x400089a008, 0x400042f348, {0x0, 0x0}, {0x0, 0x0}, 0x1)
/root/build-deb/engine/daemon/start.go:242 +0xba8
github.com/moby/moby/v2/daemon.(*Daemon).restore.func4(0x400042f348, 0x400117f1f0)
/root/build-deb/engine/daemon/daemon.go:633 +0x308
created by github.com/moby/moby/v2/daemon.(*Daemon).restore in goroutine 1
/root/build-deb/engine/daemon/daemon.go:607 +0x5ec
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 6aea8c2591 updated this part of the
test to account for BuildKit now being used as default, which doesn't use
regular containers to "commit" to an image, and therefore doesn't produce
events as part of the build.
However, it changed it to filter for `build` type events, which .. don't
exist. The test passed because it only checked for number of events produced,
which is approximated by checking the number of lines in the output. In
this case, the output would be empty, so "events" was a slice of strings
with length 1; an empty string.
Given that BuildKit doesn't produce meaningful events to test for, we could
either disable BuildKit, to test the legacy builder, or just remove this
part of the test. Let's do the latter.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These tests used intermediate images (as produced by the classic builder)
as part of the test. When using BuildKit, such images are not produced,
and will only be in the build-cache.
From the tests, it looks like the extra checks were not critical to
verify the behavior, so let's simplify them to not depend on this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Make sure the error is the one we expected, and slightly clarify
the behavior (named volumes not having a meaning in VOLUME, so will
be used as-is).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
In a multi-module repository, the top-level LICENSE file is used for
all modules in the repository. However, when using a "replace" rule,
the vendored file is removed, but added back when removing the replace
rule.
This patch adds copies of the license to each of the modules to reduce
code-churn; these are vanilla copies downloaded from;
https://www.apache.org/licenses/LICENSE-2.0.txt
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The directory was solely used by Dockerfile.simple.
For the "simple" mode, we can just directly apt-get the dependencies.
A part of issue 51637
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
These releases include 2 security fixes following the security policy:
- crypto/x509: excessive resource consumption in printing error string for host certificate validation
Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out.
Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime.
Therefore, a certificate provided by a malicious actor can result in excessive resource consumption.
HostnameError.Error() now limits the number of hosts and utilizes strings.Builder when constructing an error string.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2025-61729 and Go issue https://go.dev/issue/76445.
- crypto/x509: excluded subdomain constraint does not restrict wildcard SANs
An excluded subdomain constraint in a certificate chain does not restrict the
usage of wildcard SANs in the leaf certificate. For example a constraint that
excludes the subdomain test.example.com does not prevent a leaf certificate from
claiming the SAN *.example.com.
This is CVE-2025-61727 and Go issue https://go.dev/issue/76442.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.25.5
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Includes a change to use go.dev/dl instead of storage.googleapis.com/golang
as fallback URL, because storage.googleapis.com/golang is deprecated.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
