Registry: Error response from daemon: missing signature key after upgrade to 1.21.0 #12046

@KN4CK3R commented on GitHub (Nov 28, 2023):

Thanks for testing. Maybe a newer docker client version is more strict with the HTTP headers of the content. With SERVE_DIRECT the content response looks like this

Docker-Header: xyx
Docker-Header2: xyx
Location: url-where-the-blob-is

But the response from url-where-the-blob-is does not contain the docker headers.

@KN4CK3R commented on GitHub (Nov 28, 2023): Thanks for testing. Maybe a newer docker client version is more strict with the HTTP headers of the content. With `SERVE_DIRECT` the content response looks like this ``` Docker-Header: xyx Docker-Header2: xyx Location: url-where-the-blob-is ``` But the response from `url-where-the-blob-is` does not contain the docker headers.

GiteaMirror commented

@KN4CK3R commented on GitHub (Nov 28, 2023):

May still be wrong because you can't add arbitrary headers to the response:
https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html

Overriding Response Header Values

There are times when you want to override certain response header values in a GET response. For example, you might override the Content-Disposition response header value in your GET request.

You can override values for a set of response headers using the following query parameters. ...
response-content-type
response-content-language
response-expires
response-cache-control
response-content-disposition
response-content-encoding

@KN4CK3R commented on GitHub (Nov 28, 2023): May still be wrong because you can't add arbitrary headers to the response: https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html > Overriding Response Header Values > > There are times when you want to override certain response header values in a GET response. For example, you might override the Content-Disposition response header value in your GET request. > > You can override values for a set of response headers using the following query parameters. ... > > response-content-type > response-content-language > response-expires > response-cache-control > response-content-disposition > response-content-encoding

GiteaMirror commented

@KN4CK3R commented on GitHub (Nov 28, 2023):

Looks like the error message is from here:
aabc10ec26/jsonsign.go (L23-L25)

But that is unrelated to the serve direct setting...?

The code is only used in Docker schema1 manifests which were removed in 08/23:
0742b56677 (diff-f65d932ec1e10721d44ebd79b23a64cc70599bb6f24db45b48a9f275c9332147L146)

What Docker version do you use? Does some setting enforces the usage of schema1 (which is not supported in Gitea)?

@KN4CK3R commented on GitHub (Nov 28, 2023): Looks like the error message is from here: https://github.com/docker/libtrust/blob/aabc10ec26b754e797f9028f4589c5b7bd90dc20/jsonsign.go#L23-L25 But that is unrelated to the serve direct setting...? The code is only used in Docker schema1 manifests which were removed in 08/23: https://github.com/distribution/distribution/commit/0742b56677a04d00a97fd298663ab09f80b7583c#diff-f65d932ec1e10721d44ebd79b23a64cc70599bb6f24db45b48a9f275c9332147L146 What Docker version do you use? Does some setting enforces the usage of schema1 (which is not supported in Gitea)?

GiteaMirror commented

@EternalDeiwos commented on GitHub (Nov 28, 2023):

What Docker version do you use?

I'm running Docker CE 24.0.6 locally.

Does some setting enforces the usage of schema1 (which is not supported in Gitea)?

Not as far as I have explicitly configured or am aware of...

@EternalDeiwos commented on GitHub (Nov 28, 2023): > What Docker version do you use? I'm running Docker CE `24.0.6` locally. > Does some setting enforces the usage of schema1 (which is not supported in Gitea)? Not as far as I have explicitly configured or am aware of...

GiteaMirror commented

@jessielw commented on GitHub (Dec 11, 2023):

I've changed nothing other than the update to 1.21. I can push to packages but cannot pull. I tried to re login to docker and it's getting Error response from daemon: ............ connection refused even though it's the same setup as before.

Tried to downgrade but the databases are not compatible. Any work arounds until a fix is out?

Note: out of curiosity I pulled down the nightly docker build to see if the fix was on that, but alas it was not. Same issue and now with the database upgrade I'm stuck on the nightly release haha

@jessielw commented on GitHub (Dec 11, 2023): I've changed nothing other than the update to 1.21. I can push to packages but cannot pull. I tried to re login to docker and it's getting `Error response from daemon: ............ connection refused` even though it's the same setup as before. Tried to downgrade but the databases are not compatible. Any work arounds until a fix is out? Note: out of curiosity I pulled down the `nightly` docker build to see if the fix was on that, but alas it was not. Same issue and now with the database upgrade I'm stuck on the `nightly` release haha

GiteaMirror commented

@lunny commented on GitHub (Dec 12, 2023):

Maybe you need to check whether your ROOT_URL is correct.

@lunny commented on GitHub (Dec 12, 2023): Maybe you need to check whether your `ROOT_URL` is correct.

GiteaMirror commented

@jessielw commented on GitHub (Dec 12, 2023):

Maybe you need to check whether your ROOT_URL is correct.

I'll double-check it in the morning, but it was for the last several months with no configuration changes. Only the last update broke pulling from package registries for me.

@jessielw commented on GitHub (Dec 12, 2023): > Maybe you need to check whether your `ROOT_URL` is correct. I'll double-check it in the morning, but it was for the last several months with no configuration changes. Only the last update broke pulling from package registries for me.

GiteaMirror commented

@lunny commented on GitHub (Dec 12, 2023):

Maybe you have a different problem as this one? If that, you can create a new issue with more description.

@lunny commented on GitHub (Dec 12, 2023): Maybe you have a different problem as this one? If that, you can create a new issue with more description.

GiteaMirror commented

@jessielw commented on GitHub (Dec 12, 2023):

Maybe you have a different problem as this one? If that, you can create a new issue with more description.

It's possible, actually, although it seems like it's similar.

I'll produce the issue again tomorrow and post a more detailed bug in a separate issue.

@jessielw commented on GitHub (Dec 12, 2023): > Maybe you have a different problem as this one? If that, you can create a new issue with more description. It's possible, actually, although it seems like it's similar. I'll produce the issue again tomorrow and post a more detailed bug in a separate issue.

GiteaMirror commented

@EternalDeiwos commented on GitHub (Dec 12, 2023):

@KN4CK3R I have just seen the needs feedback tag, looking for anything specific?

@EternalDeiwos commented on GitHub (Dec 12, 2023): @KN4CK3R I have just seen the needs feedback tag, looking for anything specific?

GiteaMirror commented

@wytzevanderploeg commented on GitHub (Feb 23, 2024):

I had this problem, it turned out I had a rather old version of docker-ce running.

Sending build context to Docker daemon  5.632kB
Step 1/1 : FROM gitea/gitea:1.20
missing signature key

Docker version: Docker version 17.09.1-ce, build 19e2cf6
After upgrading to the latest version (Docker version 25.0.3, build 4debf41) I no longer had any problems pulling/building the image.

@wytzevanderploeg commented on GitHub (Feb 23, 2024): I had this problem, it turned out I had a rather old version of docker-ce running. ``` Sending build context to Docker daemon 5.632kB Step 1/1 : FROM gitea/gitea:1.20 missing signature key ``` Docker version: `Docker version 17.09.1-ce, build 19e2cf6` After upgrading to the latest version (Docker version 25.0.3, build 4debf41) I no longer had any problems pulling/building the image.

GiteaMirror commented