... if they contact external registries.
This should, hopefully, decrease the flake rate.
We have already done this for (skopeo copy), sync seems
to have been missed at that time.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
registry-v2-schema1 is now registry-v2-schema1-only,
and there is a new registry-v2-schema1-supported because the default
/usr/bin/registry does not support schema1 any more.
Adjust tests.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
In bootc, we want the ability to assert that signature verification is
enforced.
Add a new top-level `--require-signed` switch. When passed, we use the
new `RequireSignatureVerification()` method to ensure that signature
verification is enforced.
Part of https://github.com/containers/skopeo/issues/1829.
Signed-off-by: Jonathan Lebon <jonathan@jlebon.com>
I want this for https://github.com/bootc-dev/bootc/issues/1686
so we can distinguish pulls there.
But more generally it's can be a good idea for people writing
scripts using skopeo to set custom user agents so that registries
can more easily trace which actors are performing tasks.
Assisted-by: Claude Code
Signed-off-by: Colin Walters <walters@verbum.org>
Else use ./bin/skopeo as the default binary.
This makes it a lot more flexible compared to just searching and using
the first skopeo in PATH. Also, allows to avoid any binary installation
to /usr/bin.
The SKOPEO_BINARY evaluation logic has been moved to a separate and
reusable Makefile target.
Co-authored-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
NewEphemeralSigningMechanism() may, with Sequoia, return
a mechanism which !SupportsSigning(); so, to determine that,
test with a non-ephemeral mechanism instead. (That's likely
actually faster, because we create a GNUPGHOME in these tests
anyway, so we avoid creating an deleting a separate temporary
directory.)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Currently, if a key is not found, the GPG mechanism reports
> Invalid GPG signature: {$GoStructDump}
while the Sequoia one reports
> $keyFingerprint was not found
Accept both.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
The original model the idea here is the proxy centralizes
verification of things like digest. However in practice,
this causes reading to be seriously awkward; ref
https://github.com/containers/containers-image-proxy-rs/issues/79
(Basically `FinishPipe` blocks the metadata channel)
Also, I have a project to implement a registry frontend to
`containers-storage:` and a core problem with `GetBlob` right
now is it *requires* the blob size up front even though the
underlying Go logic doesn't.
Moving to a "raw" interface solves that too. In this new
raw API, we return two file descriptors, one for the data
and one for the error channel, which contains a JSON
serialization of an error.
For the error type we reuse the existing "is error retryable"
and expose that back to the client.
We also (backwards compatibly) add this new error code
for the existing APIs.
Signed-off-by: Colin Walters <walters@verbum.org>
Some files in integration did not have _test, resulting in lots of
complains when running golangci-lint with --tests=false.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
I was experimenting with images with lots of layers (> 200) and
this invocation was incorrectly adding the entire response
into what was intended as the metadata plane.
`GetManifest` and `GetConfig` (even those are relatively small)
still always return their data over a pipe, same as blobs.
Add a new `GetLayerInfoPiped` that does the same so we
can easily get this information for images with a lot of layers.
Signed-off-by: Colin Walters <walters@verbum.org>
In PR review for a different issue, the question of what happens
if we hit overflow for the imageid serial was hit. This feels
pretty unlikely; if I did the math right, it'd require opening
an average of 136 images per second to overflow it in a year.
Nevertheless, in practice what we're sending on the wire is just a JSON
number, and if we extend this to the "max safe JSON number" of 2^53,
it'd take 285,616,414 images per second to overflow in a year, going
from implausible to probably impossible.
With a bit more work of course, we could make this a sparse mapping
and reuse freed numbers, but eh.
Signed-off-by: Colin Walters <walters@verbum.org>
