Php:5.4-apache Image 'Error response from daemon: missing signature key'

Docker Hub
,
1

Hi All -

Has anyone noticed that the php:5.4-apache image is failing to load with the error

‘Error response from daemon: missing signature key’

I’ve tried to pull this image from on different Docker clients since yesterday and I keep getting this error.

Is anyone else experiencing this or not experiencing this?

Is there a way to temporarily disable the signature key check?

Thanks!

Mike

2

That is a very old Docker image updated very long time ago. If I try to pull it, I get a different error

Error response from daemon: [DEPRECATION NOTICE] Docker Image Format v1 and Docker Image manifest version 2, schema 1 support is disabled by default and will be removed in an upcoming release. Suggest the author of docker.io/library/php:5.4-apache to upgrade the image to the OCI Format or Docker Image manifest v2, schema 2. More information at https://docs.docker.com/go/deprecated-image-specs/

It is because I use the containerd image store which is not compatible with it.

It looks like php:5.5-apache still works, if you can make your code compatible with it.

3

We use old images for compatibility testing, updating code is not an option.

I notice in the deprecation notice it says disabled by default. Is there a way to temporarily toggle that? We can store the image locally then.

4

@rimelek

I am also getting a similar error out of nowhere,
Are you able to verify it is the same issue as above?

We have been using this image for testing CMIS for the last few years:
https://hub.docker.com/r/srgannav/cmis-in-memory-repository-tomcat

We are pulling this image to an Azure Webapp and getting the following on it attempting to start:

2024-11-10T00:11:18.444Z ERROR - DockerApiException: Docker API responded with status code=InternalServerError, response={“message”:“missing signature key”}

If it is the same, I would also like to know if there is a way around the issue as I dont believe it will be able to be udpated (The image has not been updated in 9 years)

5

Then you can try running an old Docker daemon in a container. https://hub.docker.com/_/docker

docker run -d --name dind --privileged docker:19:03

And run the containers based on old images in that Docker in Docker container. I tried, but the Cgroup version on my Linux is v2 and I guess this is why it couldn’t run, but didn’t have time to downgrade.

That was a different error because I used the containerd image store. It wouldn’t solve your problem.

I ran this command on macOS:

hub-tool tag inspect php:5.4-apache

And got “Unsupported mediatype” and a list of numbers

Unsupported mediatype
[123 10 32 32 32 34 115 .... ]

I get a valid manifest for php 5.5-apache. So I’m not sure an old Docker would help actually, but that is my only idea. I also checked other old images like nginx:1.9 for which I got “Unsuppoeted mediatype” too, but nginx:1.10 worked. nginx:1.9 is also about 8 years old

6

Yes. Using hub-tool I got “Unsupported mediatype” for that image too.

7

We already are on an “old” docker daemon. We use the docker.io package via ubuntu 24’s package repository, which is 24.0.7 as of this post. This predates " Disabled by default in Release: v26.0" and " Target For Removal In Release: v27.0". Did something change server-side such that no one can pull these images regardless of docker version?

8

Do you still refer to the error message I got? I think that was a mistake from me to share, because it looks like it is confusing. The version of the manifest file is one thing. If you didn’t get this message, you don’t have this problem and it is irrelevant to you. I just pointed out that in the future, when containerd becomes the default image store, v1 will not even be supported eventually.

I shared that error message before I tried the hub-tool which showed that it could not even read the manifest.

I don’t know what happened to the old images. If you used the same Docker version previously and docke rpull worked, than something must have happened on Docker Hub. If you upgraded Docker to v24 automatically and once you had an older version, maybe an even older Docker could work, but there are also github issues where someone says this happens when something during an operation on the registry server, but I don’t know why only old images would be affected.

So that is why I wanted to try an old Docker like 19.03 or even 18.06, because I don’t remember when was the last time if ever when I pulled that PHP image. I think I always used the FPM versions and that is only available from 5.5. You can try asking about this on Docker Hub

Because if not even older Docker versions can download these images, than there is no reason to keep these images on Docker Hub. And if something happened on Docker Hub that corrupted only old images for example because only these were on an older storage, then you might even get those images restored.

9

No, I’m referring to this. Versions prior to this deprecation notice should be able to download images but aren’t able to.

Ultimately, I was able to work around this by downloading the image with a third party tool and then hosting it on our local github container registry.

10

So yes :slight_smile: That is exactly the error which is not relevant to you if you didn’t get the error.

That’s great. Thanks for sharing the link.