vendor: github.com/moby/buildkit v0.14.0-rc2.0.20240610193248-7da4d591c4dc

Signed-off-by: CrazyMax <1951866+crazy-max@users.noreply.github.com>

_vendor/github.com/moby/buildkit/docs/buildkitd.toml.md

@@ -136,4 +136,25 @@ insecure-entitlements = [ "network.host", "security.insecure" ]
 # optionally mirror configuration can be done by defining it as a registry.
 [registry."yourmirror.local:5000"]
   http = true
+
+# Frontend control
+[frontend."dockerfile.v0"]
+  enabled = true
+
+[frontend."gateway.v0"]
+  enabled = true
+
+  # If allowedRepositories is empty, all gateway sources are allowed.
+  # Otherwise, only the listed repositories are allowed as a gateway source.
+  # 
+  # NOTE: Only the repository name (without tag) is compared.
+  #
+  # Example:
+  # allowedRepositories = [ "docker-registry.wikimedia.org/repos/releng/blubber/buildkit" ]
+  allowedRepositories = []
+
+[system]
+  # how often buildkit scans for changes in the supported emulated platforms
+  platformsCacheMaxAge = "1h"
+
 ```

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/reference.md

@@ -1520,7 +1520,7 @@ not translate between Linux and Windows, the use of `/etc/passwd` and `/etc/grou
 translating user and group names to IDs restricts this feature to only be viable for
 Linux OS-based containers.
 
-All files and directories copied from the build context are created with a UID and GID of 0.unless the
+All files and directories copied from the build context are created with a UID and GID of `0` unless the
 optional `--chown` flag specifies a given username, groupname, or UID/GID
 combination to request specific ownership of the copied content. The
 format of the `--chown` flag allows for either username and groupname strings

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md

@@ -0,0 +1,88 @@
+---
+title: Build checks
+description: |
+  BuildKit has built-in support for analyzing your build configuration based on
+  a set of pre-defined rules for enforcing Dockerfile and building best
+  practices.
+keywords: buildkit, linting, dockerfile, frontend, rules
+---
+
+BuildKit has built-in support for analyzing your build configuration based on a
+set of pre-defined rules for enforcing Dockerfile and building best practices.
+Adhering to these rules helps avoid errors and ensures good readability of your
+Dockerfile.
+
+Checks run as a build invocation, but instead of producing a build output, it
+performs a series of checks to validate that your build doesn't violate any of
+the rules. To run a check, use the `--check` flag:
+
+```console
+$ docker build --check .
+```
+
+<table>
+  <thead>
+    <tr>
+      <th>Name</th>
+      <th>Description</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td><a href="./stage-name-casing/">StageNameCasing</a></td>
+      <td>Stage names should be lowercase</td>
+    </tr>
+    <tr>
+      <td><a href="./from-as-casing/">FromAsCasing</a></td>
+      <td>The 'as' keyword should match the case of the 'from' keyword</td>
+    </tr>
+    <tr>
+      <td><a href="./no-empty-continuations/">NoEmptyContinuations</a></td>
+      <td>Empty continuation lines will become errors in a future release</td>
+    </tr>
+    <tr>
+      <td><a href="./consistent-instruction-casing/">ConsistentInstructionCasing</a></td>
+      <td>Instructions should be in consistent casing (all lower or all upper)</td>
+    </tr>
+    <tr>
+      <td><a href="./file-consistent-command-casing/">FileConsistentCommandCasing</a></td>
+      <td>All commands within the Dockerfile should use the same casing (either upper or lower)</td>
+    </tr>
+    <tr>
+      <td><a href="./duplicate-stage-name/">DuplicateStageName</a></td>
+      <td>Stage names should be unique</td>
+    </tr>
+    <tr>
+      <td><a href="./reserved-stage-name/">ReservedStageName</a></td>
+      <td>Reserved words should not be used as stage names</td>
+    </tr>
+    <tr>
+      <td><a href="./json-args-recommended/">JSONArgsRecommended</a></td>
+      <td>JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals</td>
+    </tr>
+    <tr>
+      <td><a href="./maintainer-deprecated/">MaintainerDeprecated</a></td>
+      <td>The MAINTAINER instruction is deprecated, use a label instead to define an image author</td>
+    </tr>
+    <tr>
+      <td><a href="./undefined-arg-in-from/">UndefinedArgInFrom</a></td>
+      <td>FROM command must use declared ARGs</td>
+    </tr>
+    <tr>
+      <td><a href="./workdir-relative-path/">WorkdirRelativePath</a></td>
+      <td>Relative workdir without an absolute workdir declared within the build can have unexpected results if the base image changes</td>
+    </tr>
+    <tr>
+      <td><a href="./undefined-var/">UndefinedVar</a></td>
+      <td>Variables should be defined before their use</td>
+    </tr>
+    <tr>
+      <td><a href="./multiple-instructions-disallowed/">MultipleInstructionsDisallowed</a></td>
+      <td>Multiple instructions of the same type should not be used in the same stage</td>
+    </tr>
+    <tr>
+      <td><a href="./legacy-key-value-format/">LegacyKeyValueFormat</a></td>
+      <td>Legacy key/value format with whitespace separator should not be used</td>
+    </tr>
+  </tbody>
+</table>

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md

