docker pull nodered/node-red fails with DOCKER_CONTENT_TRUST=1

[dnoliver]

What are the steps to reproduce?

DOCKER_CONTENT_TRUST=1 docker pull nodered/node-red

What happens?

[root@fitlet-2 tpm2]# docker pull nodered/node-red
Using default tag: latest
Error: remote trust data does not exist for docker.io/nodered/node-red: notary.docker.io does not have trust data for docker.io/nodered/node-red

What do you expect to happen?

[root@fitlet-2 tpm2]# docker pull nodered/node-red
Using default tag: latest
latest: Pulling from nodered/node-red
0a6724ff3fcd: Downloading  147.1kB/2.815MB
0e88ccee218e: Downloading  4.135MB/22.2MB
68aee5547ce7: Downloading  1.932MB/2.345MB
449ce1354b7e: Waiting
ef5a64ae34b5: Waiting
ce7315e3679c: Waiting
14134559e7be: Waiting
37cbffb78fc3: Waiting
985420e950d0: Waiting
241e4876a223: Waiting
6eb8914161d7: Waiting
9974816a3be8: Waiting

Please tell us about your environment:

• Node-RED version: nodered/node-red:latest
• Node.js version: included in Docker image
• npm version: included in Docker Image
• Platform/OS: Docker, Fedora IoT 33
• Browser: Chrome

Workaround:

[root@fitlet-2 tpm2]# DOCKER_CONTENT_TRUST=0 docker pull nodered/node-red

[knolleary]

Moving this issue over to the docker repo. Looks like we need to investigate how to sign official releases.

[hardillb]

Details look to be here:
https://docs.docker.com/engine/security/trust/#signing-images-with-docker-content-trust

[dceejay]

so what extra does this give us ? It's not as if just anyone can push to the repo/docker hub. And how does it compare to full official docker images ? (https://docs.docker.com/docker-hub/official_images/) - does it really add that much value (vs maintenance effort)

[dnoliver]

Having Docker Content Trust enabled is recommended by docker-bench-security and the Center for Internet Security (CIS) Docker Benchmark. So anybody following those guidelines will run into this problem with an unsigned image.

Even if anyone can push to the repo/docker hub (I guess it is password protected at least?), only the ones that have the private key can generate signed images, or sign them after being pushed. I guess there are much more requirements than signing images to became an official image (like having Docker's approval to became one), but signatures can be managed independently by any user or organization.

In addition of having a way of verifying the source and integrity of the image on pull and run, Docker Content Trust follows the recommendations provided by The Update Framework, so the mayor benefits for the users of this image is having a reliable update process. Having to disable that feature to use one image is a major drawback.

As regards implementation effort, there are automation examples of this process like in here

[hardillb]

Pushing this back from the v2.0 release as I still can't work out how to sign a multi-arch container build from the docker build-push GitHub Action

[hardillb]

Still can't find any sensible way to sign multi arch builds from docker buildx