Previously, if a long-lived plugin process (such as
an execution of `compose up`) was running and then
detached from a terminal, signalling the parent CLI
process to exit would leave the plugin process behind.
To address this, changes were introduced on the CLI side
(see: https://github.com/docker/cli/pull/4599) to enable
the CLI to notify a running plugin process that it should
exit. This makes it so that, when the parent CLI process
is going to exit, the command context of the plugin
command being executed is cancelled.
This commit takes advantage of these changes by tapping into
the command context's done channel and using it to teardown
on an up.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
`AdaptCmd` was previously checking for a `.WithCancel` suffix
on context strings, however it's possible for a context to be
cancellable without ending in that suffix, such as when
`context.WithValue` was called after `WithContext`, e.g.:
```go
context.Background.WithCancel.WithValue(type trace.traceContextKeyType,
val <not Stringer>).WithValue(type api.DryRunKey, val <not Stringer>)
```
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
update the package, which contains a fix in the ssh package.
full diff: https://github.com/golang/crypto/compare/v0.16.0...v0.17.0
from the security mailing:
> Hello gophers,
>
> Version v0.17.0 of golang.org/x/crypto fixes a protocol weakness in the
> golang.org/x/crypto/ssh package that allowed a MITM attacker to compromise
> the integrity of the secure channel before it was established, allowing
> them to prevent transmission of a number of messages immediately after
> the secure channel was established without either side being aware.
>
> The impact of this attack is relatively limited, as it does not compromise
> confidentiality of the channel. Notably this attack would allow an attacker
> to prevent the transmission of the SSH2_MSG_EXT_INFO message, disabling a
> handful of newer security features.
>
> This protocol weakness was also fixed in OpenSSH 9.6.
>
> Thanks to Fabian Bäumer, Marcus Brinkmann, and Jörg Schwenk from Ruhr
> University Bochum for reporting this issue.
>
> This is CVE-2023-48795 and Go issue https://go.dev/issue/64784.
>
> Cheers,
> Roland on behalf of the Go team
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The code used an atomic bool to guard channel writes. However, this
failed to synchronize with the call to close(), causing a panic.
Fix the race condition by using a mutex to guard the update to the
bool `stopped` and subsequent channel writes. This ensures atomic
execution of both updates to `stopped` and channel writes, preventing
races between writes and close().
Signed-off-by: horus <horus.li@gmail.com>
Related to:
- https://github.com/compose-spec/compose-spec/pull/435
- https://github.com/moby/moby/pull/45905
Since API v1.44, Moby supports a per-endpoint MAC address and returns a
warning when the container-wide mac_address field is set.
A corresponding field has been added to compose-spec and compose-go, so
we need to leverage it to set the right API field.
This commit is backward-compatible with compose files that still set the
container-wide mac_address field, and older API versions that don't know
about the endpoint-specific MAC address field.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Currently, we publish Compose artifacts following the OCI 1.1
specification, which is still in the RC state.
As a result, not all registries support it yet. Most notably,
AWS ECR will reject certain OCI 1.1-compliant requests with
`405 Method Not Supported` with cryptic `Invalid JSON` errors.
This adds initial support for Compose to generate either an
OCI 1.0 or OCI 1.1 compatible manifest. Notably, the OCI 1.0
manifest will be missing the `application/vnd.docker.compose.project`
artifact type, as that does not exist in that version of the
spec. (Less importantly, it uses an empty `ImageConfig`
instead of the newer `application/vnd.oci.empty.v1+json` media
type for the config.)
Currently, this is not exposed as an option (via CLI flags or
env vars). By default, OCI 1.1 is used unless the registry
domain is `amazonaws.com`, which indicates an ECR registry, so
Compose will instead use OCI 1.0.
Moving forward, we should decide how much we want to expose/
support different OCI versions and investigate if there's a
more generic way to feature probe the registry to avoid
maintaining a hardcoded list of domains, which is both tedious
and insufficient.
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Milas Bowman
Laura Brehm
Nicolas De Loof
Guillaume Lours
Sebastiaan van Stijn
dependabot[bot]
horus
Albin Kerouanton
Wes Higbee
vyneer
johnthagen
Amit Saha