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>
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>
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>
... 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>
... 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>
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>
Currently, the User-Agent defaults to a golang default of either:
Go-http-client/1.1
Go-http-client/2.0
This makes it rather difficult to distinguish this client from any other
random golang program in registry logs.
Instead, set the default User-Agent to:
containers/$VERSION (github.com/containers/image)
Signed-off-by: Jon Johnson <jonjohnson@google.com>
We want to allow users to store certs in their homedir when running in rootless mode.
We want rootless podman and rootless buildah to add $HOME/.config/containers/certs.d
to the search path for certificates by default.
Currently there is no way for a non privileged user to get certs without being root on
the system or specify the certs dir on ever call.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
... primarily so that imports of packages that aren't in the
standard library are all in one section.
Also correct the package in tarball/doc.go example (without verifying
the code works).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... so that major-version-aware Go module import
(as opposed to vX.Y.Z+incompatible, which does not allow different
packages to use different versions) works right.
Also requires adding some more GO111MODULE=on options to Makefile.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Shifted a number of auth-getting unit tests from docker_client_test.go
into config_test.go, since they only excercise config.go logic.
They'd been in their previous location since landing in e18b1afd (Be
benevolent to .docker/config.json file, 2016-09-20, #96).
Signed-off-by: W. Trevor King <wking@tremily.us>
- Network IO paths should react to cancels now.
- File IO paths generally still won't.
- `SystemContext` objects have been renamed to `sys` to leave `ctx`
available for the stdlib context objects.
Signed-off-by: Mike Lundy <mike@fluffypenguin.org>
Adding /etc/containers/certs.d as another default certs directory
The code will first check /etc/containers/certs.d for the certificates
and if not found at this path it will fall back to /etc/docker/certs.dir
Signed-off-by: umohnani8 <umohnani@redhat.com>
See: https://docs.docker.com/registry/spec/auth/token/
Signed-off-by: Ed King <eking@pivotal.io>
Signed-off-by: Will Martin <wmartin@pivotal.io>
Signed-off-by: Julia Nedialkova <julianedialkova@hotmail.com>
This package is used in authenticating a user for kpod login
and can be used for authentication in kpod push, pull etc.
Signed-off-by: umohnani8 <umohnani@redhat.com>
This will make /etc/docker/certs.d/$host[:$port], notably RHEL CDN
certificates, work by default.
types.SystemContext.DockerCertPath, if defined, overrides and disables
DockerPerHostCertDirPath. We now always look into _some_ (exactly one)
directory. (This also forces us to explicitly override the default path
in tests because in Travis /etc/docker has mode 0700, causing spurious failures.)
(See also the added comment about handling docker.io in certs.d.)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
i
Add containers/storage as a backend type called 'storage'.
The image's blobs are stored either as storage layers (if they look like
archived layers) or (alongside the manifest and signatures) as named big
data items associated with the image.
Inspection data and record-keeping (so that we can remember which blobs
were layers and which weren't) are encoded as a JSON object which is
stored in the storage image's metadata field.
When importing blobs, layer IDs are generated by concatenating the
parent's layer ID (if there is one) with the hex string representation
of the expected digest of the content blob, if one is known. If there
is no expected digest, the ID is randomly generated.
If we find ourselves importing a layer with the same ID as a layer that
we already have, we digest the incoming stream and compare it to the
cached digest of the already-present layer, and return an error only if
they don't match. If an expected blob digest is provided, the actual
digest of the blob is compared with it, and if they don't match, an
error is returned.
If we find ourselves importing a blob more than once, we track the IDs
of each of the resulting layers.
If we find ourselves importing an image that wants to be tagged with a
name that is already in use, the name is then assigned to the new image
and the old image remains otherwise unmodified. If that incoming image
claims to have the same ID as an image which we already have, the import
will fail.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Docker can store auth entries with schema prefix or even path suffix.
See an example:
{
"auths": {
"10.3.10.88:5000": {
...
},
"http://10.3.10.88:5000/v2/": {
...
},
"https://10.3.10.88:5000": {
...
},
"https://index.docker.io/v1/": {
...
}
}
}
The entries were created using command `docker login` of upstream Docker
1.12. Let's normalize the auth keys before trying to match against
hostname.
Signed-off-by: Michal Minář <miminar@redhat.com>