docker / cli

The Docker CLI
Apache License 2.0
4.85k stars 1.91k forks source link

Observation/Question/Potential Bug trust signature bytesize different then notary #2286

Open marcofranssen opened 4 years ago

marcofranssen commented 4 years ago

I'm making a mapping between docker trust and notary commands.

docker trust sign marcofranssen/openjdk:latest

Now to do same as docker command does to sign using the notary cli I came up with following which I think is equivalent. The only thing required is to get the image digest somehow and to get the bytesize of the image.

notary addhash docker.io/marcofranssen/openjdk latest **bytesize** **digest** --publish

Now to compare and figure out the bytesize i tried following notary command to compare it to some docker image equivalent.

$ notary list docker.io/marcofranssen/openjdk
NAME      DIGEST                                                              SIZE (BYTES)    ROLE
----      ------                                                              ------------    ----
latest    c0ae5f16a6708f5a0b280c4096fb7c32a2cced955a5de01c3dd91a2d8f6bc591    2407            targets/marcofranssen

Now to figure out the digest and bytesize to use using the notary command I used following command.

$ docker image inspect marcofranssen/openjdk:latest --format='{{printf "Bytesize: %d\nDigests: %s" .Size .RepoDigests}}'
Bytesize: 487231728
Digests: [marcofranssen/openjdk@sha256:c0ae5f16a6708f5a0b280c4096fb7c32a2cced955a5de01c3dd91a2d8f6bc591 philipssoftware/openjdk@sha256:c0ae5f16a6708f5a0b280c4096fb7c32a2cced955a5de01c3dd91a2d8f6bc591]

To my surprise the Bytesize from the docker command is 487231728 and the one reported by notary is 2407.

The image was signed using docker trust.

Is this a bug? https://github.com/docker/cli/blob/74fb129a73a348689794781e3ad5d1d2dcca6d7a/cli/command/trust/sign.go#L147

Should I get the bytesize for a docker image tag differently to be able to document the equivalent notary command?

marcofranssen commented 4 years ago

I have also been checking other docker cli commands to see if any of those match the size reported by notary.

docker history marcofranssen/openjdk:latest

Also there is no layer matching the size reported by notary.

thaJeztah commented 4 years ago

@justincormack PTAL

justincormack commented 4 years ago

The size is not the layer size, it is the size of the manifest, which is what gets signed. The manifest contains the hashes of the layers so those are indirectly signed. You can't currently get the manifest size from Docker directly I don't think, as it is just created on push. This is one of the reasons why we want to shift to containerd backend fully, as that keeps manifests locally.

marcofranssen commented 4 years ago

So when I want to sign a docker image with notary add or notary addhash what should be the bytesize I need to use there? Is that the full size of the image in bytes?

justincormack commented 4 years ago

No, it is the size of the manifest, not the image.

Here is an example signing a multi-arch manifest (which is similar) https://github.com/linuxkit/linuxkit/blob/292dbdf46f0b1720bf710946a3a40a3ac0209463/tools/alpine/push-manifest.sh

It uses this manifest-tool https://github.com/estesp/manifest-tool to query the registry for the size and hash.

marcofranssen commented 4 years ago

I have tried now with

$ docker manifest inspect marcofranssen/openjdk:latest | wc -c
2310

where notary reports

$ notary list marcofranssen/openjdk
NAME      DIGEST                                                              SIZE (BYTES)    ROLE
----      ------                                                              ------------    ----
latest    9e05af6b73d4ba84c26e95bd2018a7c0747fdf3fb95d47608a2a7c79ef7aac99    2619            targets/marcofranssen

It is off by 309 bytes.

Not sure if this is still buggy in the experimental docker manifest cli.

In verbose mode it shows a couple of bytes more (400).

$ docker manifest inspect -v marcofranssen/openjdk:latest | wc -c
2710
marcofranssen commented 4 years ago

@justincormack could it be a potential bug in the new docker manifest commands? See my previous comment.