The transport passed to NewResolver was applied only via
docker.WithClient. Pass it via docker.WithAuthClient too so the
authorizer's OAuth token fetches use it instead of http.DefaultClient.
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
Output was aligned with `docker ps --format json` in v2.21.0 (#10918)
but the docs were never updated.
Fixes#13850
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
When a service declares an env var without a value (e.g. `- KEY` or
`KEY:`), MappingWithEquals stores it as a nil *string. The previous
condition `existing != nil && ...` skipped the warning for this case,
allowing silent overwrites. Change to `existing == nil || ...` so the
warning fires for both nil (shell-inherit) and value-mismatch cases.
Add e2e tests for both list-style (`- KEY`) and map-style (`KEY:`)
YAML forms to lock in the behavior.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Yohta Kimura <38206553+rajyan@users.noreply.github.com>
The stop section only mentioned setenv being ignored; rawsetenv
is handled identically by the code but was missing from the docs.
The mermaid sequence diagram also lacked a rawsetenv step.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Yohta Kimura <38206553+rajyan@users.noreply.github.com>
rawsetenv injects provider variables without the service-name prefix, so
a key can collide with a value already set on the dependent service,
whether declared by the user in environment or emitted by another
provider. Log a warning and overwrite on collision, document the
precedence and the non-deterministic ordering between concurrent
providers, and cover the user-environment override with an e2e test.
Signed-off-by: Yohta Kimura <38206553+rajyan@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Providers can now send rawsetenv messages to inject environment
variables into dependent services without the automatic service name
prefix. This enables use cases where applications require exact
variable names that cannot be altered.
Closes#13727
Signed-off-by: Yohta Kimura <38206553+rajyan@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The run parameter was always passed as false at the single call site
and the run==true branch was dead code. Remove it so unparam stops
flagging callers added by PR #13742.
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
This fixture was not a valid JWT; the first 2 elements decode, but the last
one is malformed;
echo 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9' | base64 -d
{"alg":"HS256","typ":"JWT"}⏎
echo 'eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ' | base64 -d
{"sub":"1234567890","name":"John Doe","iat":1516239022⏎
echo 'SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw' | base64 -d
I�J�IHNJ(]�O��lj~�:N�%_�u
,⏎
This causes problems if the JWT parser is strict and rejecting invalid
JWT's.
It was added in 55b5f233c2, and probably copied
from an example, like https://github.com/knottx/JWTCodable#example-jwt-token,
but the last 2 bytes were truncated.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
`compose up --build` populates BuildOptions.Deps=true so the initial
startup also builds images for depends_on services. The watch rebuild
path reused the same BuildOptions pointer, only resetting Build.Services
to the watched service. Build.Deps stayed true, so s.build() switched
back to IncludeDependencies and rebuilt the upstream dependency too.
Fix it by working on a local copy of BuildOptions in rebuild() and
explicitly setting Deps=false. Using a local copy also removes the data
race on the shared pointer when concurrent file events fire.
Also fix a related leak in doBuildBake: the loop populating bake
configuration iterates over every service in the project (needed so
additional_contexts: service:xxx references can resolve), but it was
emitting the "Image X Building" progress event and tracking expected
images for services that were not part of serviceToBeBuild. Filter
those side-effects to the actual build set so the watch rebuild log
shows only the watched service.
Adds an e2e test reproducing the bug.
Fixes#13853
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
`docker compose publish` routed all registry traffic through Docker
Desktop's HTTP proxy. Publishing to a registry on localhost therefore
failed on Windows with:
proxyconnect tcp: open ./pipe/dockerHttpProxy: The system cannot
find the path specified.
even though `docker push`/`docker pull` worked against the same registry.
Two bugs in internal/desktop/proxy.go:
1. No loopback bypass. ProxyTransport forced every request through the
Docker Desktop proxy and its DialContext always dialed the proxy
socket, so loopback targets could never connect directly. Proxy
selection now bypasses the proxy only for loopback targets
(localhost, 127.0.0.0/8, ::1); all other registry traffic stays
routed through Docker Desktop's PAC-aware proxy so Desktop keeps
ownership of proxy decisions (e.g. enterprise-managed proxies). The
local process NO_PROXY/no_proxy is deliberately not honored, so a
broad value such as * or .corp cannot bypass centrally managed
proxy policy.
2. Malformed Windows pipe path. The proxy named-pipe endpoint was
hardcoded as npipe://./pipe/..., yielding the relative path
./pipe/dockerHttpProxy. It is now derived from the engine endpoint,
preserving its namespace. Docker Desktop reports the backslash form
npipe://\\.\pipe\docker_cli, so the derivation uses LastIndexAny to
handle both backslash and forward-slash forms.
Publishing to localhost now connects directly like `docker push`, while
every non-loopback registry still goes through the Docker Desktop proxy.
Fixes#13824
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Domantas Petrauskas <dom.petrauskas@gmail.com>
maxBeforeStatusWidth used len(l.taskID) (bytes) while applyPadding
used utf8.RuneCountInString (runes). For ASCII task IDs the two
agree and no symptom surfaces, but a taskID containing multi-byte
UTF-8 chars (CJK, emoji, accented Latin) reported a width larger
than its visual columns. computeOverflow then triggered truncation
where none was needed, and truncateLongestTaskID's byte-indexed
slice could land mid-multibyte sequence, corrupting the displayed
string.
Align the two measurements on rune count.
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
In narrow terminals (e.g. tmux panes), the TTY progress UI emitted
lines wider than terminalWidth because adjustLineWidth could shrink
details and taskID but never the progress field. When progress
carried the "X.XMB / Y.YMB" size suffix, the truncation loop exited
with overflow > 0 and applyPadding's max(timerPad, 1) floor pushed
the line one char over. tmux then wrapped the line visually while
print() kept counting logical lines, desyncing aec.Up() on the next
render and producing the mangled "[+] pull X/Y" header overwriting
prior task lines.
Track the size suffix byte length on lineData and let
adjustLineWidth drop it as an intermediate truncation step before
abbreviating the taskID.
Fixesdocker/compose#13595
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
The progress UI writes to dockerCli.Err() but the auto-mode selector
was probing dockerCli.Out().IsTerminal(), introduced when the
EventProcessor was moved to the CLI layer. Any context that pipes
stdout while keeping stderr attached — `docker compose up | tee log`,
some CI wrappers, PowerShell native-command capture — silently
dropped to plain mode.
Align the detection with the stream the renderer actually targets,
restoring v4 behavior. Extract the switch into selectEventProcessor
so the auto-mode logic can be unit-tested with a real pty pair.
Fixesdocker/compose#13570
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
golang.org/x/crypto v0.52.0 has various fixes for vulnerabilities.
These do NOT impact docker compose, but may show up in vulnerability
scanners;
govulncheck --version
Go: go1.26.4
Scanner: govulncheck@v1.3.0
DB: https://vuln.go.dev
DB updated: 2026-06-02 21:39:47 +0000 UTC
govulncheck -show verbose ./...
Fetching vulnerabilities from the database...
Checking the code against the vulnerabilities...
=== Package Results ===
Vulnerability #1: GO-2026-5023
Invoking VerifiedPublicKeyCallback permissions skip enforcement in
golang.org/x/crypto/ssh
More info: https://pkg.go.dev/vuln/GO-2026-5023
Module: golang.org/x/crypto
Found in: golang.org/x/crypto@v0.51.0
Fixed in: golang.org/x/crypto@v0.52.0
Vulnerability #2: GO-2026-5020
Invoking infinite loop on large channel writes in golang.org/x/crypto/ssh
More info: https://pkg.go.dev/vuln/GO-2026-5020
Module: golang.org/x/crypto
Found in: golang.org/x/crypto@v0.51.0
Fixed in: golang.org/x/crypto@v0.52.0
Vulnerability #3: GO-2026-5019
Invoking bypass of FIDO/U2F security keys physical interaction in
golang.org/x/crypto/ssh
More info: https://pkg.go.dev/vuln/GO-2026-5019
Module: golang.org/x/crypto
Found in: golang.org/x/crypto@v0.51.0
Fixed in: golang.org/x/crypto@v0.52.0
Vulnerability #4: GO-2026-5018
Invoking pathological RSA/DSA parameters may cause DoS in
golang.org/x/crypto/ssh
More info: https://pkg.go.dev/vuln/GO-2026-5018
Module: golang.org/x/crypto
Found in: golang.org/x/crypto@v0.51.0
Fixed in: golang.org/x/crypto@v0.52.0
Vulnerability #5: GO-2026-5017
Invoking client can cause server deadlock on unexpected responses in
golang.org/x/crypto/ssh
More info: https://pkg.go.dev/vuln/GO-2026-5017
Module: golang.org/x/crypto
Found in: golang.org/x/crypto@v0.51.0
Fixed in: golang.org/x/crypto@v0.52.0
Vulnerability #6: GO-2026-5016
Invoking memory leak when rejecting channels can lead to DoS in
golang.org/x/crypto/ssh
More info: https://pkg.go.dev/vuln/GO-2026-5016
Module: golang.org/x/crypto
Found in: golang.org/x/crypto@v0.51.0
Fixed in: golang.org/x/crypto@v0.52.0
Vulnerability #7: GO-2026-5015
Invoking server panic during CheckHostKey/Authenticate in
golang.org/x/crypto/ssh
More info: https://pkg.go.dev/vuln/GO-2026-5015
Module: golang.org/x/crypto
Found in: golang.org/x/crypto@v0.51.0
Fixed in: golang.org/x/crypto@v0.52.0
Vulnerability #8: GO-2026-5014
Invoking bypass of certificate restrictions in golang.org/x/crypto/ssh
More info: https://pkg.go.dev/vuln/GO-2026-5014
Module: golang.org/x/crypto
Found in: golang.org/x/crypto@v0.51.0
Fixed in: golang.org/x/crypto@v0.52.0
Vulnerability #9: GO-2026-5013
Invoking byte arithmetic causes underflow and panic in
golang.org/x/crypto/ssh
More info: https://pkg.go.dev/vuln/GO-2026-5013
Module: golang.org/x/crypto
Found in: golang.org/x/crypto@v0.51.0
Fixed in: golang.org/x/crypto@v0.52.0
=== Module Results ===
Vulnerability #1: GO-2026-5033
Invoking pathological inputs can lead to client panic in
golang.org/x/crypto/ssh/agent
More info: https://pkg.go.dev/vuln/GO-2026-5033
Module: golang.org/x/crypto
Found in: golang.org/x/crypto@v0.51.0
Fixed in: golang.org/x/crypto@v0.52.0
Vulnerability #2: GO-2026-5021
Invoking auth bypass via unenforced @revoked status in
golang.org/x/crypto/ssh/knownhosts
More info: https://pkg.go.dev/vuln/GO-2026-5021
Module: golang.org/x/crypto
Found in: golang.org/x/crypto@v0.51.0
Fixed in: golang.org/x/crypto@v0.52.0
Vulnerability #3: GO-2026-5006
Invoking agent constraints dropped when forwarding keys in
golang.org/x/crypto/ssh/agent
More info: https://pkg.go.dev/vuln/GO-2026-5006
Module: golang.org/x/crypto
Found in: golang.org/x/crypto@v0.51.0
Fixed in: golang.org/x/crypto@v0.52.0
Vulnerability #4: GO-2026-5005
Invoking key constraints not enforced in golang.org/x/crypto/ssh/agent
More info: https://pkg.go.dev/vuln/GO-2026-5005
Module: golang.org/x/crypto
Found in: golang.org/x/crypto@v0.51.0
Fixed in: golang.org/x/crypto@v0.52.0
Your code is affected by 2 vulnerabilities from 1 module.
This scan also found 9 vulnerabilities in packages you import and 4
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
follow-up to 7eeb7de7a2, adding more
links now that the CLI reference for docker logs has anchors for them.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This release include 3 security fixes following the security policy:
- mime: quadratic complexity in WordDecoder.DecodeHeader
Decoding a maliciously-crafted MIME header containing many invalid
encoded-words could consume excessive CPU.
The MIME decoder now better handles this case.
Thanks to p4p3r (https://hackerone.com/p4p3r_hak) for reporting this issue.
This is CVE-2026-42504 and Go issue https://go.dev/issue/79217.
- net/textproto: arbitrary input are included in errors without any escaping
When returning errors, functions in the net/textproto package would
include its input as part of the error, without any escaping. Note that
said input is often controlled by external parties when using this
package naturally. For example, a net/http client uses ReadMIMEHeader
when parsing the headers it receive from a server.
As a result, an attacker could inject arbitrary content into the error.
Practically, this can result in an attacker injecting misleading
content, terminal control bytes, etc. into a victim's output or logs.
This is CVE-2026-42507 and Go issue https://go.dev/issue/79346
- crypto/x509: split candidate hostname only once
(*x509.Certificate).VerifyHostname previously called matchHostnames in a loop
over all DNS Subject Alternative Name (SAN) entries. This caused
strings.Split(host, ".") to execute repeatedly on the same input hostname.
With a large DNS SAN list, verification costs scaled quadratically based on the
number of SAN entries multiplied by the hostname's label count. Because
x509.Verify validates hostnames before building the certificate chain, this
overhead occurred even for untrusted certificates.
Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue.
This is CVE-2026-27145 and https://go.dev/issue/79694.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.26.4
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
External reviewer noted that the alreadyStopped branch adds createNode
to removeDeps while the !alreadyStopped branch does not — semantically
correct but fragile, since it relies on the implicit invariant that
stopNode.DependsOn contains createNode in the !alreadyStopped path.
Spell out the invariant in a comment so a future maintainer who edits
the stop → create edge in the normal path knows they must also add
createNode unconditionally in the remove deps.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
Two coverage gaps surfaced by an external review:
- TestReconcileContainers_DependsOnChain: asserts that a service B with
depends_on: [A] produces a CreateContainer for B that depends on A's
last plan node (the serviceNodes mechanism in infrastructureDeps).
This was the only depends_on-via-plan-DAG behavior untested before.
- TestReconcileContainers_DependsOnScaleDown: companion test that
exercises the scale-down → dependent path specifically, verifying
that the previous commit's lastNode-on-scale-down fix actually wires
the dependency through.
- TestOperationTypeString: adds OpRunProvider to the table; all other
OperationType values were already covered.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
Three fixes surfaced by an external code review of the new reconciler:
1. Scale-down now propagates through serviceNodes. When a service is
scaled down (all containers in excess), reconcileService used to
continue without assigning lastNode, leaving r.serviceNodes[svc]
unset. Dependent services then declared no edge on the scale-down
ops and could start before the cleanup finished. Track the
RemoveContainer node as lastNode so depends_on chains pick it up.
2. mustRecreate errors are no longer silently ignored by sortContainers.
The comparator used `obsi, _ := r.mustRecreate(...)`, falling back
to false on any hashing error. Pre-compute obsolescence into a map
keyed by container ID before sorting and propagate the error to
reconcileService.
3. A container is no longer Stopped twice when its network and its
config both diverge. planRecreateNetwork already stops the affected
container as part of the disconnect/remove/recreate dance; the
subsequent planRecreateContainer (triggered via hasNetworkMismatch)
used to add another OpStopContainer against the now-stopped target.
Track stops in r.stoppedByPlan; planRecreateContainer reuses an
existing Stop node when present, and chains its Remove on both that
Stop and the replacement Create.
Two golden tests (TestReconcileNetworks_Diverged*) are updated to
reflect the new, dedupe'd plan shape (one Stop instead of two per
recreated container).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
Three improvements identified in the Principal Engineer pass but
deliberately deferred:
1. Test fidelity. Split executePlan into newPlanExecutor (constructs
the executor seeded from observed state) and (*planExecutor).run
(walks the DAG). Production callers go through executePlan
unchanged. TestExecutePlanRemoveContainerDropsFromCache now uses
newPlanExecutor + run, exercising the same errgroup, done-channel
and group-tracker wiring as production instead of a hand-rolled
loop over executeNode.
2. //nolint:unused chain. The three preserved helpers
(reconciler.prompt, planRecreateVolume, servicesUsingVolume) each
carried a separate "kept for future" comment. Consolidate the
rationale on the reconciler.prompt field doc and point the helper
nolint directives there, so a future cleanup is a single grep.
3. Concurrency test. Add TestExecutePlanConcurrentRemovesCacheCoherence
which builds N independent Stop→Remove chains in one plan; the
errgroup fans them out across goroutines that all hit
containersByService under the mutex. Passes under -race. Failure
would expose a missing or incorrect lock.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
Two related changes to the executor, plus the small cleanups they
attracted in review:
* Rename node consults a planner-set CreateNodeID instead of walking
ancestors. The old execRenameContainer searched node.DependsOn for a
CreateContainer result and fell back to a recursive walk through the
group chain. That worked only by convention; a future op with cross-
node data needs would have to rediscover or copy the pattern. Now the
rename op carries an explicit CreateNodeID int set at plan time and
the executor reads pctx[CreateNodeID].ContainerID directly. The
recursive findCreatedIDInChain is gone.
* Stop re-listing containers on every create. execCreateContainer used
to call getContainersByService(ctx, projectName) — a fresh
ContainerList per create — to resolve service references at execute
time. The executor now holds a live containersByService view seeded
from ObservedState (via observed.containersByService()) and grown as
OpCreateContainer nodes complete, so service references resolve from
memory. On OpRemoveContainer the removed container is dropped from
the view via slices.DeleteFunc, so a dependent's create that resolves
network_mode: service:x against the just-removed container cannot
pick up a stale ID (Containers.sorted() orders by canonical name and
would otherwise return the removed container).
* Defensive slices.Clone of op.Service.VolumesFrom in execCreateContainer.
resolveServiceReferences mutates VolumesFrom in place, and the
shallow struct copy of *op.Service still shares the backing array.
Single-execution-per-node makes it safe today, but the clone removes
the trap for any future parallel-execution mode.
* Operation gains a CreateNodeID int (not a *PlanNode pointer) to avoid
a structural cycle between Operation and PlanNode. OperationType
values are pinned to explicit integers so adding an op in the middle
cannot silently shift the others.
* execRenameContainer carries two checks so a missing CreateNodeID and
an empty produced ID are distinguishable in logs. Both are programmer
invariants (prefixed "internal:").
* containersByServiceFromObserved moved from a package-level helper to
a method on *ObservedState.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
ensureProjectVolumes already prompts the user when a volume's config hash
diverges from the compose file (create.go:1626) and recreates it on confirm.
The reconciler ran after ensureProjectVolumes and prompted again with the
exact same message — so a user who declined the first prompt was asked the
same question a second time.
Drop the prompt + recreate call from reconcileVolumes(). Recreation of
diverged volumes stays owned by ensureProjectVolumes; the reconciler only
plans the creation of missing volumes. If the user declined recreation,
the existing container's mounts still match the existing volume name and
hasVolumeMismatch correctly returns false, so containers are not falsely
flagged as obsolete.
Keep the supporting infrastructure available for future use, when
divergence detection migrates fully into the reconciler:
- reconciler.prompt field
- prompt parameter on reconcile()
- planRecreateVolume function (//nolint:unused)
- servicesUsingVolume function (//nolint:unused)
- noPrompt test helper
The reframed test (TestReconcileVolumes_DivergedIsIgnored) asserts the
new contract: a diverged volume produces no plan operations from the
reconciler.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
- plan.go: pin OperationType constants to explicit values so adding an op
in the middle doesn't shift the others.
- executor.go: remove the meaningless `var _ = getContainerProgressName`
line — same-package functions are always accessible.
- reconcile.go: fix the stale switch-default comment that contradicted
the case clause above it.
- reconcile.go: drop the local `serviceLabel` const that shadowed
`api.ServiceLabel` and use the shared constant.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Guillaume Lours <glours@users.noreply.github.com>
- Fix ContainerReplaceLabel detection: use op.Inherited != nil (not
op.Container) as signal for recreate in execCreateContainer
- Use observed network name (not desired) for DisconnectNetwork and
RemoveNetwork operations, in case the name changed
- Use observed volume name (not desired) for RemoveVolume operations
- Update reconciliation.md with 3 new lessons learned (7.8, 7.9, 7.10)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
- Remove the `convergence` struct and `newConvergence` constructor
- Extract `resolveServiceReferences` as a standalone function taking
`map[string]Containers` instead of a method on convergence
- Add `getContainersByService` helper on composeService
- Update run.go and executor.go to use the new standalone function
- Remove dead code: `getObservedState`, `setObservedState`
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
