[pull] master from moby:master#1404
Open
pull[bot] wants to merge 10000 commits intonext-stack:masterfrom
Open
Conversation
daemon/pkg/registry: use lazyregexp again
- use anchored regexes for exclusion paths; paths are by default evaluated relative to the config-file, which is at the root of the repository (alternatively it can be configured to be relative to the git-root, but we may not have that around everywhere) - combine some exclusions to a single regex Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
golangci-lint: make exclusions more specific, and combine some
Signed-off-by: Mend Renovate <bot@renovateapp.com>
…s-go-systemd-v22-22.x fix(deps): update module github.com/coreos/go-systemd/v22 to v22.7.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go.mod: add back replace rules
Also add a OTEL_COLLECTOR_VERSION env-var for easier grep'ing and updating. release notes: https://github.com/open-telemetry/opentelemetry-collector-contrib/releases/tag/v0.144.0 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Leave it to the consumer to decide whether these should be called in a goroutine. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These were called in a goroutine, likely to prevent them from affecting performance, but doing so also means that there's no promise that the notifications were actually sent before we continue. Summarising the discussion from [PR 47358]: These calls should not be particularly heavy-weight; They open a UNIX datagram socket, write and close. (see the [go-systemd] implementation), and it's unlikely these calls would block for a significant length of time unless pid 1 has become unresponsive, in which case you'd have much bigger problems. These should be lightweight and fast as we can't imagine many C programs would be going through the trouble of invoking `sd_notify()` in a background thread. Note that the syslog API is also very similar: apps log by sending unixgrams to the `/dev/log` socket. [go-systemd]: https://github.com/coreos/go-systemd/blob/d5623bf85e8e73ae6352f78ee6b55a287619dd4e/daemon/sdnotify.go#L48-L84 [PR 47358]: #47358 (comment) Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit f74b856 added an [ExecReload] to the systemd unit, which allows users to signal the daemon to reload its config through systemd (`systemctl reload docker.service`). While reloading works, systemd expects the `ExecReload` command to be synchronous, so that it knows when the reload completes, and can account for this when managing dependent services. > Note however that reloading a daemon by enqueuing a signal (...) is usually > not a good choice, because this is an asynchronous operation and hence not > suitable when ordering reloads of multiple services against each other. Systemd 253 introduced a new Type (Type=notify-reload, see [systemd#25916]), which allows setting a "ReloadSignal" instead, if the service supports it by including a [MONOTONIC_USEC] value in its "RELOADING=1" notifications. This patch: - adds reload notifications to the daemon to notify when the daemon got signaled to reload its configuration see [sd_notify(3)]. - appends a [MONOTONIC_USEC] value to the reload notification to support systemd 253's notify-reload protocol. This is backwards-compatible with older systemd releases as the systemd service manager ignores unknown assignments in notifications. - adds a `notifyReady` callback to notify when the reload finished, which we currently send regardless if the reload was successful or failed (which could be due to an invalid config). [ExecReload]: https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#ExecReload= [systemd#25916]: systemd/systemd#25916 [MONOTONIC_USEC]: https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html#MONOTONIC_USEC=… [sd_notify(3)]: https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html#RELOADING=1 Signed-off-by: Cory Snider <csnider@mirantis.com> Co-authored-by: Sebastiaan van Stijn <github@gone.nl> Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
…y.org-clock-1.x fix(deps): update module code.cloudfoundry.org/clock to v1.60.0
The build job has validate-dco as a dependency, but validate-dco is skipped for tags. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
gha/bin-image: Fix build not running for tags
go1.25.7 (released 2026-02-04) includes security fixes to the go command and the crypto/tls package, as well as bug fixes to the compiler and the crypto/x509 package. See the Go 1.25.7 milestone on our issue tracker for details: https://github.com/golang/go/issues?q=milestone%3AGo1.25.7+label%3ACherryPickApproved full diff: golang/go@go1.25.6...go1.25.7 From the security mailing list: > Hello gophers, > > We have just released Go versions 1.25.7 and 1.24.13, minor point releases. > > These releases include 2 security fixes following the security policy: > > - cmd/cgo: remove user-content from doc strings in cgo ASTs > > A discrepancy between how Go and C/C++ comments > were parsed allowed for code smuggling into the > resulting cgo binary. > > To prevent this behavior, the cgo compiler > will no longer parse user-provided doc > comments. > > Thank you to RyotaK (https://ryotak.net) of > GMO Flatt Security Inc. for reporting this issue. > > This is CVE-2025-61732 and https://go.dev/issue/76697. > > - crypto/tls: unexpected session resumption when using Config.GetConfigForClient > > Config.GetConfigForClient is documented to use the original Config's session > ticket keys unless explicitly overridden. This can cause unexpected behavior if > the returned Config modifies authentication parameters, like ClientCAs: a > connection initially established with the parent (or a sibling) Config can be > resumed, bypassing the modified authentication requirements. > > If ClientAuth is VerifyClientCertIfGiven or RequireAndVerifyClientCert (on the > server) or InsecureSkipVerify is false (on the client), crypto/tls now checks > that the root of the previously-verified chain is still in ClientCAs/RootCAs > when resuming a connection. > > Go 1.26 Release Candidate 2, Go 1.25.6, and Go 1.24.12 had fixed a similar issue > related to session ticket keys being implicitly shared by Config.Clone. Since > this fix is broader, the Config.Clone behavior change has been reverted. > > Note that VerifyPeerCertificate still behaves as documented: it does not apply > to resumed connections. Applications that use Config.GetConfigForClient or > Config.Clone and do not wish to blindly resume connections established with the > original Config must use VerifyConnection instead (or SetSessionTicketKeys or > SessionTicketsDisabled). > > Thanks to Coia Prant (github.com/rbqvq) for reporting this issue. > > This updates CVE-2025-68121 and Go issue https://go.dev/issue/77217. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Update to the latest version: - https://github.com/go-delve/delve/releases/tag/v1.26.0 - https://github.com/go-delve/delve/blob/master/CHANGELOG.md#1260-2025-12-18 Looks like it now also added support for linux/riscv64 and that linux/ppc64le left "experimental". Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
update to go1.25.7
Introduced by commit 4de8459 ("libnet: add OTEL tracing to the embedded DNS"). Signed-off-by: Rob Murray <rob.murray@docker.com>
daemon/command: add support for sd_notify "reload" notifications
gha: update OTEL collector to v0.144.0
…endencies Before b0c8ff7, system validation would not take place until the daemon was actually started. This allowed (on Windows) (un)registering the system service (`dockerd --register-service`, `dockerd --unregister-service`) before installing other system requirements (most notably, the Windows Containers feature). This patch changes the behavior to allow this scenario; we perform validation when explicitly requested (through the `--validate` flag), and perform the same validation when starting the daemon. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The CheckSystem function on Windows is not without cost. Add a sync.OnceValue to store the result, so that we can call it in multiple places. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Our Linux integration test harness continues to run tests for subsequent packages after one package's tests fail unless the environment variable TEST_INTEGRATION_FAIL_FAST is set to a nonempty value. Our Windows integration test harness always fails fast. Modify our integration test harness on Windows to follow the same conventions as our Linux harness. Change `make.ps1 -TestIntegration` to only skip testing the remaining packages on failure when the TEST_INTEGRATON_FAIL_FAST environment variable is set. Signed-off-by: Cory Snider <csnider@mirantis.com>
hack/make.ps1: respect $TEST_INTEGRATION_FAIL_FAST
Signed-off-by: Cory Snider <csnider@mirantis.com>
The Windows integration test harness goes out of its way to set TEST_INTEGRATION_USE_GRAPHDRIVER=1 in the graphdriver branches of the test matrix. But on Windows the graphdriver is already the default. Explicitly configure the daemon to use the containerd snapshotter in the snapshotter branches of the test matrix. Signed-off-by: Cory Snider <csnider@mirantis.com>
Buildkit was enabled for Windows engines when using containerd snapshotters in commit a9ec07a. Buildkit's integration tests are run on Windows in CI, but a handful of daemon integration tests are still skipped. Change those tests to only skip on Windows when the daemon under test is not using containerd snapshotters. Signed-off-by: Cory Snider <csnider@mirantis.com>
fix(deps): update module golang.org/x/net to v0.51.0
Signed-off-by: Mend Renovate <bot@renovateapp.com>
Update circl to 1.6.3
…on-github-runtime-4.x chore(deps): update crazy-max/ghaction-github-runtime action to v4
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
vendor: update buildkit to v0.28.0
…lti-mount daemon: fix getSourceMount to handle multiple mounts at same path
Signed-off-by: Shiv Tyagi <Shiv.Tyagi@amd.com>
Change GPU device driver registration from init-time function assignment to direct function exports. This removes the init() function and global function variable pattern in favor of a more explicit approach. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The *_test.go pattern was causing excessive noise by labeling all PRs that include test files with area/testing, even when the primary focus of the PR was not testing infrastructure itself. Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
gha/labeler: Remove *_test.go from area/testing label
Add an integration test to verify that getSourceMount returns the most recent mount entry when a path has multiple bind mount entries with different propagation settings. Regression test for #43714. Signed-off-by: tushar sariya <tushar.97@hotmail.com>
integration/image: pull ppc64le and s390x in TestSaveAndLoadPlatform
Use CDI for GPU injection for AMD devices for --gpus
Fix swagger/OpenAPI return value specification for /system/df endpoint.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
network/connect: Support MacAddress
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Drop replace rules
full diff: 37cc25c...api/v1.54.0 Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
vendor: github.com/moby/moby/api v1.54.0
full diff: 37cc25c...client/v0.3.0 Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
daemon: add regression test for getSourceMount
vendor: github.com/moby/moby/client v0.3.0
Includes fix for panic when client uses a closed stream full diff: containerd/ttrpc@v1.2.7...v1.2.8 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The API Dockerfile should be ok to ignore for this check, as it's not part of the module; ``` ================================================ ================================================ api diff: -ARG GO_VERSION=1.25.7 +ARG GO_VERSION=1.25.8 ================================================ Detected changes in ./api directory, checking for replace rule... null ERROR: Changes detected in ./api but go.mod is missing a replace rule for github.com/moby/moby/api Please run ./hack/vendor.sh replace ================================================ ``` Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
vendor: github.com/containerd/ttrpc v1.2.8
Replace timestamp-based duplicate exit detection for running containers with a live containerd task status check, and ignore exits only when the task is still `Running`. Also simplify restarting-state handling by always treating exit events as duplicates while restart processing is in progress, and add warning logs for task status lookups. This avoids relying on wall-clock timestamps that can move backward (e.g., NTP), which could misclassify duplicate exit events. Signed-off-by: Wei Fu <fuweid89@gmail.com>
ci: module-replace: ignore Dockerfile for api changes
bugfix: handle duplicate exit events via task status
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )