Extend the built-in policy to validate signed moby/buildkit release and
floating tags before docker-container builders are created.
Pull the image first, inspect it through Docker, and bind verification to the
descriptor digest. Resolve signature attestations through the BuildKit API
embedded in the Docker daemon.
If pulling fails, use a local image while applying the same verification when
the containerd image store exposes an immutable descriptor. Keep the classic
image-store behavior unchanged because no descriptor is available.
Allow unmanaged repositories and digest-only references unchanged. Add the
allow-untrusted-image driver option as an explicit verification bypass.
Document the behavior and add policy, digest-pinning, and local fallback
coverage.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Images loaded into Docker's containerd image store are identified by
their manifest or index digest, while the legacy graphdriver store uses
the config digest.
buildx prefers containerimage.config.digest when the Moby exporter
returns both digests.
Some exporter responses still produce a usable iidfile, but affected
builds, such as those with attestations disabled, write a config digest
that Docker image commands cannot resolve.
Expose the Docker driver's image-store mode as a feature and set
prefer-image-digest for containerd-backed Moby exports.
Signed-off-by: Paweł Gronowski <git@grono.dev>
Extend testBuildPolicyCapsProxy so that instead of only checking that
the network proxy was enabled, the build runs a command that makes an
HTTP request to a local test server. The policy denies that URL as an
HTTP source, so the test now verifies that exec traffic actually flows
through the proxy and is subject to source policy, including the deny
message and DENY decision in the build output.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Evaluate source policy caps before solve requests so policies can enable
BuildKit proxy networking. Policy can return caps {"exec.proxy": true}
during the caps request to enable proxy network
support for the solve.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Allow passing policy content through stdin by specifying
"--file -" in the eval command. This enables piping policy
data without requiring a file on disk.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Removes the experimental flags and bits for dap and deletes some dead
code that somehow made its way this far without anyone noticing.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Pass the exit code through the exited event back to the client and
ensure that the printed text is printed completely.
Previously, the exited event just had a big todo and the printer would
sometimes fail to send messages to the connected client. This moves the
printer wait to before the debug adapter is closed to ensure that all
messages get sent through the connection to the editor. While there, I
also plumbed in the exit code to exited. It's not necessarily the real
exit code but it will produce a zero on build success and a non-zero
code on build failure so that should be good enough.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
When the debug thread was updated to always solve inputs from the
operation that it was tied to it became a bit overeager to evaluate
them. The intention of the steps is to have a single direct parent and
then potentially multiple "function calls" that can be evaluated with
step into and step out to leave.
With the change, that logic stayed in, but the inputs were always being
evaluated before they were stepped into or over. Now, when we construct
the steps, we also attach a list of inputs that we should defer
evaluation on to ensure we don't execute inputs that haven't been
executed yet.
It will then wrap the reference with a version that causes `Evaluate` to
do nothing. This prevents the overeager evaluation but allows the
reference to be evaluated if we need to read the filesystem.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
When pushing to an OCI layout where the top-level descriptor
blob already existed, pushOCILayout returned early without
updating index.json or writing pending referrers. Restructure
the control flow so the blob-exists case skips only the write
but still updates the index and flushes referrers.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Handle OCI layout referrers via subject-annotated index entries and add
integration coverage for copying signed attestations through oci-layout.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Add oci-layout:// source and target support to imagetools create and
inspect while keeping merge, filter, and referrer logic shared.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Verify imagetools copies signatures only for attestation manifests and
does not copy image-manifest signatures or unsupported referrers.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
We erroneously skipped a breakpoint when that breakpoint was the same as
the entrypoint and we did not use stop on entry. This is because we only
started evaluating breakpoints after the first step on the entrypoint
instead of at the entrypoint.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Add integration coverage for imagetools create --file and verify a
descriptor read from disk resolves to the expected copied manifest.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Add integration coverage for imagetools create --append and verify the
target is rewritten as a two-platform manifest list.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Add integration coverage for imagetools create --platform on an attested
multi-platform image and verify only the matching attestation remains.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Verify copied index content keeps the same digest and descriptor metadata.
Add function comments to clarify each imagetools integration test case.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Skip the load build context step when it doesn't have an associated
source line. This caused an extra branch to be created in an otherwise
pretty straightforward dockerfile where stepping in on a copy
instruction that used the context would stay on the same line because it
"stepped into" the context loading rather than being treated the same as
step next.
This resulted in some bad and confusing ergonomics with the cursor
position that were a bit confusing and unexpected.
There might be more areas to try and prune but the most common one, a
single branch instruction that doesn't have a location, now gets skipped
which is the exact thing that was generated for loading the context.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Properly map the source paths from the metadata in the solve to the
client side paths. The source path returns is relative to the context
that gets uploaded which is usually a subdirectory. The original code
noticed this when mapping the paths but made the invalid assumption that
the dockerfile would always be in the context path so it combined the
dockerfile name with the context path.
It is possible for the dockerfile to be in a subdirectory of the
context. In which case, we computed the paths incorrectly.
This modifies DAP to instead use the `DockerfileMappingDst` and
`DockerfileMappingSrc` which are special included variables to the
inputs that get filled in during the build for the purpose of mapping
the source path to the client side path.
Tests have also been added for this functionality to ensure it doesn't
break again. This should work with both absolute and relative paths
although absolute paths should probably be preferred for usage just
because they're less likely to result in weird things happening.
The sources are also normalized to always convert the source filenames
to absolute paths and DAP itself will accept relative paths but will
only ever communicate in absolute paths. When you set a breakpoint, it
will convert it to an absolute path and reference it in that way rather
than a relative path.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Case insensitive filesystems can cause breakpoints to not be seen or
verified. This is particularly true on Windows where the drive letter
can also participate in the filepath.
Change the detection logic for a breakpoint to be case insensitive. At
the same time, report the name of the source as part of the breakpoint
so that the editor can be told which casing we're expecting to be used.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>