Monday, 28 June 2021

Docker Content Trust and the Case of the PEBCAK

 I'm doing some work with trusted/signed container images at present, and am using IBM Container Registry (ICR) as my ... container registry.

I'm doing the actual build/tag/push from an Ubuntu 20.04 VM, having logged into ICR: -

docker login --username iamapikey

and having set my Bash variables to enable Docker Content Trust (DCT): -


I then built / tagged: -

docker build --no-cache -t -f Dockerfile .

and pushed my image: -

docker push

Whilst this appeared to work, it ultimately failed: -

The push refers to repository []
d0471711ab1a: Pushed 
5dbe8c3d30af: Pushed 
67780d477478: Pushed 
5db88766b0e0: Pushed 
36dfa50192c8: Pushed 
8506b073cd53: Pushed 
468af79aab10: Pushed 
fbf82c12d86e: Pushed 
4dc20fbc0e8d: Pushed 
b831cc3ae47e: Pushed 
ace0eda3e3be: Pushed 
latest: digest: sha256:bfcadd198529d842b97dcd633f7b0b65fbcdca4599886a172a31eff0543f3f9d size: 2610
Signing and pushing trust metadata
unable to reach trust server at this time: 301.

I checked and re-checked my steps, and then turned to my faithful friend, Google .... and found this: -

in which the person raising the issue said this: -

After a day and a half of debugging and redoing everything from scratch several times I've figured out that the problem was the trailing slash in the notary server url.

That was revelatory .... notice that I'd previously typed: -


Once I changed my DCT URL to: -


( i.e. no trailing slash )

everything was copacetic 😹

Easy when you know how now

No comments:

Yay, VMware Fusion and macOS Big Sur - no longer "NAT good friends" - forgive the double negative and the terrible pun ...

After macOS 11 Big Sur was released in 2020, VMware updated their Fusion product to v12 and, sadly, managed to break Network Address Trans...