So that callers can actually check the status code of all requests if
needed. This changes error text slightly but I think it still carries
the same meaning.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When looking for inexact matches, this will cause the matches to be skipped.
When checking for an exact match, this will cause an upload failure;
we don't have any other way to handle pre-existing blobs on the destination.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This is not a security vulnerability because the registry can just as well
send a manifest modified to match, but doing this correctly protects us
in case this function were used for other purposes in the future.
Fixes#2687.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
The ping v1 happens when the ping v2 fails, however, it causes the ping
v2 error to be skipped and not output to the user. As result, when a
registry has v1 and v2 enabled, and there are, for example, intermittent
connectivity issues making the ping v2 fail, the user is presented with
a misleading error saying "can't talk to V1 registry."
Since the only use of v1 is for the search API as a workaround for
docker.io, and new container registries setups are very unlikely to be
v1-only, there is little utility in keeping this v1 detection in the
attempt to help the user realize their setup is v1-only, hence not
compatible. On the contratry, it just presents the user with a
misleading error in certain circumstances.
Signed-off-by: Carlos Rodriguez-Fernandez <carlosrodrifernandez@gmail.com>
These fields need to exist when parsing JSON; but we can just
record the outcome of processing them.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
We will want to add locks and more to the in-memory type;
sharing that with JSON gets awkward, and an explicit separation
between the externally-imposed structure and internal records
is cleaner anyway.
For now, just introduces a separate type with the same structure,
should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Not doing so can keep the HTTP client code waiting forever,
keeping some goroutines running, and the socket open.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
The idea of a StatusTooManyRequests retry loop,
or the needsRetryWithUpdatedScope logic,
only makes sense if we do get a response; on other errors,
we can exit immediately. So do that, and simplify the
code.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This may make errors visible to errors.As/errors.Is
This commit, in general, attempts not to change the formatting;
only in newShortNameAliasCache, the order of the errors is no longer
reversed.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... eliminating obsolete comments.
Alternatively, we could call tlsconfig.ServerDefault(),
but let's get closer to just delegating to the standard library
rather than managing TLS policy ourselves.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
As of Go 1.18 (which we require), this effectively bumps the minimum to TLS 1.2.
Compare 626c097f8c
updating to TLS 1.2; it is similarly not configurable.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Enable HTTP(S) keep-alive to improve network performance and reduce
latency. We need several HTTP(S) requests before we get to request the
blob and each of them requires a new HTTP(S) connection and that slows
down significantly pulling images, especially on networks with a
higher latency (e.g. wifi).
This will allow multiple requests to be sent over a single connection,
reducing the overhead of establishing new connections for each
request.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Usually by removing them, sometimes by actually using an already-available value.
golangci-lint linter: unparam
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This is quite loud in case it decides not to reconnect,
so that we can have an idea of the failing situations.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... to be also used by Fulcio.
Note that the atomic: transport uses a skopeo/... user agent,
we don't care to change that.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Clarify that exponential backoff only happens if the registry
does not specify otherwise.
And in parseRetryAfter , do not talk about backoff at all, because
that function is not involved in that.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... when checking for missing images.
In particular, this is necessary for use-sigstore-attachments not to
cause failures when pulling from registry.redhat.io.
Red Hat internal reference: RITM1310318
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... instead of httpResponseToError, or even raw manual error
logging.
NOTE: This breaks status-based checks, like 401 and 429.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... to simplify user-visible error messages, and to make the
errors less ambiguous for errcode.ErrorCoder testing.
NOTE: This may break callers that expect the full errcode.Errors.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... so that we can modify the handleErrorResponse consumption
logic in one place.
Note that this may change the user-visible error message.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Using the github.com/docker/distribution/registry/client package will
import many huge prometheus dependencies, e.g.
* github.com/prometheus/client_golang/prometheus/promhttp
* github.com/prometheus/client_golang/prometheus
* github.com/prometheus/procfs
and even more...
All of these dependencies are completely unused AFAICT but will still end
up in a binary because they are imported transitive.
github.com/docker/distribution/registry/client is only used to check
http errors so I think it makes sense to copy only the required code
into the docker package.
I vendored this commit into podman and it saves over 700KB in binary
size.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
By default docker_client just uses the auth challenges from the /v2/
ping request to request a Bearer Token. For some requests (e.g. for
/v2/_catalog on some registries) this might not be sufficient and return a
a HTTP Unauthorized Error with the "www-authenticate" header including
an "insufficient_scope" error. In that case the client will now retry
the request and fetch a new token with updated challenges to have the
"scope" matching for what the endpoint needs.
This fixes https://github.com/containers/image/issues/1478
Signed-off-by: Ralf Haferkamp <rhafer@suse.com>
Signed-off-by: Ralf Haferkamp <ralf@h4kamp.de>
Signed-off-by: Dan Čermák <dcermak@suse.com>
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Co-authored-by: Miloslav Trmač <mitr@redhat.com>
Co-authored-by: Ralf Haferkamp <ralf@h4kamp.de>
`github.com/pkg/errors` is deprecated since quite some time so we now
use the native error wrapping for more idiomatic golang.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
NOTE design decisions:
- We can read Cosign data from lookaside
- We ONLY write Cosign data to Cosign attachments, never
to lookaside; because lookaside is set up by default, that
would be too confusing.
- We ONLY use Cosign attachments at all if the user opts in
via registries.d.
One concern is performance impact of the extra round-trip
for large-scale operations like (skopeo sync).
Short-term, a much more worrying is the risk that we probably
have the "is this failure just a missing atachment manifest,
or a real failure reading it?" heuristic wrong, so without an
opt-in, _all_ image reads are going to fail. This might eventually
go away after more testing.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Paul Holzinger