@@ -0,0 +1,45 @@
+---
+title: ConsistentInstructionCasing
+description: Instructions should be in consistent casing (all lower or all upper)
+aliases:
+  - /go/dockerfile/rule/consistent-instruction-casing/
+---
+
+## Output
+
+```text
+Command 'EntryPoint' should be consistently cased
+```
+
+## Description
+
+Instruction keywords should use consistent casing (all lowercase or all
+uppercase). Using a case that mixes uppercase and lowercase, such as
+`PascalCase` or `snakeCase`, letters result in poor readability.
+
+## Examples
+
+❌ Bad: don't mix uppercase and lowercase.
+
+```dockerfile
+From alpine
+Run echo hello > /greeting.txt
+EntRYpOiNT ["cat", "/greeting.txt"]
+```
+
+✅ Good: all uppercase.
+
+```dockerfile
+FROM alpine
+RUN echo hello > /greeting.txt
+ENTRYPOINT ["cat", "/greeting.txt"]
+```
+
+✅ Good: all lowercase.
+
+```dockerfile
+from alpine
+run echo hello > /greeting.txt
+entrypoint ["cat", "/greeting.txt"]
+```
+

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md

@@ -0,0 +1,38 @@
+---
+title: DuplicateStageName
+description: Stage names should be unique
+aliases:
+  - /go/dockerfile/rule/duplicate-stage-name/
+---
+
+## Output
+
+```text
+Duplicate stage name 'foo-base', stage names should be unique
+```
+
+## Description
+
+Defining multiple stages with the same name results in an error because the
+builder is unable to uniquely resolve the stage name reference.
+
+## Examples
+
+❌ Bad: `builder` is declared as a stage name twice.
+
+```dockerfile
+FROM debian:latest AS builder
+RUN apt-get update; apt-get install -y curl
+
+FROM golang:latest AS builder
+```
+
+✅ Good: stages have unique names.
+
+```dockerfile
+FROM debian:latest AS deb-builder
+RUN apt-get update; apt-get install -y curl
+
+FROM golang:latest AS go-builder
+```
+

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/file-consistent-command-casing.md

@@ -0,0 +1,61 @@
+---
+title: FileConsistentCommandCasing
+description: All commands within the Dockerfile should use the same casing (either upper or lower)
+aliases:
+  - /go/dockerfile/rule/file-consistent-command-casing/
+---
+
+## Output
+
+Example warning:
+
+```text
+Command 'foo' should match the case of the command majority (uppercase)
+```
+
+## Description
+
+Instructions within a Dockerfile should have consistent casing through out the
+entire files. Instructions are not case-sensitive, but the convention is to use
+uppercase for instruction keywords to make it easier to distinguish keywords
+from arguments.
+
+Whether you prefer instructions to be uppercase or lowercase, you should make
+sure you use consistent casing to help improve readability of the Dockerfile.
+
+## Examples
+
+❌ Bad: mixed uppercase and lowercase.
+
+```dockerfile
+FROM alpine:latest AS builder
+run apk --no-cache add build-base
+
+FROM builder AS build1
+copy source1.cpp source.cpp
+```
+
+✅ Good: all uppercase.
+
+```dockerfile
+FROM alpine:latest AS builder
+RUN apk --no-cache add build-base
+
+FROM builder AS build1
+COPY source1.cpp source.cpp
+```
+
+✅ Good: all lowercase.
+
+```dockerfile
+from alpine:latest as builder
+run apk --no-cache add build-base
+
+from builder as build1
+copy source1.cpp source.cpp
+```
+
+## Related errors
+
+- [`FromAsCasing`](./from-as-casing.md)
+

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md

