Verifiable publisher/build identity for an exact PHP Official Image

[Madelezhus]

Hello Docker Official Images maintainers,

I am reviewing the provenance of this exact docker.io/library/php publication:

• OCI index:
  sha256:f62df9916bc05ae3c5120b41a115938f22623b0c98c815cbe2c67bc73cec21ef
• Linux/amd64 manifest:
  sha256:450d778f41d54f2f626a3e4e36e8e50e60b08bf370ddc58cb120a28f79283360
• SLSA provenance statement blob:
  sha256:19007e4a7829d01a6385be12629c2cd5f5b8a3e1674471f114f56baa90f2aeb1
• Recipe revision:
  docker-library/php@445bf414f1d5866f7aef715f1203eae043710070, path 8.3/trixie/cli/Dockerfile.

The metadata digests and provenance subject match. However, I would like to distinguish those integrity checks from authentication of the claimed builder, https://github.com/docker-library.

Is verifiable evidence available linking this exact publication and provenance statement to the authorized Official Images builder or publisher? If so, where can it be obtained, and how should its authority, identity and exact subject be verified? I am not assuming any particular signing technology.

Anonymous Notary requests returned HTTP 401, so access was not obtained. This is not a claim that the image is unsigned.

If another official team handles this question, could you direct me to the appropriate channel?

Thank you.

[tianon]

Can you please say more about the actual problem you're trying to solve? I see a lot of technical details there, but I don't see a real problem statement unless I infer one from between the lines.

[Madelezhus]

Thanks — fair point. I led with the technical details and did not explain the practical problem clearly.

We are qualifying a PHP runtime for our application. For our dependency review, we need to document why we trust the exact image we use to have been published through the authorized Docker Official Images process.

We have matched the PHP binary and library hashes observed in our runtime to the image’s SBOM, and checked that the provenance statement refers to the exact platform manifest. The remaining question is what establishes the authority of that provenance statement: matching hashes alone does not authenticate its claimed builder.

Concretely, what is the intended trust model for consumers of this image? Should we rely on the official Docker Hub namespace and its access controls, or is there additional independently verifiable publisher/build evidence for this exact digest?

We are not reporting a suspected compromise or a runtime defect, and we are not asking you to implement a particular signing mechanism. We want to document the supported trust basis accurately, including any limitations, rather than impose a verification requirement that the publication process does not claim to satisfy.

Thank you for helping us clarify this.

[tianon]

We do not currently implement a signing solution, and our provenance is best-effort (whatever BuildKit provides plus some targeted OCI annotations).

Docker Hub's namespace access controls are our current trust boundary, yes.

We have plans to eventually implement a signing solution of some kind, but it has been on the backlog for a while (and hasn't been prioritized), so I wouldn't recommend waiting for it.

If you wanted to do something deeper, you could add the trust boundary of GitHub access controls by scraping through history in https://github.com/docker-library/meta, but it's going to be a little bit esoteric to accomplish in a clean way.