We've long been able to use these and they have a couple
great benefits:
1. Forces you to always access them atomically. With the pointer
variants it's completely valid to access the regular ol' int64/uint32
etc. without using the atomic.* methods. These wrappers don't provide
access to the underlying value so it forces correct usage always.
2. Conveys intent much better. Seeing the type be atomic.Int32 immediately
lets the reader know that this var will be used in a concurrent context,
and we no longer need comments like "this MUST be accessed atomically"
or similar.
Signed-off-by: Danny Canter <danny@dcantah.dev>
Instead of failing and returning the error received from the authorizer,
fall back the already existing path to handle non-nil response with a
status code indicating a failure.
Allow the Authorizer to return an error both from Authorize and from
AddResponses.
Signed-off-by: Alberto Garcia Hierro <damaso.hierro@docker.com>
Schema 1 (`application/vnd.docker.distribution.manifest.v1+prettyjws`) has been
officially deprecated since containerd v1.7 (PR 6884), and disabled since v2.0 (PR 9765).
Users who have been seeing warnings like `conversion from schema 1 images is deprecated`
now have to rebuild the image with Schema 2 or OCI.
Schema 2 was introduced in Docker 1.10 (Feb 2016), so most users should have been already
using Schema 2 or OCI.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Prevent a panic in the Docker pusher pushWriter, by checking that
the pipe is non nil before attempting to use it.
The panic was found by Moby issue #46746 (https://github.com/moby/moby/issues/46746).
With this fix the panic no longer reproduces.
Signed-off-by: Cesar Talledo <cesar.talledo@docker.com>
Currently `cri.config.headers` is only added
to registry requests (manifests/blobs), but not
the auth requests.
This patch fixed it by passing `cri.config.headers`
when we create `DockerAuthorizer`.
Signed-off-by: Jin Dong <djdongjin95@gmail.com>
This patch fixed an issue that when we create
a `DockerAuthorizer`, we didn't pass the
headers read from hosts.toml to it, causing
the headers are missing in auth requests.
Signed-off-by: Jin Dong <djdongjin95@gmail.com>
If `host.caCerts, host.clientPairs, host.skipVerify` are
all `nil` and `host.skipVerify` not `nil`, `explicitTLS`
will be set to be `true` instead of `false`.
Signed-off-by: Jin Dong <djdongjin95@gmail.com>
Don't produce `reference for unknown type: application/vnd.in-toto+json`
warning logs when pushing/fetching an image containing the attestation
manifests.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The default transport are used in 3 places:
1. `ConfigureDefaultRegistries` (no `hosts_dir` is set)
2. `ConfigureHosts` (when `hosts_dir` is set)
3. in cri service
2 and 3 use/duplicate the same default transport, whereas 1
uses go's default Client/Transport
This PR moves the default transport to a common funcion (can pass in tls config).
Signed-off-by: Jin Dong <djdongjin95@gmail.com>
When no port is specified, allow falling back from 443 to 80 when
http is specified along with a TLS configuration.
Signed-off-by: Derek McGowan <derek@mcg.dev>
Before this, during a call to the docker resolver, we would generate
span wrappers for each HTTPRequest correctly, however, as the docker
resolver reaches out to the docker authorizer, it could create HTTP
requests (for fetching tokens) that would not be wrapped in any span.
This can result in rather confusing traces, e.g. something like:
remotes.docker.resolver.HTTPRequest
HTTP HEAD (fetch index, fails with 401)
HTTP GET (fetch token)
remotes.docker.resolver.HTTPRequest
HTTP HEAD (fetch index)
remotes.docker.resolver.HTTPRequest
HTTP GET (fetch manifest)
By adding a span into the FetchToken, this trace becomes a little easier
to consume:
remotes.docker.resolver.HTTPRequest
HTTP HEAD (fetch index, fails with 401)
remotes.docker.resolver.FetchToken
HTTP GET (fetch token)
remotes.docker.resolver.HTTPRequest
HTTP HEAD (fetch index)
remotes.docker.resolver.HTTPRequest
HTTP GET (fetch manifest)
Signed-off-by: Justin Chadwell <me@jedevc.com>
Schema 1 (`application/vnd.docker.distribution.manifest.v1+prettyjws`) has been
officially deprecated since containerd v1.7 (PR 6884).
We have planned to remove the support for Schema 1 in containerd v2.0, but this
removal may still surprise some users.
So, in containerd v2.0 we will just disable it by default.
The support for Schema 1 can be still enabled by setting an environment variable
`CONTAINERD_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE=1`, however, this workaround
will be completely removed in containerd v2.1.
Schema 2 was introduced in Docker 1.10 (Feb 2016), so most users should
have been already using Schema 2 or OCI.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
We also need an additional check to avoid setting both the error and
response which can create a race where they can arrive in the receiving
thread in either order.
If we hit an error, we don't need to send the response.
> There is a condition where the registry (unexpectedly, not to spec)
> returns 201 or 204 on the put before the body is fully written. I would
> expect that the http library would issue close and could fall into a
> deadlock here. We could just read respC and call setResponse. In that
> case ErrClosedPipe would get returned and Commit shouldn't be called
> anyway.
Signed-off-by: Justin Chadwell <me@jedevc.com>
If sending two messages from goroutine X:
a <- 1
b <- 2
And receiving them in goroutine Y:
select {
case <- a:
case <- b:
}
Either branch of the select can trigger first - so when we call
.setError and .Close next to each other, we don't know whether the done
channel will close first or the error channel will receive first - so
sometimes, we get an incorrect error message.
We resolve this by not sending both signals - instead, we can have
.setError *imply* .Close, by having the pushWriter call .Close on
itself, after receiving an error.
Signed-off-by: Justin Chadwell <me@jedevc.com>
If we get io.ErrClosedPipe in pushWriter.Write, there are three possible
scenarios:
- The request has failed, we need to attempt a reset, so we can expect a
new pipe incoming on pipeC.
- The request has failed, we don't need to attempt a reset, so we can
expect an incoming error on errC.
- Something else externally has called Close, so we can expect the done
channel to be closed.
This patch ensures that we block for as long as possible (while still
handling each of the above cases, so we avoid hanging), to make sure
that we properly return an appropriate error message each time.
Signed-off-by: Justin Chadwell <me@jedevc.com>