@@ -0,0 +1,44 @@
+---
+title: FromAsCasing
+description: The 'as' keyword should match the case of the 'from' keyword
+aliases:
+  - /go/dockerfile/rule/from-as-casing/
+---
+
+## Output
+
+```text
+'as' and 'FROM' keywords' casing do not match
+```
+
+## Description
+
+While Dockerfile keywords can be either uppercase or lowercase, mixing case
+styles is not recommended for readability. This rule reports violations where
+mixed case style occurs for a `FROM` instruction with an `AS` keyword declaring
+a stage name.
+
+## Examples
+
+❌ Bad: `FROM` is uppercase, `AS` is lowercase.
+
+```dockerfile
+FROM debian:latest as builder
+```
+
+✅ Good: `FROM` and `AS` are both uppercase
+
+```dockerfile
+FROM debian:latest AS deb-builder
+```
+
+✅ Good: `FROM` and `AS` are both lowercase.
+
+```dockerfile
+from debian:latest as deb-builder
+```
+
+## Related errors
+
+- [`FileConsistenCommandCasing`](./file-consistent-command-casing.md)
+

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md

@@ -0,0 +1,66 @@
+---
+title: JSONArgsRecommended
+description: JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals
+aliases:
+  - /go/dockerfile/rule/json-args-recommended/
+---
+
+## Output
+
+```text
+JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals
+```
+
+## Description
+
+`ENTRYPOINT` and `CMD` instructions both support two different syntaxes for
+arguments:
+
+- Shell form: `CMD my-cmd start`
+- Exec form: `CMD ["my-cmd", "start"]`
+
+When you use shell form, the executable runs as a child process to a shell,
+which doesn't pass signals. This means that the program running in the
+container can't detect OS signals like `SIGTERM` and `SIGKILL` and respond to
+them correctly.
+
+## Examples
+
+❌ Bad: the `ENTRYPOINT` command doesn't receive OS signals.
+
+```dockerfile
+FROM alpine
+ENTRYPOINT my-program start
+# entrypoint becomes: /bin/sh -c my-program start
+```
+
+To make sure the executable can receive OS signals, use the exec form for `CMD`
+and `ENTRYPOINT`, which lets you run the executable as the main process (`PID
+1`) in the container, avoiding a shell parent process.
+
+✅ Good: the `ENTRYPOINT` receives OS signals.
+
+```dockerfile
+FROM alpine
+ENTRYPOINT ["my-program", "start"]
+# entrypoint becomes: my-program start
+```
+
+Note that running programs as PID 1 means the program now has the special
+responsibilities and behaviors associated with PID 1 in Linux, such as reaping
+child processes.
+
+Alternatively, if you want to ignore this lint rule because you do want your
+executable to be invoked via a shell, you can use the
+[`SHELL`](https://docs.docker.com/reference/dockerfile.md#shell) Dockerfile
+instruction to explicitly specify a shell to use.
+
+✅ Good: shell is explicitly defined.
+
+```dockerfile
+FROM alpine
+RUN apk add bash
+SHELL ["/bin/bash", "-c"]
+ENTRYPOINT echo "hello world"
+```
+

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md

@@ -0,0 +1,38 @@
+---
+title: LegacyKeyValueFormat
+description: Legacy key/value format with whitespace separator should not be used
+aliases:
+  - /go/dockerfile/rule/legacy-key-value-format/
+---
+
+## Output
+
+```text
+"ENV key=value" should be used instead of legacy "ENV key value" format
+```
+
+## Description
+
+The correct format for declaring environment variables and build arguments in a
+Dockerfile is `ENV key=value` and `ARG key=value`, where the variable name
+(`key`) and value (`value`) are separated by an equals sign (`=`).
+Historically, Dockerfiles have also supported a space separator between the key
+and the value (for example, `ARG key value`). This legacy format is deprecated,
+and you should only use the format with the equals sign.
+
+## Examples
+
+❌ Bad: using a space separator for variable key and value.
+
+```dockerfile
+FROM alpine
+ARG foo bar
+```
+
+✅ Good: use an equals sign to separate key and value.
+
+```dockerfile
+FROM alpine
+ARG foo=bar
+```
+

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md

@@ -0,0 +1,33 @@
+---
+title: MaintainerDeprecated
+description: The MAINTAINER instruction is deprecated, use a label instead to define an image author
+aliases:
+  - /go/dockerfile/rule/maintainer-deprecated/
+---
+
+## Output
+
+```text
+MAINTAINER instruction is deprecated in favor of using label
+```
+
+## Description
+
+The `MAINTAINER` instruction, used historically for specifying the author of
+the Dockerfile, is deprecated. To set author metadata for an image, use the
+`org.opencontainers.image.authors` [OCI label](https://github.com/opencontainers/image-spec/blob/main/annotations.md#pre-defined-annotation-keys).
+
+## Examples
+
+❌ Bad: don't use the `MAINTAINER` instruction
+
+```dockerfile
+MAINTAINER moby@example.com
+```
+
+✅ Good: specify the author using the `org.opencontainers.image.authors` label
+
+```dockerfile
+LABEL org.opencontainers.image.authors="moby@example.com"
+```
+

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md

@@ -0,0 +1,50 @@
+---
+title: MultipleInstructionsDisallowed
+description: Multiple instructions of the same type should not be used in the same stage
+aliases:
+  - /go/dockerfile/rule/multiple-instructions-disallowed/
+---
+
+## Output
+
+```text
+Multiple CMD instructions should not be used in the same stage because only the last one will be used
+```
+
+## Description
+
+If you have multiple `CMD`, `HEALTHCHECK`, or `ENTRYPOINT` instructions in your
+Dockerfile, only the last occurrence is used. An image can only ever have one
+`CMD`, `HEALTHCHECK`, and `ENTRYPOINT`.
+
+## Examples
+
+❌ Bad: Duplicate instructions.
+
+```dockerfile
+FROM alpine
+CMD echo "Hello, Norway!"
+CMD echo "Hello, Sweden!"
+# Only "Hello, Sweden!" will be printed
+```
+
+✅ Good: only one `CMD` instruction.
+
+```dockerfile
+FROM alpine
+CMD echo "Hello, Norway!"; echo "Hello, Sweden!"
+```
+
+You can have both a regular, top-level `CMD`
+and a separate `CMD` for a `HEALTHCHECK` instruction.
+
+✅ Good: only one top-level `CMD` instruction.
+
+```dockerfile
+FROM python:alpine
+RUN apk add curl
+HEALTHCHECK --interval=1s --timeout=3s \
+  CMD curl -f http://localhost:8080 || exit 1
+CMD python -m http.server 8080
+```
+

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuations.md

@@ -0,0 +1,54 @@
+---
+title: NoEmptyContinuations
+description: Empty continuation lines will become errors in a future release
+aliases:
+  - /go/dockerfile/rule/no-empty-continuations/
+---
+
+## Output
+
+```text
+Empty continuation line found in: RUN apk add     gnupg     curl
+```
+
+## Description
+
+Support for empty continuation (`/`) lines have been deprecated and will
+generate errors in future versions of the Dockerfile syntax.
+
+Empty continuation lines are empty lines following a newline escape:
+
+```dockerfile
+FROM alpine
+RUN apk add \
+
+    gnupg \
+
+    curl
+```
+
+Support for such empty lines is deprecated, and a future BuildKit release will
+remove support for this syntax entirely, causing builds to break. To avoid
+future errors, remove the empty lines, or add comments, since lines with
+comments aren't considered empty.
+
+## Examples
+
+❌ Bad: empty continuation line between `EXPOSE` and 80.
+
+```dockerfile
+FROM alpine
+EXPOSE \
+
+80
+```
+
+✅ Good: comments do not count as empty lines.
+
+```dockerfile
+FROM alpine
+EXPOSE \
+# Port
+80
+```
+

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md

@@ -0,0 +1,36 @@
+---
+title: ReservedStageName
+description: Reserved words should not be used as stage names
+aliases:
+  - /go/dockerfile/rule/reserved-stage-name/
+---
+
+## Output
+
+```text
+'scratch' is reserved and should not be used as a stage name
+```
+
+## Description
+
+Reserved words should not be used as names for stages in multi-stage builds.
+The reserved words are:
+
+- `context`
+- `scratch`
+
+## Examples
+
+❌ Bad: `scratch` and `context` are reserved names.
+
+```dockerfile
+FROM alpine AS scratch
+FROM alpine AS context
+```
+
+✅ Good: the stage name `builder` is not reserved.
+
+```dockerfile
+FROM alpine AS builder
+```
+

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md

@@ -0,0 +1,32 @@
+---
+title: StageNameCasing
+description: Stage names should be lowercase
+aliases:
+  - /go/dockerfile/rule/stage-name-casing/
+---
+
+## Output
+
+```text
+Stage name 'BuilderBase' should be lowercase
+```
+
+## Description
+
+To help distinguish Dockerfile instruction keywords from identifiers, this rule
+forces names of stages in a multi-stage Dockerfile to be all lowercase.
+
+## Examples
+
+❌ Bad: mixing uppercase and lowercase characters in the stage name.
+
+```dockerfile
+FROM alpine AS BuilderBase
+```
+
+✅ Good: stage name is all in lowercase.
+
+```dockerfile
+FROM alpine AS builder-base
+```
+

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md

@@ -0,0 +1,54 @@
+---
+title: UndefinedArgInFrom
+description: FROM command must use declared ARGs
+aliases:
+  - /go/dockerfile/rule/undefined-arg-in-from/
+---
+
+## Output
+
+```text
+FROM argument 'VARIANT' is not declared
+```
+
+## Description
+
+This rule warns for cases where you're consuming an undefined build argument in
+`FROM` instructions.
+
+Interpolating build arguments in `FROM` instructions can be a good way to add
+flexibility to your build, and lets you pass arguments that overriding the base
+image of a stage. For example, you might use a build argument to specify the
+image tag:
+
+```dockerfile
+ARG ALPINE_VERSION=3.20
+
+FROM alpine:${ALPINE_VERSION}
+```
+
+This makes it possible to run the build with a different `alpine` version by
+specifying a build argument:
+
+```console
+$ docker buildx build --build-arg ALPINE_VERSION=edge .
+```
+
+This check also tries to detect and warn when a `FROM` instruction reference
+miss-spelled built-in build arguments, like `BUILDPLATFORM`.
+
+## Examples
+
+❌ Bad: the `VARIANT` build argument is undefined.
+
+```dockerfile
+FROM node:22${VARIANT} AS jsbuilder
+```
+
+✅ Good: the `VARIANT` build argument is defined.
+
+```dockerfile
+ARG VARIANT="-alpine3.20"
+FROM node:22${VARIANT} AS jsbuilder
+```
+

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md

@@ -0,0 +1,55 @@
+---
+title: UndefinedVar
+description: Variables should be defined before their use
+aliases:
+  - /go/dockerfile/rule/undefined-var/
+---
+
+## Output
+
+```text
+Usage of undefined variable '$foo'
+```
+
+## Description
+
+Before you reference an environment variable or a build argument in a `RUN`
+instruction, you should ensure that the variable is declared in the Dockerfile,
+using the `ARG` or `ENV` instructions.
+
+Attempting to access an environment variable without explicitly declaring it
+doesn't necessarily result in a build error, but it may yield an unexpected
+result or an error later on in the build process.
+
+This check also attempts to detect if you're accessing a variable with a typo.
+For example, given the following Dockerfile:
+
+```dockerfile
+FROM alpine
+ENV PATH=$PAHT:/app/bin
+```
+
+The check detects that `$PAHT` is undefined, and that it's probably a
+misspelling of `PATH`.
+
+```text
+Usage of undefined variable '$PAHT' (did you mean $PATH?)
+```
+
+## Examples
+
+❌ Bad: `$foo` is an undefined build argument.
+
+```dockerfile
+FROM alpine AS base
+COPY $foo .
+```
+
+✅ Good: declaring `foo` as a build argument before attempting to access it.
+
+```dockerfile
+FROM alpine AS base
+ARG foo
+COPY $foo .
+```
+

_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md

@@ -0,0 +1,48 @@
+---
+title: WorkdirRelativePath
+description: Relative workdir without an absolute workdir declared within the build can have unexpected results if the base image changes
+aliases:
+  - /go/dockerfile/rule/workdir-relative-path/
+---
+
+## Output
+
+```text
+Relative workdir 'app/src' can have unexpected results if the base image changes
+```
+
+## Description
+
+When specifying `WORKDIR` in a build stage, you can use an absolute path, like
+`/build`, or a relative path, like `./build`. Using a relative path means that
+the working directory is relative to whatever the previous working directory
+was. So if your base image uses `/usr/local/foo` as a working directory, and
+you specify a relative directory like `WORKDIR build`, the effective working
+directory becomes `/usr/local/foo/build`.
+
+The `WorkdirRelativePath` build rule warns you if you use a `WORKDIR` with a
+relative path without first specifying an absolute path in the same Dockerfile.
+The rationale for this rule is that using a relative working directory for base
+image built externally is prone to breaking, since working directory may change
+upstream without warning, resulting in a completely different directory
+hierarchy for your build.
+
+## Examples
+
+❌ Bad: this assumes that `WORKDIR` in the base image is `/`
+(if that changes upstream, the `web` stage is broken).
+
+```dockerfile
+FROM nginx AS web
+WORKDIR usr/share/nginx/html
+COPY public .
+```
+
+✅ Good: a leading slash ensures that `WORKDIR` always ends up at the desired path.
+
+```dockerfile
+FROM nginx AS web
+WORKDIR /usr/share/nginx/html
+COPY public .
+```
+

_vendor/modules.txt

@@ -1,6 +1,6 @@
 # github.com/moby/moby v26.1.2+incompatible
-# github.com/moby/buildkit v0.13.1
+# github.com/moby/buildkit v0.14.0-rc2.0.20240610193248-7da4d591c4dc
 # github.com/docker/buildx v0.14.1
-# github.com/docker/cli v26.1.3+incompatible
+# github.com/docker/cli v26.1.4+incompatible
 # github.com/docker/compose/v2 v2.27.0
 # github.com/docker/scout-cli v1.9.3

go.mod

@@ -6,10 +6,10 @@ toolchain go1.21.1
 
 require (
 	github.com/docker/buildx v0.14.1 // indirect
-	github.com/docker/cli v26.1.3+incompatible // indirect
+	github.com/docker/cli v26.1.4+incompatible // indirect
 	github.com/docker/compose/v2 v2.27.0 // indirect
 	github.com/docker/scout-cli v1.9.3 // indirect
-	github.com/moby/buildkit v0.13.1 // indirect
+	github.com/moby/buildkit v0.14.0-rc2.0.20240610193248-7da4d591c4dc // indirect
 	github.com/moby/moby v26.1.2+incompatible // indirect
 )
 
@@ -18,6 +18,6 @@ replace (
 	github.com/docker/cli => github.com/docker/cli v26.1.3-0.20240513184838-60f2d38d5341+incompatible
 	github.com/docker/compose/v2 => github.com/docker/compose/v2 v2.27.0
 	github.com/docker/scout-cli => github.com/docker/scout-cli v1.9.3
-	github.com/moby/buildkit => github.com/moby/buildkit v0.13.0-rc3.0.20240424175633-5fce077ed0e0
+	github.com/moby/buildkit => github.com/moby/buildkit v0.14.0-rc2.0.20240610193248-7da4d591c4dc
 	github.com/moby/moby => github.com/moby/moby v26.1.2+incompatible
 )

go.sum

@@ -242,6 +242,10 @@ github.com/moby/buildkit v0.13.0-rc3.0.20240424175633-5fce077ed0e0 h1:wTJCJDC1wo
 github.com/moby/buildkit v0.13.0-rc3.0.20240424175633-5fce077ed0e0/go.mod h1:wH5RTVyFjMQ67euC1e3UUSw7yQe7JkAHmf8OZkQY7Y4=
 github.com/moby/buildkit v0.13.0 h1:reVR1Y+rbNIUQ9jf0Q1YZVH5a/nhOixZsl+HJ9qQEGI=
 github.com/moby/buildkit v0.13.0/go.mod h1:aNmNQKLBFYAOFuzQjR3VA27/FijlvtBD1pjNwTSN37k=
+github.com/moby/buildkit v0.14.0-rc2 h1:qvl0hOKeyAWReOkksNtstQjPNaAD4jN3Dvq4r7slqYM=
+github.com/moby/buildkit v0.14.0-rc2/go.mod h1:/ZJNHNVso1nf063XlDhEkNEcRNW19utVpUKixCUo9Ks=
+github.com/moby/buildkit v0.14.0-rc2.0.20240610193248-7da4d591c4dc h1:D/QzYP+52V4IzxMvcWe8ppgg0XptfI4/JCd7ry79gqY=
+github.com/moby/buildkit v0.14.0-rc2.0.20240610193248-7da4d591c4dc/go.mod h1:1XssG7cAqv5Bz1xcGMxJL123iCv5TYN4Z/qf647gfuk=
 github.com/moby/locker v1.0.1/go.mod h1:S7SDdo5zpBK84bzzVlKr2V0hz+7x9hWbYC/kq7oQppc=
 github.com/moby/moby v24.0.2+incompatible h1:yH+5dRHH1x3XRKzl1THA2aGTy6CHYnkt5N924ADMax8=
 github.com/moby/moby v24.0.2+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=